Mengirim data log ke Azure Monitor dengan menggunakan HTTP Data Collector API (tidak digunakan lagi)
Artikel ini menunjukkan cara menggunakan HTTP Data Collector API untuk mengirim data log ke Azure Monitor dari klien REST API. Artikel ini menjelaskan cara memformat data yang dikumpulkan oleh skrip atau aplikasi Anda, menyertakannya ke dalam permintaan, dan membuat permintaan tersebut diotorisasi oleh Azure Monitor. Kami memberikan contoh untuk Azure PowerShell, C #, dan Python.
Catatan
API Pengumpul Data HTTP Azure Monitor tidak digunakan lagi dan tidak akan lagi berfungsi pada 14/9/2026. Ini telah digantikan oleh API penyerapan Log.
Konsep
Anda dapat menggunakan HTTP Data Collector API untuk mengirim data log ke ruang kerja Log Analytics di Azure Monitor dari klien mana pun yang dapat memanggil REST API. Klien mungkin berupa runbook di Azure Automation yang mengumpulkan data manajemen dari Azure atau cloud lain, atau mungkin sistem manajemen alternatif yang menggunakan Azure Monitor untuk mengonsolidasikan dan menganalisis data log.
Semua data di ruang kerja Log Analytics disimpan sebagai rekaman dengan jenis rekaman tertentu. Anda memformat data Anda untuk dikirim ke HTTP Data Collector API sebagai beberapa rekaman dalam JavaScript Object Notation (JSON). Saat Anda mengirimkan data, rekaman individual dibuat di repositori untuk setiap rekaman di payload permintaan.
Buat permintaan
Untuk menggunakan HTTP Data Collector API, buat permintaan POST yang menyertakan data yang akan dikirim dalam JSON. Tiga tabel berikutnya mencantumkan atribut yang diperlukan untuk setiap permintaan. Kami menjelaskan setiap atribut secara lebih rinci nanti di artikel.
URI Permintaan
Atribut | Properti |
---|---|
Metode | POST |
URI | https://<CustomerId>.ods.opinsights.azure.com/api/logs?api-version=2016-04-01 |
Jenis konten | application/json |
Meminta parameter URI
Parameter | Deskripsi |
---|---|
CustomerID | Pengidentifikasi unik untuk ruang kerja Log Analytics. |
Sumber daya | Nama sumber daya API: /api/logs. |
Versi API | Versi API yang akan digunakan dengan permintaan ini. Saat ini, versinya adalah 2016-04-01. |
Header permintaan
Header | Deskripsi |
---|---|
Authorization | Tanda tangan otorisasi. Nanti di artikel, Anda bisa membaca tentang cara membuat header HMAC-SHA256. |
Log-Type | Tentukan jenis rekaman data yang sedang dikirimkan. Data ini hanya dapat berisi huruf, angka, dan karakter garis bawah (_), dan tidak dapat melebihi 100 karakter. |
x-ms-date | Tanggal permintaan diproses, dalam format RFC 1123 . |
x-ms-AzureResourceId | ID sumber daya dari sumber daya Azure yang harus dikaitkan dengan data. Fitur ini mengisi properti _ResourceId dan memungkinkan data disertakan dalam kueri resource-context. Jika bidang ini tidak ditentukan, data tidak akan disertakan dalam kueri konteks sumber daya. |
bidang yang dihasilkan waktu | Nama bidang dalam data yang berisi tanda waktu item data. Jika Anda menentukan bidang, maka isinya akan digunakan untuk TimeGenerated. Jika bidang ini tidak ditentukan, nilai default untuk TimeGenerated adalah waktu saat pesan diserap. Isi kolom pesan harus mengikuti format ISO 8601 format YYYY-MM-DDThh:mm:ssZ. Nilai Waktu yang Dihasilkan tidak boleh lebih lama dari 2 hari sebelum menerima waktu atau lebih dari satu hari di masa mendatang. Dalam kasus seperti itu, waktu pesan diserap akan digunakan. |
Authorization
Setiap permintaan ke Azure Monitor HTTP Data Collector API harus menyertakan header otorisasi. Untuk mengautentikasi permintaan, tanda tangani permintaan dengan kunci utama atau kunci sekunder untuk ruang kerja yang membuat permintaan. Kemudian, berikan tanda tangan tersebut sebagai bagian dari permintaan.
Berikut format untuk header otorisasi:
Authorization: SharedKey <WorkspaceID>:<Signature>
WorkspaceID adalah pengidentifikasi unik untuk ruang kerja Log Analytics. Tanda tangan adalah Kode Autentikasi Pesan Berbasis Hash (HMAC) yang dibuat dari permintaan dan kemudian dikomputasikan dengan menggunakan algoritme SHA256. Kemudian, Anda melakukan pengodean dengan menggunakan pengodean Base64.
Gunakan format ini untuk mengkodekan string tanda tangan SharedKey:
StringToSign = VERB + "\n" +
Content-Length + "\n" +
Content-Type + "\n" +
"x-ms-date:" + x-ms-date + "\n" +
"/api/logs";
Berikut ini contoh string tanda tangan:
POST\n1024\napplication/json\nx-ms-date:Mon, 04 Apr 2016 08:00:00 GMT\n/api/logs
Saat Anda memiliki string tanda tangan, kodekan dengan menggunakan algoritma HMAC-SHA256 pada string yang disandikan UTF-8, lalu kodekan hasilnya sebagai Base64. Gunakan format ini:
Signature=Base64(HMAC-SHA256(UTF8(StringToSign)))
Sampel di bagian berikutnya memiliki kode sampel untuk membantu Anda membuat header otorisasi.
Isi permintaan
Isi pesan harus dalam JSON. Isi pesan harus menyertakan satu atau beberapa rekaman dengan nama properti dan pasangan nilai dalam format berikut. Nama properti hanya boleh berisi huruf, angka, dan karakter garis bawah (_).
[
{
"property 1": "value1",
"property 2": "value2",
"property 3": "value3",
"property 4": "value4"
}
]
Anda dapat mengelompokkan beberapa rekaman bersama-sama dalam satu permintaan dengan menggunakan format berikut. Semua rekaman harus memiliki jenis rekaman yang sama.
[
{
"property 1": "value1",
"property 2": "value2",
"property 3": "value3",
"property 4": "value4"
},
{
"property 1": "value1",
"property 2": "value2",
"property 3": "value3",
"property 4": "value4"
}
]
Jenis rekaman dan properti
Anda menentukan jenis rekaman kustom saat Anda mengirimkan data melalui Azure Monitor HTTP Data Collector API. Saat ini, Anda tidak bisa menulis data ke jenis rekaman yang sudah ada yang dibuat oleh jenis data dan solusi lain. Azure Monitor membaca data yang masuk lalu membuat properti yang cocok dengan jenis data dari nilai yang Anda masukkan.
Setiap permintaan ke Data Collector API harus menyertakan header Log-Type dengan nama untuk jenis rekaman. Akhiran _CL secara otomatis ditambahkan ke nama yang Anda masukkan untuk membedakannya dari jenis log lainnya sebagai log kustom. Misalnya, jika Anda memasukkan nama MyNewRecordType, Azure Monitor membuat rekaman dengan jenis MyNewRecordType_CL. Ini membantu memastikan bahwa tidak ada konflik antara nama jenis yang dibuat pengguna dan yang dikirimkan dalam solusi Microsoft saat ini atau di masa mendatang.
Untuk mengidentifikasi jenis data properti, Azure Monitor menambahkan akhiran ke nama properti. Jika properti berisi nilai nol, properti tidak disertakan dalam rekaman tersebut. Tabel ini mencantumkan jenis data properti dan akhiran yang sesuai:
Jenis data properti | Akhiran |
---|---|
String | _s |
Boolean | _b |
Laju | _d |
Tanggal/Waktu | _t |
GUID (disimpan sebagai string) | _g |
Catatan
Nilai string yang tampak sebagai GUID diberi akhiran _g dan diformat sebagai GUID, meskipun nilai yang masuk tidak menyertakan tanda hubung. Misalnya, "8145d822-13a7-44ad-859c-36f31a84f6dd" dan "8145d82213a744ad859c36f31a84f6dd" disimpan sebagai "8145d822-13a7-44ad-859c-36f31a84f6dd". Satu-satunya perbedaan antara string ini dan string lainnya adalah _g pada nama dan penyisipan tanda hubung jika tidak disediakan dalam input.
Jenis data yang digunakan Azure Monitor untuk setiap properti bergantung pada apakah jenis rekaman untuk rekaman baru sudah ada.
- Jika jenis rekaman tidak ada, Azure Monitor membuat rekaman baru dengan menggunakan inferensi jenis JSON untuk menentukan jenis data setiap properti untuk rekaman baru.
- Jika jenis rekaman sudah ada, Azure Monitor mencoba membuat rekaman baru berdasarkan properti yang sudah ada. Jika jenis data untuk properti di rekaman baru tidak cocok dan tidak bisa dikonversi ke jenis yang sudah ada, atau jika rekaman menyertakan properti yang tidak ada, Azure Monitor membuat properti baru yang memiliki akhiran yang relevan.
Misalnya, entri pengiriman berikut akan membuat rekaman dengan tiga properti, number_d, boolean_b, dan string_s:
Jika Anda mengirimkan ini pada entri berikutnya, dengan semua nilai diformat sebagai string, properti tidak akan berubah. Anda dapat mengonversi nilai ke tipe data yang ada.
Namun, jika Anda kemudian membuat ini menjadi pengiriman berikutnya, Azure Monitor akan membuat properti baru boolean_d dan string_d. Anda tidak dapat mengonversi nilai-nilai ini.
Jika Anda kemudian mengirimkan entri berikut, sebelum jenis rekaman dibuat, Azure Monitor akan membuat rekaman dengan tiga properti, number_s, boolean_s, dan string_s. Dalam entri ini, setiap nilai awal diformat sebagai string:
Properti yang dipesan
Properti berikut dicadangkan dan tidak boleh digunakan dalam jenis rekaman kustom. Anda akan menerima pesan kesalahan jika payload Anda menyertakan salah satu dari nama properti ini:
- penyewa
- TimeGenerated
- RawData
Batasan data
Data yang diposting ke API kumpulan Data Azure Monitor tunduk pada batasan tertentu:
- Maksimum 30 MB per postingan ke Azure Monitor Data Collector API. Ini adalah batas ukuran untuk satu posting. Jika ukuran data dari satu kiriman melebihi 30 MB, Anda harus membagi data menjadi bagian yang lebih kecil dan mengirimkannya secara bersamaan.
- Maksimal 32 KB untuk nilai bidang. Jika nilai bidang lebih besar dari 32 KB, data akan dipotong.
- Jumlah maksimal bidang yang direkomendasikan untuk jenis tertentu adalah 50. Ini adalah batas praktis dari perspektif penggunaan dan pengalaman pencarian.
- Tabel di ruang kerja Analitik Log hanya mendukung hingga 500 kolom (disebut sebagai bidang dalam artikel ini).
- Maksimal 45 karakter untuk nama kolom.
Mengembalikan kode
Kode status HTTP 200 berarti bahwa permintaan telah diterima untuk diproses. Hal ini menunjukkan bahwa operasi selesai dengan sukses.
Kumpulan lengkap kode status yang mungkin dikembalikan layanan tercantum dalam tabel berikut:
Kode | Status | Kode kesalahan | Deskripsi |
---|---|---|---|
200 | OK | Permintaan berhasil diterima. | |
400 | Permintaan Buruk | InactiveCustomer | Ruang kerja telah ditutup. |
400 | Permintaan Buruk | InvalidApiVersion | Versi API yang Anda tentukan tidak dikenali oleh layanan. |
400 | Permintaan Buruk | InvalidCustomerId | ID ruang kerja yang ditentukan tidak valid. |
400 | Permintaan Buruk | InvalidDataFormat | JSON yang tidak valid telah dikirimkan. Isi respons mungkin berisi informasi lebih lanjut cara mengatasi kesalahan. |
400 | Permintaan Buruk | InvalidLogType | Jenis log yang ditentukan berisi karakter atau angka khusus. |
400 | Permintaan Buruk | MissingApiVersion | Versi API tidak ditentukan. |
400 | Permintaan Buruk | MissingContentType | Jenis konten tidak ditentukan. |
400 | Permintaan Buruk | MissingLogType | Jenis log nilai yang diperlukan tidak ditentukan. |
400 | Permintaan Buruk | UnsupportedContentType | Jenis konten tidak diatur ke application/json. |
403 | Terlarang | InvalidAuthorization | Layanan gagal mengautentikasi permintaan. Verifikasi bahwa ID ruang kerja dan kunci koneksi valid. |
404 | Tidak Ditemukan | URL yang diberikan salah atau permintaan terlalu besar. | |
429 | Terlalu Banyak Permintaan | Layanan mengalami volume data yang tinggi dari akun Anda. Silakan coba lagi permintaan nanti. | |
500 | Kesalahan Server Internal | UnspecifiedError | Layanan mengalami kesalahan internal. Silakan coba lagi permintaannya. |
503 | Layanan Tidak Tersedia | ServiceUnavailable | Layanan saat ini tidak tersedia untuk menerima permintaan. Silakan coba lagi permintaan Anda. |
Mengkueri data
Untuk membuat kueri data yang dikirimkan oleh Azure Monitor HTTP Data Collector API, cari rekaman yang Type-nya sama dengan nilai LogType yang Anda tentukan dan tambahkan dengan _CL. Misalnya, jika Anda menggunakan MyCustomLog, Anda akan mengembalikan semua rekaman dengan MyCustomLog_CL
.
Sampel permintaan
Di bagian ini adalah sampel yang menunjukkan cara mengirimkan data ke API Pengumpul Data HTTP Azure Monitor dengan menggunakan berbagai bahasa pemrograman.
Untuk setiap sampel, atur variabel untuk header otorisasi dengan melakukan hal berikut:
- Di portal Azure, temukan ruang kerja Log Analytics Anda.
- Pilih Agen.
- Di sebelah kanan ID Ruang Kerja, pilih ikon Salin, lalu tempel ID sebagai nilai variabel ID Pelanggan.
- Di sebelah kanan Kunci Primer, pilih ikon Salin, lalu tempel ID sebagai nilai variabel Kunci Bersama.
Atau, Anda dapat mengubah variabel untuk jenis log dan data JSON.
# Replace with your Workspace ID
$CustomerId = "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
# Replace with your Primary Key
$SharedKey = "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
# Specify the name of the record type that you'll be creating
$LogType = "MyRecordType"
# Optional name of a field that includes the timestamp for the data. If the time field is not specified, Azure Monitor assumes the time is the message ingestion time
$TimeStampField = ""
# Create two records with the same set of properties to create
$json = @"
[{ "StringValue": "MyString1",
"NumberValue": 42,
"BooleanValue": true,
"DateValue": "2019-09-12T20:00:00.625Z",
"GUIDValue": "9909ED01-A74C-4874-8ABF-D2678E3AE23D"
},
{ "StringValue": "MyString2",
"NumberValue": 43,
"BooleanValue": false,
"DateValue": "2019-09-12T20:00:00.625Z",
"GUIDValue": "8809ED01-A74C-4874-8ABF-D2678E3AE23D"
}]
"@
# Create the function to create the authorization signature
Function Build-Signature ($customerId, $sharedKey, $date, $contentLength, $method, $contentType, $resource)
{
$xHeaders = "x-ms-date:" + $date
$stringToHash = $method + "`n" + $contentLength + "`n" + $contentType + "`n" + $xHeaders + "`n" + $resource
$bytesToHash = [Text.Encoding]::UTF8.GetBytes($stringToHash)
$keyBytes = [Convert]::FromBase64String($sharedKey)
$sha256 = New-Object System.Security.Cryptography.HMACSHA256
$sha256.Key = $keyBytes
$calculatedHash = $sha256.ComputeHash($bytesToHash)
$encodedHash = [Convert]::ToBase64String($calculatedHash)
$authorization = 'SharedKey {0}:{1}' -f $customerId,$encodedHash
return $authorization
}
# Create the function to create and post the request
Function Post-LogAnalyticsData($customerId, $sharedKey, $body, $logType)
{
$method = "POST"
$contentType = "application/json"
$resource = "/api/logs"
$rfc1123date = [DateTime]::UtcNow.ToString("r")
$contentLength = $body.Length
$signature = Build-Signature `
-customerId $customerId `
-sharedKey $sharedKey `
-date $rfc1123date `
-contentLength $contentLength `
-method $method `
-contentType $contentType `
-resource $resource
$uri = "https://" + $customerId + ".ods.opinsights.azure.com" + $resource + "?api-version=2016-04-01"
$headers = @{
"Authorization" = $signature;
"Log-Type" = $logType;
"x-ms-date" = $rfc1123date;
"time-generated-field" = $TimeStampField;
}
$response = Invoke-WebRequest -Uri $uri -Method $method -ContentType $contentType -Headers $headers -Body $body -UseBasicParsing
return $response.StatusCode
}
# Submit the data to the API endpoint
Post-LogAnalyticsData -customerId $customerId -sharedKey $sharedKey -body ([System.Text.Encoding]::UTF8.GetBytes($json)) -logType $logType
Alternatif dan pertimbangan
Meskipun Data Collector API harus mencakup sebagian besar kebutuhan Anda saat Anda mengumpulkan data bentuk bebas ke dalam Azure Logs, Anda mungkin memerlukan pendekatan alternatif untuk mengatasi beberapa keterbatasan API. Pilihan Anda, termasuk pertimbangan utama, tercantum dalam tabel berikut:
Alternatif | Deskripsi | Paling cocok untuk |
---|---|---|
Peristiwa kustom: Penyerapan berbasis SDK bawaan di Application Insights | Application Insights, yang biasanya dilengkapi melalui SDK dalam aplikasi Anda, memberi Anda kemampuan untuk mengirim data khusus melalui Kejadian Khusus. |
|
Data Collector API di Azure Monitor Logs | Data Collector API di Azure Monitor Logs adalah cara yang sepenuhnya terbuka untuk menyerap data. Data apa pun yang diformat dalam objek JSON dapat dikirim ke sini. Setelah dikirim, data diproses dan tersedia di Log Monitor untuk dikorelasikan dengan data lain di Log Monitor atau dengan data Application Insights lainnya. Mengunggah data sebagai file ke blob Azure Blob Storage itu cukup mudah, di mana file akan diproses dan kemudian diunggah ke Analitik Log. Untuk implementasi sampel, lihat Membuat alur data dengan API Pengumpul Data. |
|
Azure Data Explorer | Azure Data Explorer, yang kini tersedia secara umum, adalah platform data yang mendukung Analitik Application Insights dan Log Azure Monitor. Dengan menggunakan platform data dalam bentuk mentahnya, Anda memiliki fleksibilitas penuh (tetapi memerlukan manajemen overhead) di atas kluster (kontrol akses berbasis peran (RBAC) Kubernetes, tingkat retensi, skema, dan sebagainya). Azure Data Explorer menyediakan banyak opsi penyerapan, termasuk file CSV, TSV, dan JSON. |
|
Langkah berikutnya
Gunakan Log Search API untuk mengambil data dari ruang kerja Log Analytics.
Pelajari lebih lanjut cara membuat alur data dengan Data Collector API menggunakan alur kerja Logic Apps ke Azure Monitor.