Log diagnostik untuk Application Gateway
Log Application Gateway menyediakan informasi terperinci untuk peristiwa yang terkait dengan sumber daya dan operasinya. Log ini tersedia untuk peristiwa seperti Akses, Aktivitas, Firewall, dan Performa (hanya untuk V1). Informasi terperinci dalam log sangat membantu saat memecahkan masalah atau membangun dasbor analitik dengan menggunakan data mentah ini.
Log tersedia untuk semua sumber daya Application Gateway; namun, untuk mengonsumsinya, Anda harus mengaktifkan koleksinya di lokasi penyimpanan pilihan Anda. Pengelogan di Azure Application Gateway diaktifkan oleh layanan Azure Monitor. Sebaiknya gunakan ruang kerja Analitik Log karena Anda dapat dengan mudah menggunakan kueri yang telah ditentukan sebelumnya dan mengatur pemberitahuan berdasarkan kondisi log tertentu.
Jenis log Diagnostik
Anda dapat menggunakan berbagai jenis log di Azure untuk mengelola dan memecahkan masalah gateway aplikasi. Anda dapat mempelajari lebih lanjut tentang jenis-jenis ini di bawah ini:
- Log aktivitas: Anda dapat menggunakan log aktivitas Azure (sebelumnya dikenal sebagai log operasional dan log audit) untuk melihat semua operasi yang dikirimkan ke langganan Azure Anda, dan statusnya. Entri log aktivitas dikumpulkan secara default, dan Anda dapat melihatnya di portal Microsoft Azure.
- Log akses: Anda dapat menggunakan log ini untuk melihat pola akses Application Gateway dan menganalisis informasi penting. Ini termasuk IP penelepon, URL yang diminta, latensi respons, kode pengembalian, serta byte masuk dan keluar. Log akses dikumpulkan setiap 60 detik. Log ini berisi satu catatan per instans Application Gateway. Instans Application Gateway diidentifikasi menurut properti Id instans.
- Log performa: Anda dapat menggunakan log ini untuk melihat performa instans Application Gateway. Log ini menangkap informasi performa untuk setiap instans, termasuk total permintaan yang dilayani, throughput dalam byte, total permintaan yang dilayani, jumlah permintaan yang gagal, dan jumlah instans backend yang sehat dan tidak sehat. Log performa dikumpulkan setiap 60 detik. Log Performa hanya tersedia untuk SKU v1. Untuk SKU v2, gunakan Metrik untuk data performa.
- Log firewall: Anda dapat menggunakan log ini untuk melihat permintaan yang dicatat melalui mode deteksi atau pencegahan gateway aplikasi yang terkonfigurasi dengan firewall aplikasi web. Log firewall dikumpulkan setiap 60 detik.
Catatan
Log hanya tersedia untuk sumber daya yang disebarkan dalam model penyebaran Azure Resource Manager. Anda tidak dapat menggunakan log untuk sumber daya dalam model penyebaran klasik. Untuk pemahaman yang lebih baik tentang dua model ini, lihat artikel Memahami penyebaran Resource Manager dan penyebaran klasik.
Lokasi penyimpanan
Anda memiliki opsi berikut untuk menyimpan log di lokasi pilihan Anda.
Ruang kerja Analitik Log: Opsi ini memungkinkan Anda menggunakan kueri, visualisasi, dan mengatur pemberitahuan yang telah ditentukan sebelumnya berdasarkan kondisi log tertentu. Tabel yang digunakan oleh log sumber daya di ruang kerja analitik log bergantung pada jenis pengumpulan sumber daya apa yang digunakan:
Diagnostik Azure: Data ditulis ke tabel Diagnostik Azure. Tabel Diagnostik Azure dibagikan di antara beberapa jenis sumber daya, dengan masing-masing dari mereka menambahkan bidang kustom mereka sendiri. Ketika jumlah bidang kustom yang diserap ke tabel Azure Diagnostics melebihi 500, bidang baru tidak ditambahkan sebagai tingkat atas tetapi ditambahkan ke bidang "AdditionalFields" sebagai pasangan nilai kunci dinamis.
Khusus sumber daya(disarankan): Data ditulis ke tabel khusus untuk setiap kategori sumber daya. Dalam mode khusus sumber daya, setiap kategori log yang dipilih dalam pengaturan diagnostik ditetapkan tabelnya sendiri dalam ruang kerja yang dipilih. Ini memiliki beberapa manfaat, termasuk:
- Manipulasi data yang lebih mudah dalam kueri log
- Peningkatan kemampuan penemuan skema dan strukturnya
- Peningkatan performa dalam hal latensi penyerapan dan waktu kueri
- Kemampuan untuk menetapkan hak kontrol akses berbasis peran Azure ke tabel tertentu
Untuk Application Gateway, mode khusus sumber daya membuat tiga tabel:
Catatan
Opsi spesifik sumber daya saat ini tersedia di semua wilayah publik.
Pengguna yang ada dapat terus menggunakan Azure Diagnostics, atau dapat memilih tabel khusus dengan mengalihkan pengalih di Pengaturan diagnostik ke Sumber Daya khusus, atau ke Khusus di tujuan API. Mode ganda tidak dimungkinkan. Data di semua log dapat mengalir ke Azure Diagnostics, atau ke tabel khusus. Namun, Anda dapat memiliki beberapa pengaturan diagnostik di mana satu aliran data adalah ke diagnostik azure dan yang lain menggunakan sumber daya khusus secara bersamaan.
Memilih tabel tujuan di Analitik log : Semua layanan Azure akhirnya menggunakan tabel khusus sumber daya. Sebagai bagian dari transisi ini, Anda dapat memilih diagnostik Azure atau tabel khusus sumber daya dalam pengaturan diagnostik menggunakan tombol alih. Pengalih diatur ke Sumber Daya khusus secara default dan dalam mode ini, log untuk kategori baru yang dipilih dikirim ke tabel khusus di Log Analytics, sementara aliran yang ada tetap tidak berubah. Lihat contoh berikut.
Transformasi Ruang Kerja: Memilih opsi Khusus sumber daya memungkinkan Anda memfilter dan memodifikasi data Sebelum diserap dengan transformasi ruang kerja. Ini memberikan kontrol terperinci, memungkinkan Anda untuk fokus pada informasi yang paling relevan dari log di sana dengan mengurangi biaya data dan meningkatkan keamanan. Untuk instruksi terperinci tentang menyiapkan transformasi ruang kerja, silakan lihat:Tutorial: Menambahkan transformasi ruang kerja ke Log Azure Monitor dengan menggunakan portal Azure.
Contoh mengoptimalkan log akses menggunakan Transformasi Ruang Kerja
Contoh 1: Proyeksi Selektif Kolom: Bayangkan Anda memiliki log akses gateway aplikasi dengan 20 kolom, tetapi Anda tertarik untuk menganalisis data hanya dari 6 kolom tertentu. Dengan menggunakan transformasi ruang kerja, Anda dapat memproyeksikan 6 kolom ini ke ruang kerja Anda, secara efektif tidak termasuk 14 kolom lainnya. Meskipun data asli dari kolom yang dikecualikan tidak akan disimpan, tempat penampung kosong untuk mereka masih muncul di bilah Log. Pendekatan ini mengoptimalkan penyimpanan dan memastikan bahwa hanya data yang relevan yang disimpan untuk analisis.
Catatan
Dalam bilah Log, memilih opsi Coba Analitik Log Baru memberikan kontrol yang lebih besar atas kolom yang ditampilkan di antarmuka pengguna Anda.
Contoh 2: Berfokus pada Kode Status Tertentu: Saat menganalisis log akses, alih-alih memproses semua entri log, Anda dapat menulis kueri untuk hanya mengambil baris dengan kode status HTTP tertentu (seperti 4xx dan 5xx). Karena sebagian besar permintaan idealnya termasuk dalam kategori 2xx dan 3xx (mewakili respons yang berhasil), berfokus pada kode status bermasalah mempersempit himpunan data. Pendekatan yang ditargetkan ini memungkinkan Anda untuk mengekstrak informasi yang paling relevan dan dapat ditindaklanjuti, sehingga bermanfaat dan hemat biaya.
Strategi transisi yang direkomendasikan untuk berpindah dari diagnostik Azure ke tabel spesifik sumber daya:
- Menilai retensi data saat ini: Tentukan durasi data yang saat ini disimpan dalam tabel diagnostik Azure (misalnya: asumsikan tabel diagnostik menyimpan data selama 15 hari).
- Membuat retensi khusus sumber daya: Terapkan pengaturan Diagnostik baru dengan tabel spesifik sumber daya.
- Pengumpulan data paralel: Untuk periode sementara, kumpulkan data secara bersamaan di Azure Diagnostics dan pengaturan khusus sumber daya.
- Konfirmasikan akurasi data: Verifikasi bahwa pengumpulan data akurat dan konsisten di kedua pengaturan.
- Menghapus pengaturan diagnostik Azure: Hapus pengaturan Diagnostik Azure untuk mencegah pengumpulan data duplikat.
Lokasi penyimpanan lainnya:
- Akun Azure Storage: Akun penyimpanan paling baik digunakan untuk log saat log disimpan untuk durasi yang lebih lama dan ditinjau saat diperlukan.
- Azure Event Hubs: Azure Event Hubs adalah opsi yang bagus untuk mengintegrasikan dengan alat informasi keamanan dan manajemen peristiwa (SIEM) lainnya untuk mendapatkan pemberitahuan tentang sumber daya Anda.
- Integrasi mitra Azure Monitor.
Pelajari selengkapnya tentang tujuan pengaturan diagnostik Azure Monitor .
Aktifkan pengelogan dengan PowerShell
Pembuatan log aktivitas diaktifkan secara otomatis untuk setiap sumber daya Resource Manager. Anda harus mengaktifkan akses dan pengelogan performa untuk mulai mengumpulkan data yang tersedia dalam log tersebut. Untuk mengaktifkan pengelogan, gunakan langkah berikut:
Perhatikan ID sumber daya akun penyimpanan Anda, tempat data log disimpan. Nilai ini dalam bentuk formulir: /subscriptions/<subscriptionId>/resourceGroups/<nama grup sumber daya>/providers/Microsoft.Storage/storageAccounts/<nama akun penyimpanan>. Anda dapat menggunakan akun penyimpanan apa pun di langganan Anda. Anda dapat menggunakan portal Microsoft Azure untuk melihat informasi ini.
Perhatikan ID sumber daya gateway aplikasi Anda yang pengelogannya aktif. Nilai ini dalam bentuk formulir: /subscriptions/<subscriptionId>/resourceGroups/<nama grup sumber daya>/providers/Microsoft.Network/applicationGateways/<nama gateway aplikasi>. Anda dapat menggunakan portal untuk melihat informasi ini.
Aktifkan log diagnostik dengan menggunakan cmdlet PowerShell berikut ini:
Set-AzDiagnosticSetting -ResourceId /subscriptions/<subscriptionId>/resourceGroups/<resource group name>/providers/Microsoft.Network/applicationGateways/<application gateway name> -StorageAccountId /subscriptions/<subscriptionId>/resourceGroups/<resource group name>/providers/Microsoft.Storage/storageAccounts/<storage account name> -Enabled $true
Tip
Log aktivitas tidak memerlukan akun penyimpanan terpisah. Penggunaan penyimpanan untuk log akses dan performa dikenakan biaya layanan.
Aktifkan pengelogan melalui portal Microsoft Azure
Di portal Microsoft Azure, temukan sumber daya Anda dan pilih Pengaturan diagnostik.
Untuk Application Gateway, tersedia tiga log:
- Log akses
- Log performa
- Log firewall
Untuk mulai mengumpulkan data, Aktifkan diagnostik.
Halaman Pengaturan diagnostik menyediakan pengaturan untuk log diagnostik. Pada contoh ini, Log Analitik menyimpan log. Anda juga dapat menggunakan hub peristiwa dan akun penyimpanan untuk menyimpan log diagnostik.
Ketik nama untuk pengaturan, konfirmasikan pengaturan, dan pilih Simpan.
Log aktivitas
Azure menghasilkan log aktivitas secara default. Log ini disimpan selama 90 hari di penyimpanan log peristiwa Azure. Pelajari selengkapnya tentang log ini dengan membaca artikel Melihat log peristiwa dan log aktivitas.
Log akses
Log akses dibuat hanya jika Anda telah mengaktifkannya pada setiap instans Application Gateway, sebagaimana terperinci dalam langkah sebelumnya. Data disimpan di akun penyimpanan yang Anda tentukan saat Anda mengaktifkan pengelogan. Setiap akses Application Gateway dicatat dalam format JSON seperti yang ditunjukkan di bawah ini.
Untuk Application Gateway dan WAF SKU v2
Catatan
Untuk informasi terkait proksi TLS/TCP, kunjungi referensi data.
| Nilai | Deskripsi |
|---|---|
| instansId | Instans Application Gateway yang melayani permintaan. |
| clientIP | IP klien langsung Application Gateway. Jika proksi lain menghadap gateway aplikasi Anda, ini menampilkan IP proksi fronting tersebut. |
| httpMethod | Metode HTTP yang digunakan oleh permintaan. |
| requestUri | URI permintaan yang diterima. |
| UserAgent | Agen pengguna dari header permintaan HTTP. |
| httpStatus | Kode status HTTP yang dikembalikan ke klien dari Application Gateway. |
| httpVersion | Versi HTTP permintaan. |
| receivedBytes | Ukuran paket yang diterima, dalam byte. |
| sentBytes | Ukuran paket yang dikirim, dalam byte. |
| clientResponseTime | Perbedaan waktu (dalam detik) antara byte pertama dan gateway aplikasi byte terakhir yang dikirim ke klien. Berguna dalam mengukur waktu pemrosesan Application Gateway untuk respons atau klien yang lambat. |
| timeTaken | Lamanya waktu (dalam detik) yang diperlukan agar byte pertama permintaan klien diproses dan byte terakhirnya dikirim sebagai respons terhadap klien. Penting untuk diperhatikan bahwa bidang Time-Taken biasanya mencakup waktu paket permintaan dan respons melintasi jaringan. |
| WAFEvaluationTime | Lamanya waktu (dalam detik) yang diperlukan agar permintaan diproses oleh WAF. |
| WAFMode | Nilai dapat berupa Deteksi atau Pencegahan |
| transactionId | Pengidentifikasi unik untuk menghubungkan permintaan yang diterima dari klien |
| sslEnabled | Apakah komunikasi ke kumpulan backend menggunakan TLS. Nilai yang valid yaitu aktif dan nonaktif. |
| sslCipher | Cipher suite yang sedang digunakan untuk komunikasi TLS (jika TLS aktif). |
| sslProtocol | Protokol SSL/TLS yang sedang digunakan (jika TLS aktif). |
| serverRouted | Server ujung belakang tempat gateway aplikasi merutekan permintaan. |
| serverStatus | Kode status HTTP server ujung belakang. |
| serverResponseLatency | Latensi respons (dalam detik) dari server ujung belakang. |
| tuan rumah | Alamat yang tercantum di header host permintaan. Jika ditulis ulang menggunakan regenerasi header, bidang ini berisi nama host yang diperbarui |
| originalRequestUriWithArgs | Bidang ini berisi URL permintaan awal |
| requestUri | Bidang ini berisi URL setelah operasi regenerasi pada Application Gateway |
| upstreamSourcePort | Port sumber yang digunakan oleh Application Gateway saat memulai koneksi ke target backend |
| originalHost | Bidang ini berisi nama host permintaan awal |
| error_info | Alasan kesalahan 4xx dan 5xx. Menampilkan kode kesalahan untuk permintaan yang gagal. Detail selengkapnya dalam Informasi kode kesalahan. |
| contentType | Jenis konten atau data yang sedang diproses atau dikirimkan oleh gateway aplikasi |
{
"timeStamp": "2021-10-14T22:17:11+00:00",
"resourceId": "/SUBSCRIPTIONS/{subscriptionId}/RESOURCEGROUPS/{resourceGroupName}/PROVIDERS/MICROSOFT.NETWORK/APPLICATIONGATEWAYS/{applicationGatewayName}",
"listenerName": "HTTP-Listener",
"ruleName": "Storage-Static-Rule",
"backendPoolName": "StaticStorageAccount",
"backendSettingName": "StorageStatic-HTTPS-Setting",
"operationName": "ApplicationGatewayAccess",
"category": "ApplicationGatewayAccessLog",
"properties": {
"instanceId": "appgw_2",
"clientIP": "185.42.129.24",
"clientPort": 45057,
"httpMethod": "GET",
"originalRequestUriWithArgs": "\/",
"requestUri": "\/",
"requestQuery": "",
"userAgent": "Mozilla\/5.0 (Windows NT 6.1; WOW64) AppleWebKit\/537.36 (KHTML, like Gecko) Chrome\/52.0.2743.116 Safari\/537.36",
"httpStatus": 200,
"httpVersion": "HTTP\/1.1",
"receivedBytes": 184,
"sentBytes": 466,
"clientResponseTime": 0,
"timeTaken": 0.034,
"WAFEvaluationTime": "0.000",
"WAFMode": "Detection",
"transactionId": "592d1649f75a8d480a3c4dc6a975309d",
"sslEnabled": "on",
"sslCipher": "ECDHE-RSA-AES256-GCM-SHA384",
"sslProtocol": "TLSv1.2",
"sslClientVerify": "NONE",
"sslClientCertificateFingerprint": "",
"sslClientCertificateIssuerName": "",
"serverRouted": "52.239.221.65:443",
"serverStatus": "200",
"serverResponseLatency": "0.028",
"upstreamSourcePort": "21564",
"originalHost": "20.110.30.194",
"host": "20.110.30.194",
"error_info":"ERRORINFO_NO_ERROR",
"contentType":"application/json"
}
}
Catatan
Akses log dengan nilai clientIP 127.0.0.1 berasal dari proses keamanan internal yang berjalan pada instans gateway aplikasi. Anda dapat mengabaikan entri log ini dengan aman.
Untuk Application Gateway Standar dan WAF SKU (v1)
| Nilai | Deskripsi |
|---|---|
| instansId | Instans Application Gateway yang melayani permintaan. |
| clientIP | IP asal permintaan. |
| clientPort | Porta asal permintaan. |
| httpMethod | Metode HTTP yang digunakan oleh permintaan. |
| requestUri | URI permintaan yang diterima. |
| RequestQuery | Server-Routed: Instans kumpulan backend yang dikirimi permintaan. X-AzureApplicationGateway-LOG-ID: ID korelasi yang digunakan untuk permintaan tersebut. Ini dapat digunakan untuk memecahkan masalah lalu lintas di server backend. SERVER-STATUS: Kode respons HTTP yang diterima Application Gateway dari ujung-belakang. |
| UserAgent | Agen pengguna dari header permintaan HTTP. |
| httpStatus | Kode status HTTP yang dikembalikan ke klien dari Application Gateway. |
| httpVersion | Versi HTTP permintaan. |
| receivedBytes | Ukuran paket yang diterima, dalam byte. |
| sentBytes | Ukuran paket yang dikirim, dalam byte. |
| timeTaken | Lamanya waktu (dalam milidetik) yang diperlukan untuk permintaan diproses dan responsnya dikirim. Dihitung sebagai interval dari waktu ketika Application Gateway menerima byte pertama permintaan HTTP sampai waktu ketika operasi pengiriman respons selesai. Penting untuk diperhatikan bahwa bidang Time-Taken biasanya mencakup waktu paket permintaan dan respons melintasi jaringan. |
| sslEnabled | Apakah komunikasi ke kumpulan backend menggunakan TLS/SSL. Nilai yang valid yaitu aktif dan nonaktif. |
| tuan rumah | Nama host yang permintaannya telah dikirim ke server backend. Jika nama host backend sedang ditimpa, nama ini mencerminkan bahwa. |
| originalHost | Nama host tempat permintaan diterima oleh Application Gateway dari klien. |
{
"resourceId": "/SUBSCRIPTIONS/{subscriptionId}/RESOURCEGROUPS/PEERINGTEST/PROVIDERS/MICROSOFT.NETWORK/APPLICATIONGATEWAYS/{applicationGatewayName}",
"operationName": "ApplicationGatewayAccess",
"time": "2017-04-26T19:27:38Z",
"category": "ApplicationGatewayAccessLog",
"properties": {
"instanceId": "ApplicationGatewayRole_IN_0",
"clientIP": "191.96.249.97",
"clientPort": 46886,
"httpMethod": "GET",
"requestUri": "/phpmyadmin/scripts/setup.php",
"requestQuery": "X-AzureApplicationGateway-CACHE-HIT=0&SERVER-ROUTED=10.4.0.4&X-AzureApplicationGateway-LOG-ID=874f1f0f-6807-41c9-b7bc-f3cfa74aa0b1&SERVER-STATUS=404",
"userAgent": "-",
"httpStatus": 404,
"httpVersion": "HTTP/1.0",
"receivedBytes": 65,
"sentBytes": 553,
"timeTaken": 205,
"sslEnabled": "off",
"host": "www.contoso.com",
"originalHost": "www.contoso.com"
}
}
Informasi kode kesalahan
Jika gateway aplikasi tidak dapat menyelesaikan permintaan, gateway aplikasi menyimpan salah satu kode alasan berikut di bidang error_info log akses.
| Kesalahan 4XX | (Kode kesalahan 4xx menunjukkan bahwa ada masalah dengan permintaan klien, dan Application Gateway tidak dapat memenuhinya.) |
|---|---|
| ERRORINFO_INVALID_METHOD | Klien telah mengirim permintaan yang tidak mematuhi RFC. Kemungkinan alasan: klien yang menggunakan metode HTTP tidak didukung oleh server, metode yang salah eja, versi protokol HTTP yang tidak kompatibel, dll. |
| ERRORINFO_INVALID_REQUEST | Server tidak dapat memenuhi permintaan karena sintaksis yang salah. |
| ERRORINFO_INVALID_VERSION | Gateway aplikasi menerima permintaan dengan versi HTTP yang tidak valid atau tidak didukung. |
| ERRORINFO_INVALID_09_METHOD | Klien mengirim permintaan dengan Protokol HTTP versi 0.9. |
| ERRORINFO_INVALID_HOST | Nilai yang disediakan di header "Host" hilang, diformat dengan tidak benar, atau tidak cocok dengan nilai host yang diharapkan. Misalnya, ketika tidak ada pendengar Dasar, dan tidak ada nama host pendengar Multisitus yang cocok dengan host. |
| ERRORINFO_INVALID_CONTENT_LENGTH | Panjang konten yang ditentukan oleh klien di header Content-Length tidak cocok dengan panjang konten aktual dalam permintaan. |
| ERRORINFO_INVALID_METHOD_TRACE | Klien mengirim metode HTTP TRACE, yang tidak didukung oleh gateway aplikasi. |
| ERRORINFO_CLIENT_CLOSED_REQUEST | Klien menutup koneksi dengan gateway aplikasi sebelum periode batas waktu diam berlalu. Periksa apakah periode batas waktu klien lebih besar dari periode batas waktu diam untuk gateway aplikasi. |
| ERRORINFO_REQUEST_URI_INVALID | Menunjukkan masalah dengan Pengidentifikasi Sumber Daya Seragam (URI) yang disediakan dalam permintaan klien. |
| ERRORINFO_HTTP_NO_HOST_HEADER | Klien mengirim permintaan tanpa header Host. |
| ERRORINFO_HTTP_TO_HTTPS_PORT | Klien mengirim permintaan HTTP biasa ke port HTTPS. |
| ERRORINFO_HTTPS_NO_CERT | Menunjukkan klien tidak mengirim sertifikat TLS yang valid dan dikonfigurasi dengan benar selama autentikasi TLS Bersama. |
| Kesalahan 5XX | Deskripsi |
|---|---|
| ERRORINFO_UPSTREAM_NO_LIVE | Gateway aplikasi tidak dapat menemukan server backend yang aktif atau dapat dijangkau untuk menangani permintaan masuk |
| ERRORINFO_UPSTREAM_CLOSED_CONNECTION | Server backend menutup koneksi secara tak terduga atau sebelum permintaan diproses sepenuhnya. Ini bisa terjadi karena server backend mencapai batasnya, crash dll. |
| ERRORINFO_UPSTREAM_TIMED_OUT | Koneksi TCP yang dibuat dengan server ditutup karena koneksi membutuhkan waktu lebih lama dari nilai batas waktu yang dikonfigurasi. |
Log performa
Log performa dibuat hanya jika Anda telah mengaktifkannya pada setiap instans Application Gateway, sebagaimana terperinci dalam langkah sebelumnya. Data disimpan di akun penyimpanan yang Anda tentukan saat Anda mengaktifkan pengelogan. Data log performa dihasilkan dalam interval 1 menit. Ini hanya tersedia untuk SKU v1. Untuk SKU v2, gunakan Metrik untuk data performa. Data berikut dicatat:
| Nilai | Deskripsi |
|---|---|
| instansId | Instans Application Gateway tempat data performa dihasilkan. Untuk gateway aplikasi beberapa instans, ada satu baris per instans. |
| healthyHostCount | Jumlah host sehat di kumpulan backend. |
| unHealthyHostCount | Jumlah host yang tidak sehat di kumpulan backend. |
| requestCount | Jumlah permintaan yang dilayani. |
| latency | Rata-rata latensi (dalam milidetik) permintaan dari instans ke ujung belakang yang melayani permintaan. |
| failedRequestCount | Jumlah permintaan yang gagal. |
| throughput | Rata-rata throughput sejak log terakhir, dihitung dalam byte per detik. |
{
"resourceId": "/SUBSCRIPTIONS/{subscriptionId}/RESOURCEGROUPS/{resourceGroupName}/PROVIDERS/MICROSOFT.NETWORK/APPLICATIONGATEWAYS/{applicationGatewayName}",
"operationName": "ApplicationGatewayPerformance",
"time": "2016-04-09T00:00:00Z",
"category": "ApplicationGatewayPerformanceLog",
"properties":
{
"instanceId":"ApplicationGatewayRole_IN_1",
"healthyHostCount":"4",
"unHealthyHostCount":"0",
"requestCount":"185",
"latency":"0",
"failedRequestCount":"0",
"throughput":"119427"
}
}
Catatan
Latensi dihitung dari waktu ketika byte pertama permintaan HTTP diterima hingga saat byte terakhir respons HTTP dikirim. Ini adalah jumlah waktu pemrosesan Application Gateway ditambah biaya jaringan ke ujung belakang, ditambah waktu yang diperlukan ujung belakang untuk memproses permintaan.
Log firewall
Log firewall dibuat hanya jika Anda telah mengaktifkannya pada setiap instans Application Gateway, sebagaimana terperinci dalam langkah sebelumnya. Log ini juga mengharuskan firewall aplikasi web dikonfigurasi di gateway aplikasi. Data disimpan di akun penyimpanan yang Anda tentukan saat Anda mengaktifkan pengelogan. Data berikut dicatat:
| Nilai | Deskripsi |
|---|---|
| instansId | Instans Application Gateway tempat data firewall dihasilkan. Untuk gateway aplikasi beberapa instans, ada satu baris per instans. |
| clientIp | IP asal permintaan. |
| clientPort | Porta asal permintaan. |
| requestUri | URI permintaan yang diterima. |
| ruleSetType | Jenis seperangkat aturan. Nilai yang tersedia adalah OWASP. |
| ruleSetVersion | Versi seperangkat aturan yang digunakan. Nilai yang tersedia adalah 2.2.9 dan 3.0. |
| ruleId | ID aturan dari kejadian pemicu. |
| pesan | Pesan ramah-pengguna untuk kejadian pemicu. Detail lebih lanjut disediakan di bagian detail. |
| tindakan | Tindakan yang diambil atas permintaan. Nilai yang tersedia Diblokir dan Diizinkan (untuk aturan kustom), Cocok (jika aturan cocok dengan bagian permintaan), dan Terdeteksi dan Diblokir (keduanya untuk aturan wajib, tergantung pada apakah WAF berada dalam mode deteksi atau pencegahan). |
| site | Situs tempat log dihasilkan. Saat ini, hanya Global yang terdaftar karena aturan bersifat global. |
| detail | Detail kejadian pemicu. |
| details.message | Deskripsi aturan. |
| details.data | Data tertentu yang ditemukan dalam permintaan yang cocok dengan aturan. |
| details.file | File konfigurasi yang memuat aturan. |
| details.line | Nomor baris dalam file konfigurasi yang memicu peristiwa. |
| hostname | Nama host atau alamat IP Application Gateway. |
| transactionId | ID khusus untuk transaksi tertentu yang membantu mengelompokkan beberapa pelanggaran aturan yang terjadi dalam permintaan yang sama. |
{
"timeStamp": "2021-10-14T22:17:11+00:00",
"resourceId": "/SUBSCRIPTIONS/{subscriptionId}/RESOURCEGROUPS/{resourceGroupName}/PROVIDERS/MICROSOFT.NETWORK/APPLICATIONGATEWAYS/{applicationGatewayName}",
"operationName": "ApplicationGatewayFirewall",
"category": "ApplicationGatewayFirewallLog",
"properties": {
"instanceId": "appgw_2",
"clientIp": "185.42.129.24",
"clientPort": "",
"requestUri": "\/",
"ruleSetType": "OWASP_CRS",
"ruleSetVersion": "3.0.0",
"ruleId": "920350",
"message": "Host header is a numeric IP address",
"action": "Matched",
"site": "Global",
"details": {
"message": "Warning. Pattern match \\\"^[\\\\d.:]+$\\\" at REQUEST_HEADERS:Host .... ",
"data": "20.110.30.194:80",
"file": "rules\/REQUEST-920-PROTOCOL-ENFORCEMENT.conf",
"line": "791"
},
"hostname": "20.110.30.194:80",
"transactionId": "592d1649f75a8d480a3c4dc6a975309d",
"policyId": "default",
"policyScope": "Global",
"policyScopeName": "Global"
}
}
Melihat dan menganalisis log aktivitas
Anda dapat melihat dan menganalisis data log aktivitas dengan menggunakan salah satu metode berikut:
- Alat Azure: Mengambil informasi dari log aktivitas melalui Azure PowerShell, Azure CLI, REST API Azure, atau portal Microsoft Azure. Petunjuk langkah demi langkah untuk setiap metode dijelaskan dalam artikel Operasi aktivitas dengan Resource Manager.
- Power BI: Jika Anda belum memiliki akun Power BI, Anda dapat mencobanya secara gratis. Dengan menggunakan aplikasi templat Power BI, Anda dapat menganalisis data.
Melihat dan menganalisis log akses, performa, dan firewall
Log Azure Monitor dapat mengumpulkan penghitung dan file log peristiwa dari akun Blob storage Anda. Ini termasuk visualisasi dan kemampuan pencarian yang canggih untuk menganalisis log Anda.
Anda juga dapat terhubung ke akun penyimpanan dan mengambil entri log JSON untuk log akses dan performa. Setelah mengunduh file JSON, Anda dapat mengonversinya ke CSV dan menampilkannya di Excel, Power BI, atau alat visualisasi data lainnya.
Tip
Jika Anda terbiasa dengan Visual Studio dan konsep dasar pengubahan nilai untuk konstanta dan variabel di C#, Anda dapat menggunakan alat pengonversi log yang tersedia dari GitHub.
Menganalisis log Access melalui GoAccess
Kami telah menerbitkan templat Resource Manager yang menginstal dan menjalankan penganalisis log populer GoAccess untuk Log Akses Application Gateway. GoAccess menyediakan statistik lalu lintas HTTP penting seperti Pengunjung Unik, File yang Diminta, Host, Sistem Operasi, Browser, kode Status HTTP, dan banyak lagi. Untuk detail lebih lanjut, lihat file Readme di folder templat Resource Manager di GitHub.
Langkah berikutnya
- Visualisasikan penghitung dan log peristiwa dengan menggunakan log Azure Monitor.
- Visualisasikan log aktivitas Azure Anda dengan posting blog Power BI.
- Lihat dan analisis log aktivitas Azure di Power BI dan posting blog lainnya.