Pengelogan Azure Storage analytics

  • Artikel

Storage Analytics mencatat informasi mendetail tentang permintaan yang berhasil dan gagal ke layanan penyimpanan. Informasi ini dapat digunakan untuk memantau setiap permintaan dan mendiagnosis masalah dengan layanan penyimpanan. Permintaan dicatat di log dengan 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 Azure Storage di Azure Monitor alih-alih log Storage Analytics. 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 dicatat di log:

  • Permintaan berhasil

  • Permintaan yang gagal, termasuk waktu habis, pembatasan, jaringan, otorisasi, dan kesalahan lainnya

  • Permintaan yang menggunakan Tanda Tangan Akses Bersama (SAS) atau OAuth, termasuk permintaan yang gagal dan berhasil

  • Permintaan ke data analitik

    Permintaan yang dibuat oleh Storage Analytics itu sendiri, seperti pembuatan log atau penghapusan, tidak dicatat. Daftar lengkap data yang dicatat didokumentasikan dalam topik Operasi Pengelogan dan Pesan Status Storage Analytics serta Format Log Storage Analytics.

Mencatat permintaan anonim

Jenis permintaan anonim berikut ini dicatat di log:

Catatan

Storage Analytics mencatat semua panggilan ke data plane. Panggilan dari Penyedia Sumber Daya Azure Storage juga dicatat. Untuk mengidentifikasi permintaan ini, cari untai (karakter) kueri <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&amp;sig=XXXXX&amp;sp=rwl&amp;sr=c&amp;sv=2020-04-08&amp;timeout=901;"/logsamples/container1/1.txt";xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx;0;71.197.193.44:53371;2019-12-12;654;13;337;0;13;"xxxxxxxxxxxxxxxxxxxxx==";"xxxxxxxxxxxxxxxxxxxxx==";"&quot;0x8D9CEF88004E296&quot;";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 Gen2 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;73.157.16.8;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&amp;peekonly=true&amp;timeout=30;"/logsamples/queue1";xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx;0;71.197.193.44: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;71.197.193.44: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"

Langkah berikutnya