Memantau metrik dan log di Azure Front Door
Azure Front Door menyediakan beberapa fitur untuk membantu Anda memantau aplikasi, melacak permintaan, dan men-debug konfigurasi Front Door Anda.
Log dan metrik disimpan dan dikelola oleh Azure Monitor.
Laporan memberikan wawasan tentang bagaimana lalu lintas Anda mengalir melalui Azure Front Door, firewall aplikasi web (WAF), dan ke aplikasi Anda.
Metrik
Azure Front Door mengukur dan mengirimkan metriknya dalam interval 60 detik. Metrik dapat memakan waktu hingga 3 menit untuk diproses oleh Azure Monitor, dan metrik mungkin tidak muncul sampai pemrosesan selesai. Metrik juga dapat ditampilkan dalam bagan atau kisi, dan dapat diakses melalui portal Azure, Azure PowerShell, Azure CLI, dan AZURE Monitor API. Untuk informasi lebih lengkap, lihat Metrik Azure Monitor .
Metrik yang tercantum dalam tabel berikut direkam dan disimpan secara gratis untuk jangka waktu terbatas. Dengan biaya tambahan, Anda dapat menyimpan untuk jangka waktu yang lebih lama.
| Metrik | Deskripsi | Dimensi | Agregasi yang direkomendasikan |
|---|---|---|---|
| Byte Hit Ratio | Persentase lalu lintas yang dilayani dari cache Azure Front Door, dihitung terhadap total lalu lintas keluar. Rasio byte hit rendah jika sebagian besar lalu lintas diteruskan ke asal daripada dilayani dari cache. Rasio Byte Hit = (keluar dari tepi - keluar dari asal)/keluar dari tepi. Skenario yang dikecualikan dari perhitungan rasio hit byte:
|
Titik akhir | Rata-rata, Min |
| Origin Health Percentage | Persentase pemeriksaan kesehatan yang berhasil dikirim dari Azure Front Door ke asal. | Asal Usul, Grup Asal | Avg |
| Origin Latency | Azure Front Door menghitung waktu dari mengirim permintaan ke asal untuk menerima byte respons terakhir dari asal. | Titik akhir, Asal | Rata-rata, Maks |
| Origin Request Count | Jumlah permintaan yang dikirim dari Azure Front Door ke asal. | Titik akhir, Asal, Status HTTP, Grup Status HTTP | Rata-rata, Jumlah |
| Percentage of 4XX | Persentase semua permintaan klien yang kode status responsnya adalah 4XX. | Titik akhir, Negara Klien, Wilayah Klien | Rata-rata, Maks |
| Percentage of 5XX | Persentase semua permintaan klien yang kode status responsnya adalah 5XX. | Titik akhir, Negara Klien, Wilayah Klien | Rata-rata, Maks |
| Jumlah Permintaan | Jumlah permintaan klien yang dilayani melalui Azure Front Door, termasuk permintaan yang dilayani sepenuhnya dari cache. | Titik akhir, Negara Klien, Wilayah Klien, Status HTTP, Grup Status HTTP | Rata-rata, Jumlah |
| Permintaan Ukuran | Jumlah byte yang dikirim dalam permintaan dari klien ke Azure Front Door. | Titik akhir, Negara Klien, Wilayah klien, Status HTTP, Grup Status HTTP | Rata-rata, Maks |
| Ukuran respons | Jumlah byte yang dikirim sebagai tanggapan dari Front Door kepada klien. | Titik akhir, Negara klien, Wilayah klien, Status HTTP, Grup Status HTTP | Rata-rata, Maks |
| Latensi Total | Azure Front Door menerima permintaan klien dan mengirim byte respons terakhir ke klien. Ini adalah total waktu yang dibutuhkan. | Titik akhir, Negara Klien, Wilayah Klien, Status HTTP, Grup Status HTTP | Rata-rata, Maks |
| Jumlah Permintaan Firewall Aplikasi Web | Jumlah permintaan yang diproses oleh firewall aplikasi web Azure Front Door. | Tindakan, Nama Kebijakan, Nama Aturan | Rata-rata, Jumlah |
Catatan
Jika permintaan ke waktu asal habis, nilai dimensi Status Http adalah 0.
Log
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). |
| 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. |
| Pusat Respons | Ukuran pesan respons HTTP dalam byte. |
| 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 | Lamanya waktu dari ketika tepi Azure Front Door menerima permintaan klien hingga saat Azure Front Door mengirim byte terakhir respons kepada klien, dalam hitungan detik. Bidang ini tidak memperhitungkan latensi jaringan dan buffering TCP. |
| RequestProtocol | Protokol yang ditentukan klien dalam permintaan. Nilai yang mungkin termasuk: HTTP, HTTPS. |
| 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 permintaan ditangani oleh cache Azure Front Door. 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 URL permintaan ditulis ulang oleh Mesin Aturan, 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 telah memperhatikan 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 minat jika asal dikonfigurasi untuk menggunakan FDQN. |
| 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 FDQN, bukan 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.
Log aktivitas
Log aktivitas menyediakan informasi tentang operasi manajemen pada sumber daya Azure Front Door Anda. Log mencakup detail tentang setiap operasi tulis yang dilakukan pada sumber daya Azure Front Door, termasuk ketika operasi terjadi, siapa yang melakukannya, dan apa operasinya.
Catatan
Log aktivitas tidak menyertakan operasi baca. Mereka juga mungkin tidak menyertakan semua operasi yang Anda lakukan dengan menggunakan API manajemen portal Azure atau klasik.
Untuk informasi selengkapnya, lihat Menampilkan log aktivitas Anda.
Langkah berikutnya
Untuk mengaktifkan dan menyimpan log diagnostik Anda, lihat Mengonfigurasi log Azure Front Door.
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).
Saat menggunakan Azure Front Door (klasik), Anda dapat memantau sumber daya dengan cara berikut:
- Metrik. Azure Front Door saat ini memiliki delapan metrik untuk melihat penghitung kinerja.
- Logs. Log aktivitas dan diagnostik memungkinkan kinerja, akses, dan data lainnya disimpan atau dikonsumsi dari sumber daya untuk tujuan pemantauan.
Metrik
Metrik adalah fitur untuk sumber daya Azure tertentu yang memungkinkan Anda melihat penghitung kinerja di portal. Berikut ini adalah metrik Front Door yang tersedia:
| Metric | Nama Tampilan Metrik | Unit | Dimensi | Deskripsi |
|---|---|---|---|---|
| RequestCount | Jumlah Permintaan | Hitung | HttpStatus HttpStatusGroup ClientRegion ClientCountry |
Jumlah permintaan klien yang dilayani oleh Front Door. |
| RequestSize | Permintaan Ukuran | Byte | HttpStatus HttpStatusGroup ClientRegion ClientCountry |
Jumlah byte yang dikirim sebagai permintaan dari klien ke Front Door. |
| ResponseSize | Ukuran respons | Byte | HttpStatus HttpStatusGroup ClientRegion ClientCountry |
Jumlah byte yang dikirim sebagai tanggapan dari Front Door kepada klien. |
| TotalLatency | Latensi Total | Milidetik | HttpStatus HttpStatusGroup ClientRegion ClientCountry |
Total waktu dari permintaan klien yang diterima oleh Front Door hingga byte respons terakhir yang dikirim dari AFD ke klien. |
| BackendRequestCount | Jumlah Permintaan Backend | Hitung | HttpStatus HttpStatusGroup Backend |
Jumlah permintaan yang dikirim dari Front Door ke backend. |
| BackendRequestLatency | Latensi Permintaan Backend | Milidetik | Backend | Waktu dihitung dari ketika permintaan dikirim oleh Front Door ke backend sampai Front Door menerima byte respons terakhir dari backend. |
| BackendHealthPercentage | Persentase Kondisi Backend | Persen | Backend BackendPool |
Persentase penyelidikan kesehatan yang berhasil dari Front Door ke backend. |
| WebApplicationFirewallRequestCount | Jumlah Permintaan Firewall Aplikasi Web | Hitung | PolicyNameRuleNameAction |
Jumlah permintaan klien yang diproses oleh keamanan lapisan aplikasi Front Door. |
Log aktivitas
Log aktivitas memberikan informasi tentang operasi yang dilakukan pada profil Azure Front Door (klasik). Mereka juga menentukan apa, siapa, dan kapan untuk operasi tulis apa pun (letakkan, posting, atau hapus) yang dilakukan terhadap profil Azure Front Door (klasik).
Catatan
Jika permintaan ke waktu asal habis, nilai untuk HttpStatusCode diatur ke 0.
Akses log aktivitas di Front Door Anda atau semua log sumber daya Azure Anda di Azure Monitor. Untuk melihat log aktivitas:
Pilih instans Front Door Anda.
Pilih Log aktivitas.
Pilih lingkup pemfilteran, lalu pilih Terapkan.
Catatan
Log aktivitas tidak menyertakan operasi GET atau operasi apa pun yang Anda lakukan dengan menggunakan portal Azure atau API Manajemen asli.
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 telah 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: Kegagalan permintaan karena koneksi jaringan klien. UnspecifiedClientError: Kesalahan klien generik. 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: Koneksi dengan asal dihentikan secara tiba-tiba. OriginConnectionError: Kesalahan koneksi asal generik. OriginConnectionRefused: Koneksi dengan asal tidak dapat dibuat. OriginError: Kesalahan asal generik. OriginInvalidResponse: Origin mengembalikan respons yang tidak valid atau tidak dikenali. OriginTimeout: Periode batas waktu untuk permintaan asal kedaluwarsa. ResponseHeaderTooBig: Asal mengembalikan header respons yang terlalu besar. RestrictedIP: Permintaan diblokir karena IP terbatas. SSLHandshakeError: Tidak dapat membangun koneksi dengan asal karena kegagalan shake tangan SSL. UnspecifiedError: Terjadi kesalahan yang tidak sesuai dalam salah satu 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 penjaluran dan perilaku lalu lintas, beberapa bidang seperti backendHostname, TembolokStatus, isReceivedFromClient, dan bidang POP dapat merespons dengan nilai yang berbeda. Tabel berikut menjelaskan nilai yang berbeda yang akan 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 caching, nilai untuk Status Cache akan menjadi partial_hit ketika beberapa byte untuk permintaan dilayani dari tepi Azure Front Door atau cache pelindung 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.
Langkah berikutnya
- Pelajari cara membuat profil Azure Front Door (klasik)
- Pelajari cara kerja Azure Front Door (klasik)