Pengelogan Azure Storage Analytics
Storage Analytics mencatat informasi mendetail tentang permintaan yang berhasil dan gagal ke layanan penyimpanan. Informasi ini dapat digunakan untuk memantau permintaan individu dan mendiagnosis masalah dengan layanan penyimpanan. Permintaan dicatat di log dengan basis upaya terbaik. Ini artinya sebagian besar permintaan akan menghasilkan rekaman log, tetapi kelengkapan dan ketepatan waktu log Storage Analytics tidak dijamin.
Catatan
Kami menyarankan agar Anda menggunakan log Microsoft Azure Storage di Azure Monitor alih-alih log Analitik Penyimpanan. Untuk mempelajari selengkapnya, lihat salah satu artikel berikut ini:
Pengelogan Storage Analytics tidak diaktifkan secara default untuk akun penyimpanan. Anda dapat mengaktifkannya di portal Azure atau dengan menggunakan PowerShell, atau Azure CLI. Untuk panduan langkah demi langkah, lihat Aktifkan dan kelola log Azure Storage Analytics (klasik).
Anda juga dapat mengaktifkan Storage Analytics secara terprogram melalui REST API atau pustaka klien. Gunakan operasi Get Blob Service Properties, Get Queue Service Properties, dan Get Table Service Properties untuk mengaktifkan Storage Analytics ke setiap layanan. Untuk melihat contoh yang mengaktifkan log Storage Analytics dengan menggunakan .NET, lihat Aktifkan log
Entri log hanya dibuat jika ada permintaan yang dibuat terhadap titik akhir layanan. Misalnya, jika akun penyimpanan memiliki aktivitas di titik akhir Blob tetapi tidak di titik akhir Table atau Queue, hanya log yang berkaitan dengan layanan Blob yang dibuat.
Catatan
Pembuatan log Analitik Penyimpanan saat ini hanya tersedia untuk layanan Blob, Antrian, dan Tabel. Pengelogan Storage Analytics juga tersedia untuk akun BlockBlobStorage performa premium. Namun, itu tidak tersedia untuk akun tujuan umum v2 dengan performa premium.
Permintaan dicatat dalam pengelogan
Mencatat permintaan autentik
Jenis permintaan yang diautentikasi berikut ini dicatat:
Permintaan berhasil
Permintaan gagal, termasuk waktu habis, pembatasan, jaringan, otorisasi, dan kesalahan lainnya
Permintaan menggunakan Tanda Tangan Akses Bersama (SAS) atau OAuth, termasuk permintaan yang gagal dan berhasil
Permintaan ke data analitik
Permintaan yang dibuat oleh Analitik Penyimpanan itu sendiri, seperti pembuatan log atau penghapusan, tidak dicatat. Daftar lengkap data yang dicatat didokumentasikan dalam topik Operasi dan Pesan Status Analitik Penyimpanan Dilog serta Format Log Analitik Penyimpanan.
Mencatat permintaan anonim
Jenis permintaan anonim berikut ini dicatat di log:
Permintaan berhasil
Kesalahan server
Kesalahan timeout untuk klien dan server
Permintaan GET gagal dengan kode galat 304 (Tidak Diubah)
Semua permintaan anonim lainnya yang gagal tidak dicatat di log. Daftar lengkap data yang dicatat didokumentasikan dalam topik Operasi dan Pesan Status Analitik Penyimpanan Dilog serta Format Log Analitik Penyimpanan.
Catatan
Storage Analytics mencatat semua panggilan ke {i>data plane<sk=system-1> di URL permintaan.
Bagaimana log disimpan
Semua log disimpan dalam blob blok dalam kontainer bernama $logs
, yang secara otomatis dibuat saat Storage Analytics diaktifkan untuk akun penyimpanan. Kontainer $logs
terletak di namespace blob akun penyimpanan, misalnya: http://<accountname>.blob.core.windows.net/$logs
. Kontainer ini tidak dapat dihapus setelah Storage Analytics diaktifkan, meski kontennya dapat dihapus. Jika menggunakan alat peramban penyimpanan untuk membuka kontainer secara langsung, Anda akan melihat semua blob yang berisi data pencatatan Anda.
Catatan
Kontainer $logs
tidak ditampilkan ketika operasi cantumkan kontainer dilakukan, seperti operasi Cantumkan Kontainer. Itu harus diakses secara langsung. Misalnya, Anda dapat menggunakan operasi Cantumkan Blob untuk mengakses blob dalam kontainer $logs
.
Saat permintaan dicatat, Storage Analytics akan mengunggah hasil menengah sebagai blok. Secara berkala, Storage Analytics akan menerapkan blok ini dan membuatnya tersedia sebagai blob. Dibutuhkan waktu hingga satu jam agar data log muncul dalam gumpalan di kontainer $logs berdasarkan frekuensi layanan penyimpanan menyiram penulis log. Rekaman duplikat mungkin ada untuk log yang dibuat dalam jam yang sama. Anda dapat menentukan apakah rekaman itu duplikat dengan memeriksa nomor RequestId dan Operasi.
Jika Anda memiliki data log dalam volume tinggi dengan banyak file setiap jam, maka Anda dapat menggunakan metadata blob untuk menentukan data apa yang dikandung log dengan memeriksa bidang metadata blob. Ini juga berguna karena terkadang ada penundaan selagi data ditulis ke file log: metadata blob memberikan indikasi yang lebih akurat dari konten blob daripada nama blob.
Sebagian besar alat peramban penyimpanan memungkinkan Anda untuk melihat metadata blob; Anda juga dapat membaca informasi ini menggunakan PowerShell atau secara terprogram. Cuplikan PowerShell berikut adalah contoh filter daftar blob log menurut nama untuk menentukan waktu, dan menurut metadata untuk mengidentifikasi hanya log yang berisi operasi tulis.
Get-AzStorageBlob -Container '$logs' |
Where-Object {
$_.Name -match 'blob/2014/05/21/05' -and
$_.ICloudBlob.Metadata.LogType -match 'write'
} |
ForEach-Object {
"{0} {1} {2} {3}" -f $_.Name,
$_.ICloudBlob.Metadata.StartTime,
$_.ICloudBlob.Metadata.EndTime,
$_.ICloudBlob.Metadata.LogType
}
Untuk informasi tentang mencantumkan blob secara terprogram, lihat Enumerasi Sumber Daya Blob dan Mengatur dan Mengambil Properti dan Metadata untuk Sumber Daya Blob.
Konvensi penamaan log
Setiap log akan ditulis dalam format berikut:
<service-name>/YYYY/MM/DD/hhmm/<counter>.log
Tabel berikut ini menjelaskan setiap atribut dalam nama log:
Atribut | Deskripsi |
---|---|
<service-name> |
Nama layanan penyimpanan. Misalnya: blob , table , atau queue |
YYYY |
Empat digit tahun untuk log. Misalnya: 2011 |
MM |
Dua digit bulan untuk log. Misalnya: 07 |
DD |
Dua digit hari untuk log. Misalnya: 31 |
hh |
Dua digit jam yang menunjukkan jam mulai log, dalam format UTC 24 jam. Misalnya: 18 |
mm |
Dua digit angka yang menunjukkan menit awal untuk log. Catatan: Nilai ini tidak didukung dalam versi Analitik Penyimpanan saat ini, dan nilainya akan selalu 00 . |
<counter> |
Penghitung berbasis nol dengan enam digit yang menunjukkan jumlah blob log yang dihasilkan untuk layanan penyimpanan dalam periode waktu satu jam. Penghitung ini dimulai dari 000000 . Misalnya: 000001 |
Berikut ini adalah sampel nama log lengkap yang menggabungkan contoh di atas:
blob/2011/07/31/1800/000001.log
Berikut ini adalah sampel URI yang dapat digunakan untuk mengakses log di atas:
https://<accountname>.blob.core.windows.net/$logs/blob/2011/07/31/1800/000001.log
Ketika permintaan penyimpanan dicatat, nama log yang dihasilkan berkorelasi dengan jam ketika operasi yang diminta selesai. Misalnya, jika permintaan GetBlob selesai pukul 18:30 pada 31/7/2011, log akan ditulis dengan awalan berikut: blob/2011/07/31/1800/
Metadata log
Semua blob log disimpan dengan metadata yang dapat digunakan untuk mengidentifikasi data pengelogan apa yang dikandung blob. Tabel berikut ini menjelaskan setiap atribut metadata:
Atribut | Deskripsi |
---|---|
LogType |
Menjelaskan apakah log berisi informasi yang berkaitan dengan operasi baca, tulis, atau hapus. Nilai ini dapat mencakup satu jenis atau kombinasi ketiganya, dipisahkan dengan koma. Contoh 1: write Contoh 2: read,write Contoh 3: read,write,delete |
StartTime |
Waktu awal entri dalam log, dalam bentuk YYYY-MM-DDThh:mm:ssZ . Misalnya: 2011-07-31T18:21:46Z |
EndTime |
Waktu akhir entri dalam log, dalam bentuk YYYY-MM-DDThh:mm:ssZ . Misalnya: 2011-07-31T18:22:09Z |
LogVersion |
Versi format log. |
Daftar berikut menampilkan metadata sampel lengkap menggunakan contoh di atas:
LogType=write
StartTime=2011-07-31T18:21:46Z
EndTime=2011-07-31T18:22:09Z
LogVersion=1.0
Entri log
Bagian berikut ini memperlihatkan contoh entri log untuk setiap layanan Azure Storage yang didukung.
Contoh entri log untuk Blob Storage
2.0;2022-01-03T20:34:54.4617505Z;PutBlob;SASSuccess;201;7;7;sas;;logsamples;blob;https://logsamples.blob.core.windows.net/container1/1.txt?se=2022-02-02T20:34:54Z&sig=XXXXX&sp=rwl&sr=c&sv=2020-04-08&timeout=901;"/logsamples/container1/1.txt";xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx;0;172.16.0.0:53371;2019-12-12;654;13;337;0;13;"xxxxxxxxxxxxxxxxxxxxx==";"xxxxxxxxxxxxxxxxxxxxx==";""0x8D9CEF88004E296"";Monday, 03-Jan-22 20:34:54 GMT;;"Microsoft Azure Storage Explorer, 1.20.1, win32, azcopy-node, 2.0.0, win32, AzCopy/10.11.0 Azure-Storage/0.13 (go1.15; Windows_NT)";;"xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx";;;;;;;;
Contoh entri log untuk Blob Storage (Data Lake Storage diaktifkan)
2.0;2022-01-04T22:50:56.0000775Z;RenamePathFile;Success;201;49;49;authenticated;logsamples;logsamples;blob;"https://logsamples.dfs.core.windows.net/my-container/myfileorig.png?mode=legacy";"/logsamples/my-container/myfilerenamed.png";xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx;0;172.16.0.0;2020-04-08;591;0;224;0;0;;;;Friday, 11-Jun-21 17:58:15 GMT;;"Microsoft Azure Storage Explorer, 1.19.1, win32 azsdk-js-storagedatalake/12.3.1 (NODE-VERSION v12.16.3; Windows_NT 10.0.22000)";;"xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx";;;;;;;;
Contoh entri log untuk Queue Storage
2.0;2022-01-03T20:35:04.6097590Z;PeekMessages;Success;200;5;5;authenticated;logsamples;logsamples;queue;https://logsamples.queue.core.windows.net/queue1/messages?numofmessages=32&peekonly=true&timeout=30;"/logsamples/queue1";xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx;0;172.16.0.0:53385;2020-04-08;536;0;232;62;0;;;;;;"Microsoft Azure Storage Explorer, 1.20.1, win32 azsdk-js-storagequeue/12.3.1 (NODE-VERSION v12.16.3; Windows_NT 10.0.22000)";;"xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx";;;;;;;;
Contoh entri log untuk Table Storage
1.0;2022-01-03T20:35:13.0719766Z;CreateTable;Success;204;30;30;authenticated;logsamples;logsamples;table;https://logsamples.table.core.windows.net/Tables;"/logsamples/Table1";xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx;0;172.16.0.0:53389;2018-03-28;601;22;339;0;22;;;;;;"Microsoft Azure Storage Explorer, 1.20.1, win32, Azure-Storage/2.10.3 (NODE-VERSION v12.16.3; Windows_NT 10.0.22000)";;"xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx"