Memantau Azure Front Door
Azure Monitor mengumpulkan dan menggabungkan metrik dan log dari sistem Anda untuk memantau ketersediaan, performa, dan ketahanan, dan memberi tahu Anda tentang masalah yang memengaruhi sistem Anda. Anda dapat menggunakan pustaka portal Azure, PowerShell, Azure CLI, REST API, atau klien untuk menyiapkan dan melihat data pemantauan.
Metrik dan log yang berbeda tersedia untuk berbagai jenis sumber daya. Artikel ini menjelaskan jenis data pemantauan yang dapat Anda kumpulkan untuk layanan ini dan cara menganalisis data tersebut.
Laporan memberikan wawasan tentang bagaimana lalu lintas Anda mengalir melalui Azure Front Door, firewall aplikasi web (WAF), dan ke aplikasi Anda.
Penting
Azure Front Door (klasik) akan dihentikan pada 31 Maret 2027. Untuk menghindari gangguan layanan apa pun, penting untuk memigrasikan profil Azure Front Door (klasik) Anda ke Azure Front Door Standard atau tingkat Premium paling lambat Maret 2027. Untuk informasi selengkapnya, lihat Penghentian Azure Front Door (klasik).
Mengumpulkan data dengan Azure Monitor
Tabel ini menjelaskan bagaimana Anda dapat mengumpulkan data untuk memantau layanan Anda, dan apa yang dapat Anda lakukan dengan data setelah dikumpulkan:
| Data untuk dikumpulkan | Deskripsi | Cara mengumpulkan dan merutekan data | Tempat menampilkan data | Data yang didukung |
|---|---|---|---|---|
| Data metrik | Metrik adalah nilai numerik yang menjelaskan aspek sistem pada titik waktu tertentu. Metrik dapat diagregasi menggunakan algoritma, dibandingkan dengan metrik lain, dan dianalisis untuk tren dari waktu ke waktu. | - Dikumpulkan secara otomatis secara berkala. - Anda dapat merutekan beberapa metrik platform ke ruang kerja Analitik Log untuk dikueri dengan data lain. Periksa pengaturan ekspor DS untuk setiap metrik untuk melihat apakah Anda dapat menggunakan pengaturan diagnostik untuk merutekan data metrik. |
Penjelajah metrik | Metrik Azure Front Door yang didukung oleh Azure Monitor |
| Data log sumber daya | Log adalah peristiwa sistem yang direkam dengan tanda waktu. Log dapat berisi berbagai jenis data, dan teks terstruktur atau bentuk bebas. Anda dapat merutekan data log sumber daya ke ruang kerja Analitik Log untuk kueri dan analisis. | Buat pengaturan diagnostik untuk mengumpulkan dan merutekan data log sumber daya. | Analitik Log | Data log sumber daya Azure Front Door yang didukung oleh Azure Monitor |
| Data log aktivitas | Log aktivitas Azure Monitor memberikan wawasan tentang peristiwa tingkat langganan. Log aktivitas mencakup informasi seperti saat sumber daya dimodifikasi atau mesin virtual dimulai. | - Dikumpulkan secara otomatis. - Buat pengaturan diagnostik ke ruang kerja Analitik Log tanpa biaya. |
Log aktivitas |
Untuk daftar semua data yang didukung oleh Azure Monitor, lihat:
Pemantauan bawaan untuk Azure Front Door
Log melacak semua permintaan yang melewati Azure Front Door. Dibutuhkan beberapa menit agar log diproses dan disimpan.
Ada beberapa log Front Door, yang dapat Anda gunakan untuk tujuan yang berbeda:
- Log akses dapat digunakan untuk mengidentifikasi permintaan lambat, menentukan tingkat kesalahan, dan memahami cara kerja perilaku penembolokan Front Door untuk solusi Anda.
- Log firewall aplikasi web (WAF) dapat digunakan untuk mendeteksi potensi serangan, dan deteksi positif palsu yang mungkin menunjukkan permintaan sah yang diblokir WAF. Untuk informasi selengkapnya tentang log WAF, lihat Pemantauan dan pengelogan Azure Web Application Firewall.
- Log pemeriksaan kesehatan dapat digunakan untuk mengidentifikasi asal-usul yang tidak sehat atau yang tidak menanggapi permintaan dari beberapa POP front Door yang didistribusikan secara geografis.
- Log aktivitas memberikan visibilitas ke dalam operasi yang dilakukan pada sumber daya Azure Anda, seperti perubahan konfigurasi pada profil Azure Front Door Anda.
Log akses dan log WAF mencakup referensi pelacakan, yang juga disebarluaskan dalam permintaan ke asal dan ke respons klien dengan menggunakan X-Azure-Ref header. Anda dapat menggunakan referensi pelacakan untuk mendapatkan tampilan end-to-end dari pemrosesan permintaan aplikasi Anda.
Log akses, log pemeriksaan kesehatan, dan log WAF tidak diaktifkan secara default. Untuk mengaktifkan dan menyimpan log diagnostik Anda, lihat Mengonfigurasi log Azure Front Door. Entri log aktivitas dikumpulkan secara default, dan Anda dapat melihatnya di portal Microsoft Azure.
Log akses
Informasi tentang setiap permintaan dicatat ke log akses. Setiap entri log akses berisi informasi yang tercantum dalam tabel berikut.
| Properti | Deskripsi |
|---|---|
| TrackingReference | String referensi unik yang mengidentifikasi permintaan yang dilayani oleh Azure Front Door. Referensi pelacakan dikirim ke klien dan ke asal dengan menggunakan X-Azure-Ref header. Gunakan referensi pelacakan saat mencari permintaan tertentu dalam akses atau log WAF. |
| Waktu | Tanggal dan waktu ketika tepi Azure Front Door mengirimkan konten yang diminta ke klien (dalam UTC). Untuk koneksi WebSocket, waktu mewakili kapan koneksi ditutup. |
| HttpMethod | Metode HTTP yang digunakan oleh permintaan: DELETE, GET, HEAD, OPTIONS, PATCH, POST, atau PUT. |
| HttpVersion | Versi HTTP yang ditentukan klien dalam permintaan. |
| RequestUri | URI permintaan yang diterima. Bidang ini berisi skema lengkap, port, domain, jalur, dan string kueri. |
| HostName | Nama host dalam permintaan dari klien. Jika Anda mengaktifkan domain kustom dan memiliki domain wildcard (*.contoso.com), nilai bidang log HostName adalah subdomain-from-client-request.contoso.com. Jika Anda menggunakan domain Azure Front Door (contoso-123.z01.azurefd.net), nilai bidang log HostName adalah contoso-123.z01.azurefd.net. |
| RequestBytes | Ukuran pesan permintaan HTTP dalam byte, termasuk header permintaan dan isi permintaan. Untuk koneksi WebSocket, nilai ini adalah jumlah total byte yang dikirim dari klien ke server melalui koneksi. |
| Pusat Respons | Ukuran pesan respons HTTP dalam byte. Untuk koneksi WebSocket, nilai ini adalah jumlah total byte yang dikirim dari server ke klien melalui koneksi. |
| UserAgent | Agen pengguna yang digunakan klien. Biasanya, agen pengguna mengidentifikasi jenis browser. |
| ClientIp | Alamat IP klien yang membuat permintaan. Jika ada X-Forwarded-For header dalam permintaan, maka alamat IP klien diambil dari header. |
| SocketIp | Alamat IP koneksi langsung ke tepi Azure Front Door. Jika klien menggunakan proksi HTTP atau penyeimbang muatan untuk mengirim permintaan, nilai SocketIp-nya adalah alamat IP proksi atau penyeimbang beban. |
| TimeTaken | Durasi dari ketika tepi Azure Front Door menerima permintaan klien ke ketika byte terakhir respons dikirim ke klien, diukur dalam hitungan detik. Metrik ini mengecualikan latensi jaringan dan buffering TCP. Untuk koneksi WebSocket, ini mewakili durasi koneksi dari pendirian hingga penutupan. |
| RequestProtocol | Protokol yang ditentukan oleh klien dalam permintaan. Nilai yang mungkin termasuk: HTTP, HTTPS. Untuk WebSocket, protokolnya adalah WS, WSS. Hanya permintaan yang berhasil meningkatkan ke WebSocket yang memiliki WS/WSS. |
| SecurityProtocol | Versi protokol TLS/SSL yang digunakan oleh permintaan, atau null jika permintaan tidak menggunakan enkripsi. Nilai yang mungkin termasuk: SSLv3, TLSv1, TLSv1.1, TLSv1.2. |
| SecurityCipher | Ketika nilai untuk protokol permintaan adalah HTTPS, bidang ini menunjukkan cipher TLS/SSL yang dinegosiasikan oleh klien dan Azure Front Door. |
| Titik akhir | Nama domain titik akhir Azure Front Door, seperti contoso-123.z01.azurefd.net. |
| HttpStatusCode | Kode status HTTP dikembalikan dari Azure Front Door. Jika permintaan ke asal kehabisan waktu, nilai untuk bidang HttpStatusCode adalah 0. Jika klien menutup koneksi, nilai untuk bidang HttpStatusCode adalah 499. |
| Pop | Titik kehadiran tepi Azure Front Door (PoP) yang merespons permintaan pengguna. |
| Status Tembolok | Bagaimana cache Azure Front Door menangani permintaan. Nilai yang mungkin adalah:
|
| MatchedRulesSetName | Nama aturan Mesin Aturan yang diproses. |
| RouteName | Nama aturan perutean yang cocok dengan permintaan. |
| ClientPort | Alamat IP klien yang membuat permintaan. |
| Perujuk | URL situs yang berasal dari permintaan. |
| TimetoFirstByte | Lamanya waktu, dalam detik, dari ketika tepi Azure Front Door menerima permintaan hingga waktu byte pertama dikirim ke klien, seperti yang diukur oleh Azure Front Door. Properti ini tidak mengukur data klien. |
| ErrorInfo | Jika terjadi kesalahan selama pemrosesan permintaan, bidang ini memberikan informasi terperinci tentang kesalahan tersebut. Nilai yang mungkin adalah:
|
| OriginURL | URL lengkap asal tempat permintaan dikirim. URL terdiri dari skema, header host, port, jalur, dan string kueri. Penulisan ulang URL: Jika Mesin Aturan menulis ulang URL permintaan, jalur mengacu pada jalur yang ditulis ulang. Cache di PoP tepi: Jika permintaan dilayani dari cache Azure Front Door, asalnya adalah N/A. Permintaan besar: Jika konten yang diminta besar dan ada beberapa permintaan yang dipotong kembali ke asal, bidang ini sesuai dengan permintaan pertama ke asal. Untuk informasi selengkapnya, lihat Penggugusan Objek. |
| OriginIP | Alamat IP asal yang melayani permintaan. Cache di PoP tepi: Jika permintaan dilayani dari cache Azure Front Door, asalnya adalah N/A. Permintaan besar: Jika konten yang diminta besar dan ada beberapa permintaan yang dipotong kembali ke asal, bidang ini sesuai dengan permintaan pertama ke asal. Untuk informasi selengkapnya, lihat Penggugusan Objek. |
| OriginName | Nama host lengkap (nama DNS) asal. Cache di PoP tepi: Jika permintaan dilayani dari cache Azure Front Door, asalnya adalah N/A. Permintaan besar: Jika konten yang diminta besar dan ada beberapa permintaan yang dipotong kembali ke asal, bidang ini sesuai dengan permintaan pertama ke asal. Untuk informasi selengkapnya, lihat Penggugusan Objek. |
| Hasil |
SSLMismatchedSNI adalah kode status yang menandakan permintaan yang berhasil dengan peringatan yang tidak cocok antara SNI dan header host. Kode status ini menyiratkan fronting domain, teknik yang melanggar ketentuan layanan Azure Front Door. Permintaan dengan SSLMismatchedSNI akan ditolak setelah 22 Januari 2024. |
| Sni | Bidang ini menentukan Indikasi Nama Server (SNI) yang dikirim selama jabat tangan TLS/SSL. Ini dapat digunakan untuk mengidentifikasi nilai SNI yang tepat jika ada SSLMismatchedSNI kode status. Selain itu, dapat dibandingkan dengan nilai host di requestUri bidang untuk mendeteksi dan mengatasi masalah ketidakcocokan. |
Log pemeriksaan kesehatan
Azure Front Door mencatat setiap permintaan pemeriksaan kesehatan yang gagal. Log ini dapat membantu Anda mendiagnosis masalah dengan asal. Log memberi Anda informasi yang dapat Anda gunakan untuk menyelidiki alasan kegagalan dan kemudian membawa asal kembali ke status sehat.
Beberapa skenario yang bisa berguna bagi log ini adalah:
- Anda melihat lalu lintas Azure Front Door dikirim ke subset asal. Misalnya, Anda mungkin melihat bahwa hanya tiga dari empat asal yang menerima lalu lintas. Anda ingin tahu apakah asal-usul menerima dan menanggapi pemeriksaan kesehatan sehingga Anda tahu apakah asal-usulnya sehat.
- Anda melihat metrik persentase kesehatan asal lebih rendah dari yang Anda harapkan. Anda ingin tahu asal-usul mana yang dicatat sebagai tidak sehat dan alasan kegagalan pemeriksaan kesehatan.
Setiap entri log pemeriksaan kesehatan memiliki skema berikut:
| Properti | Deskripsi |
|---|---|
| HealthProbeId | ID unik untuk mengidentifikasi permintaan pemeriksaan kesehatan. |
| Waktu | Tanggal dan waktu ketika pemeriksaan kesehatan dikirim (dalam UTC). |
| HttpMethod | Metode HTTP yang digunakan oleh permintaan pemeriksaan kesehatan. Nilai termasuk GET dan HEAD, berdasarkan konfigurasi pemeriksaan kesehatan. |
| Hasil | Status pemeriksaan kesehatan. Nilainya adalah keberhasilan atau deskripsi kesalahan yang diterima pemeriksaan. |
| HttpStatusCode | Kode status HTTP yang dikembalikan oleh asal. |
| ProbeURL | URL target lengkap ke tempat permintaan pemeriksaan dikirim. URL terdiri dari skema, header host, jalur, dan string kueri. |
| OriginName | Nama asal tempat pemeriksaan kesehatan dikirim. Bidang ini membantu Anda menemukan asal yang menarik jika asal dikonfigurasi untuk menggunakan FQDN. |
| POP | PoP tepi yang mengirim permintaan pemeriksaan. |
| IP Asal | Alamat IP asal tempat pemeriksaan kesehatan dikirim. |
| TotalLatency | Waktu sejak tepi Azure Front Door mengirim permintaan pemeriksaan kesehatan ke asal ketika asal mengirim respons terakhir ke Azure Front Door. |
| ConnectionLatency | Waktu yang dihabiskan untuk menyiapkan koneksi TCP untuk mengirim permintaan pemeriksaan HTTP ke asal. |
| Latensi DNSResolution | Waktu yang dihabiskan untuk resolusi DNS. Bidang ini hanya memiliki nilai jika asal dikonfigurasi menjadi FQDN alih-alih alamat IP. Jika asal dikonfigurasi untuk menggunakan alamat IP, nilainya adalah N/A. |
Contoh cuplikan JSON berikut menunjukkan entri log pemeriksaan kesehatan untuk permintaan pemeriksaan kesehatan yang gagal.
{
"records": [
{
"time": "2021-02-02T07:15:37.3640748Z",
"resourceId": "/SUBSCRIPTIONS/mySubscriptionID/RESOURCEGROUPS/myResourceGroup/PROVIDERS/MICROSOFT.CDN/PROFILES/MyProfile",
"category": "FrontDoorHealthProbeLog",
"operationName": "Microsoft.Cdn/Profiles/FrontDoorHealthProbeLog/Write",
"properties": {
"healthProbeId": "9642AEA07BA64675A0A7AD214ACF746E",
"POP": "MAA",
"httpVerb": "HEAD",
"result": "OriginError",
"httpStatusCode": "400",
"probeURL": "http://www.example.com:80/",
"originName": "www.example.com",
"originIP": "PublicI:Port",
"totalLatencyMilliseconds": "141",
"connectionLatencyMilliseconds": "68",
"DNSLatencyMicroseconds": "1814"
}
}
]
}
Log firewall aplikasi web
Untuk informasi selengkapnya tentang log firewall aplikasi web (WAF) Front Door, lihat Pemantauan dan pengelogan Azure Web Application Firewall.
Untuk Azure Front Door klasik, pemantauan bawaan menyertakan log diagnostik.
Log Diagnostik
Log diagnostik menyediakan informasi yang kaya tentang operasi dan kesalahan yang penting untuk audit dan pemecahan masalah. Log diagnostik berbeda dari log aktivitas.
Log aktivitas memberikan wawasan tentang operasi yang dilakukan pada sumber daya Azure. Log diagnostik memberikan wawasan tentang operasi yang dilakukan sumber daya Anda. Untuk informasi lebih lengkap, lihat log diagnostik Azure Monitor.
Untuk mengonfigurasi log diagnostik untuk Azure Front Door Anda (klasik):
Pilih profil Azure Front Door (klasik).
Pilih setelan Diagnostik.
Pilih Aktifkan diagnostik. Arsipkan log diagnostik bersama dengan metrik ke akun penyimpanan, streaming ke hub kejadian, atau kirim ke log Azure Monitor.
Front Door saat ini menyediakan log diagnostik. Log diagnostik menyediakan permintaan API individual dengan setiap entri memiliki skema berikut:
| Properti | Deskripsi |
|---|---|
| BackendHostname | Jika permintaan diteruskan ke backend, bidang ini mewakili nama host backend. Bidang ini kosong jika permintaan dialihkan atau diteruskan ke cache regional (saat penembolokan diaktifkan untuk aturan perutean). |
| CacheStatus | Untuk skenario penembolokan, bidang ini menentukan miss/hit singgahan di POP |
| ClientIp | Alamat IP klien yang membuat permintaan. Jika ada header X-Forwarded-For dalam permintaan, maka IP Klien dipilih dari yang sama. |
| ClientPort | Alamat IP klien yang membuat permintaan. |
| HttpMethod | Metode HTTP yang digunakan oleh permintaan. |
| HttpStatusCode | Kode status HTTP yang dikembalikan dari proxy. Jika permintaan ke waktu asal habis, nilai untuk HttpStatusCode diatur ke 0. |
| HttpStatusDetails | Status yang dihasilkan atas permintaan. Arti dari nilai string ini dapat ditemukan di tabel referensi Status. |
| HttpVersion | Jenis permintaan atau koneksi. |
| POP | Nama pendek tepi tempat permintaan mendarat. |
| RequestBytes | Ukuran pesan permintaan HTTP dalam byte, termasuk header permintaan dan isi permintaan. |
| RequestUri | URI permintaan yang diterima. |
| Pusat Respons | Byte dikirim oleh server backend sebagai respons. |
| RoutingRuleName | Nama aturan perutean yang cocok dengan permintaan. |
| RulesEngineMatchNames | Nama aturan yang cocok dengan permintaan. |
| SecurityProtocol | Versi protokol TLS/SSL yang digunakan oleh permintaan atau null jika tidak ada enkripsi. |
| SentToOriginShield (tidak digunakan lagi) * Lihat catatan tentang penghentian di bagian berikut. |
Jika true, artinya permintaan itu dijawab dari cache perisai asal, bukan pop tepi. Perisai asal adalah cache induk yang digunakan untuk meningkatkan rasio hit cache. |
| isReceivedFromClient | Jika True, itu artinya permintaan berasal dari klien. Jika False, permintaan adalah ketinggalan di tepi (POP anak) dan ditanggapi dari perisai asal (POP induk). |
| TimeTaken | Lamanya waktu dari byte pertama permintaan ke Front Door untuk byte terakhir respons keluar, dalam hitungan detik. |
| TrackingReference | String referensi unik yang mengidentifikasi permintaan yang dilayani oleh Front Door, juga dikirim sebagai header X-Azure-Ref ke klien. Diperlukan untuk mencari detail dalam log akses untuk permintaan tertentu. |
| UserAgent | Jenis browser yang digunakan klien. |
| ErrorInfo | Bidang ini berisi jenis kesalahan tertentu untuk pemecahan masalah lebih lanjut.
Nilai yang mungkin termasuk: NoError: Menunjukkan tidak ada kesalahan yang ditemukan. CertificateError: Kesalahan sertifikat SSL generik. CertificateNameCheckFailed: Nama host dalam sertifikat SSL tidak valid atau tidak cocok. ClientDisconnected: Permintaan gagal karena koneksi jaringan klien. UnspecifiedClientError: Galat klien umum. InvalidRequest: Permintaan tidak valid. Ini mungkin terjadi karena header, isi, dan URL yang salah bentuk. DNSFailure: Kegagalan DNS. DNSNameNotResolved: Nama atau alamat server tidak dapat diselesaikan. OriginConnectionAborted: Sambungan dengan asal dihentikan secara tiba-tiba. OriginConnectionError: Kesalahan koneksi asal generik. OriginConnectionRefused: Sambungan dengan asal tidak dapat dibuat. OriginError: Kesalahan asal umum. OriginInvalidResponse: Asal menampilkan respons yang tidak valid atau tidak dikenali. OriginTimeout: Periode waktu habis untuk permintaan asal kedaluwarsa. ResponseHeaderTooBig: Asal menampilkan header respons yang terlalu besar. RestrictedIP: Permintaan diblokir karena IP terbatas. SSLHandshakeError: Tidak dapat membuat sambungan dengan asal karena kegagalan jabat tangan SSL. UnspecifiedError: Terjadi kesalahan yang tidak sesuai dengan kesalahan dalam tabel. SSLMismatchedSNI: Permintaan tidak valid karena header pesan HTTP tidak cocok dengan nilai yang disajikan dalam ekstensi SNI TLS selama penyiapan koneksi SSL/TLS. |
| Hasil |
SSLMismatchedSNI adalah kode status yang menandakan permintaan yang berhasil dengan peringatan yang tidak cocok antara SNI dan header host. Kode status ini menyiratkan fronting domain, teknik yang melanggar ketentuan layanan Azure Front Door. Permintaan dengan SSLMismatchedSNI akan ditolak setelah 22 Januari 2024. |
| Sni | Bidang ini menentukan Indikasi Nama Server (SNI) yang dikirim selama jabat tangan TLS/SSL. Ini dapat digunakan untuk mengidentifikasi nilai SNI yang tepat jika ada SSLMismatchedSNI kode status. Selain itu, dapat dibandingkan dengan nilai host di requestUri bidang untuk mendeteksi dan mengatasi masalah ketidakcocokan. |
Dikirim ke penghentian perisai asal
Properti log mentah isSentToOriginShield tidak digunakan lagi dan digantikan oleh bidang baru isReceivedFromClient. Gunakan bidang baru jika Anda sudah menggunakan bidang yang tidak digunakan lagi.
Log mentah termasuk log yang dihasilkan dari tepi CDN (POP anak) dan perisai asal. Perisai asal mengacu pada node induk yang berlokasi strategis di seluruh dunia. Node ini berkomunikasi dengan server asal dan mengurangi beban lalu lintas pada asal.
Untuk setiap permintaan yang masuk ke perisai asal, ada dua entri log:
- Satu untuk node tepi
- Satu untuk perisai asal
Untuk membedakan egress atau respons dari node tepi vs perisai asal, Anda dapat menggunakan bidang isReceivedFromClient untuk mendapatkan data yang benar.
Jika nilainya false, maka itu berarti permintaan direspons dari perisai asal ke node tepi. Pendekatan ini efektif untuk membandingkan log mentah dengan data penagihan. Biaya tidak dikenakan untuk egress dari perisai asal ke node tepi. Biaya dikeluarkan untuk egress dari node tepi ke klien.
Sampel kueri Kusto untuk mengecualikan log yang dihasilkan pada perisai asal di Analitik Log.
AzureDiagnostics | where Category == "FrontdoorAccessLog" and isReceivedFromClient_b == true
Catatan
Untuk berbagai konfigurasi perutean dan perilaku lalu lintas, beberapa bidang seperti backendHostname, cacheStatus, isReceivedFromClient, dan bidang POP mungkin merespons dengan nilai yang berbeda. Tabel berikut menjelaskan nilai berbeda yang dimiliki bidang-bidang ini untuk berbagai skenario:
| Skenario | Jumlah entri log | POP | BackendHostname | isReceivedFromClient | CacheStatus |
|---|---|---|---|---|---|
| Aturan peruteantanpa penembolokan diaktifkan | 1 | Kode POP Azure Stack Edge | Backend di mana permintaan diteruskan | Benar | CONFIG_NOCACHE |
| Aturan perutean tanpa penembolokan diaktifkan. Tembolok hit di tepi POP | 1 | Kode POP Azure Stack Edge | Kosong | Benar | Memukul |
| Aturan perutean tanpa penembolokan diaktifkan. Tembolok meleset di EDGE POP tetapi tembolok hit di tembolok pop induk | 2 | 1. Kode POP tepi 2. Kode POP cache induk |
1. Cache induk POP hostname 2. Kosong |
1. True 2. Salah |
1. MISS 2. Memukul |
| Aturan perutean tanpa penembolokan diaktifkan. Tembolok meleset di POP tepi tetapi tembolok PARSIAL terpukul di pop tembolok induk | 2 | 1. Kode POP tepi 2. Kode POP cache induk |
1. Cache induk POP hostname 2. Backend yang membantu mengisi cache |
1. True 2. Salah |
1. MISS 2. PARTIAL_HIT |
| Aturan perutean tanpa penembolokan diaktifkan. Tembolok meleset di EDGE POP tetapi tembolok hit di tembolok pop induk | 2 | 1. Kode POP tepi 2. Kode POP cache induk |
1. Kode POP tepi 2. Kode POP cache induk |
1. True 2. Salah |
1. PARTIAL_HIT 2. Memukul |
| Aturan perutean tanpa penembolokan diaktifkan. Cache meleset di kedua tepi dan cache induk POP | 2 | 1. Kode POP tepi 2. Kode POP cache induk |
1. Kode POP tepi 2. Kode POP cache induk |
1. True 2. Salah |
1. MISS 2. MISS |
| Kesalahan memproses permintaan | T/A |
Catatan
Untuk skenario penembolokan, nilai untuk Status Cache adalah PARTIAL_HIT ketika beberapa byte untuk permintaan dilayani dari tepi Azure Front Door atau cache perisai asal sementara beberapa byte dilayani dari asal untuk objek besar.
Azure Front Door menggunakan teknik yang disebut objek penggugusan. Saat file besar diminta, Azure Front Door mengambil potongan file yang lebih kecil dari asalnya. Setelah server POP Azure Front Door menerima rentang penuh atau byte dari file yang diminta, server tepi Azure Front Door meminta file dari asal dalam potongan 8 MB.
Setelah potongan tiba di tepi Azure Front Door, potongan tersebut di-cache dan segera disajikan kepada pengguna. Azure Front Door kemudian mengambil potongan berikutnya secara paralel. Prefetch ini memastikan konten tetap satu bagian bagi pengguna, yang mengurangi latensi. Proses ini berlanjut hingga seluruh file diunduh (jika diminta), semua rentang byte tersedia (jika diminta), atau klien menutup koneksi. Untuk informasi selengkapnya tentang permintaan rentang byte, lihat RFC 7233. Azure Front Door menyimpan semua potongan saat diterima. Seluruh file tidak perlu di-tembolok di tembolok Front Door. Permintaan berikutnya untuk rentang file atau byte disajikan dari cache Azure Front Door. Jika tidak semua potongan di-cache di Azure Front Door, prefetch digunakan untuk meminta potongan dari asal. Pengoptimalan ini bergantung pada kemampuan server asal untuk mendukung permintaan rentang byte. Jika server asal tidak mendukung permintaan rentang byte, pengoptimalan ini tidak efektif.
Menggunakan alat Azure Monitor untuk menganalisis data
Alat Azure Monitor ini tersedia di portal Azure untuk membantu Anda menganalisis data pemantauan:
Beberapa layanan Azure memiliki dasbor pemantauan bawaan di portal Azure. Dasbor ini disebut wawasan, dan Anda dapat menemukannya di bagian Wawasan Azure Monitor di portal Azure.
Penjelajah metrik memungkinkan Anda melihat dan menganalisis metrik untuk sumber daya Azure. Untuk informasi selengkapnya, lihat Menganalisis metrik dengan penjelajah metrik Azure Monitor.
Log Analytics memungkinkan Anda untuk mengkueri dan menganalisis data log menggunakan bahasa kueri Kusto (KQL). Untuk informasi selengkapnya, lihat Mulai menggunakan kueri Log di Azure Monitor.
portal Azure memiliki antarmuka pengguna untuk melihat dan pencarian dasar log aktivitas. Untuk melakukan analisis yang lebih mendalam, rutekan data ke log Azure Monitor dan jalankan kueri yang lebih kompleks di Analitik Log.
Application Insights memantau ketersediaan, performa, dan penggunaan aplikasi web Anda, sehingga Anda dapat mengidentifikasi dan mendiagnosis kesalahan tanpa menunggu pengguna melaporkannya.
Application Insights mencakup titik koneksi ke berbagai alat pengembangan dan terintegrasi dengan Visual Studio untuk mendukung proses DevOps Anda. Untuk informasi selengkapnya, lihat Pemantauan aplikasi untuk App Service.
Alat yang memungkinkan visualisasi yang lebih kompleks meliputi:
- Dasbor yang memungkinkan Anda menggabungkan berbagai jenis data ke dalam satu panel di portal Azure.
- Buku kerja, laporan yang dapat disesuaikan yang bisa Anda buat di portal Azure. Buku kerja dapat menyertakan kueri teks, metrik, dan log.
- Grafana, alat platform terbuka yang unggul di dasbor operasional. Anda dapat menggunakan Grafana untuk membuat dasbor yang menyertakan data dari beberapa sumber selain Azure Monitor.
- Power BI, layanan analitik bisnis yang menyediakan visualisasi interaktif di berbagai sumber data. Anda dapat mengonfigurasi Power BI untuk mengimpor data log secara otomatis dari Azure Monitor untuk memanfaatkan visualisasi ini.
Mengekspor data Azure Monitor
Anda dapat mengekspor data dari Azure Monitor ke alat lain menggunakan:
Metrik: Gunakan REST API untuk metrik untuk mengekstrak data metrik dari database metrik Azure Monitor. Untuk informasi selengkapnya, lihat Referensi REST API Azure Monitor.
Log: Gunakan REST API atau pustaka klien terkait.
Ekspor data ruang kerja Analitik Log.
Untuk mulai menggunakan REST API Azure Monitor, lihat Panduan REST API pemantauan Azure.
Menggunakan kueri Kusto untuk menganalisis data log
Anda dapat menganalisis data Log Azure Monitor menggunakan bahasa kueri Kusto (KQL). Untuk informasi selengkapnya, lihat Mencatat kueri di Azure Monitor.
Menggunakan pemberitahuan Azure Monitor untuk memberi tahu Anda tentang masalah
Pemberitahuan Azure Monitor memungkinkan Anda mengidentifikasi dan mengatasi masalah dalam sistem Anda, dan secara proaktif memberi tahu Anda saat kondisi tertentu ditemukan di data pemantauan Anda sebelum pelanggan Anda memperhatikannya. Anda dapat memperingatkan metrik atau sumber data log apa pun di platform data Azure Monitor. Ada berbagai jenis pemberitahuan Azure Monitor tergantung pada layanan yang Anda pantau dan data pemantauan yang Anda kumpulkan. Lihat Memilih jenis aturan pemberitahuan yang tepat.
Untuk contoh pemberitahuan umum untuk sumber daya Azure, lihat Contoh kueri pemberitahuan log.
Menerapkan pemberitahuan dalam skala besar
Untuk beberapa layanan, Anda dapat memantau dalam skala besar dengan menerapkan aturan pemberitahuan metrik yang sama ke beberapa sumber daya dengan jenis yang sama yang ada di wilayah Azure yang sama. Azure Monitor Baseline Alerts (AMBA) menyediakan metode semi-otomatis untuk menerapkan pemberitahuan metrik platform, dasbor, dan panduan penting dalam skala besar.
Mendapatkan rekomendasi yang dipersonalisasi menggunakan Azure Advisor
Untuk beberapa layanan, jika kondisi penting atau perubahan segera terjadi selama operasi sumber daya, pemberitahuan ditampilkan di halaman Gambaran Umum layanan di portal. Anda dapat menemukan informasi selengkapnya dan perbaikan yang direkomendasikan untuk pemberitahuan di rekomendasi Advisor di bawah Pemantauan di menu sebelah kiri. Selama operasi normal, tidak ada rekomendasi advisor yang ditampilkan.
Untuk informasi selengkapnya tentang Azure Advisor, lihat Gambaran umum Azure Advisor.