Catatan
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba masuk atau mengubah direktori.
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba mengubah direktori.
Peringatan adalah bagian penting dari pemantauan beban kerja pada Azure Kubernetes Service (AKS). Pemberitahuan tingkat lanjut memerlukan log tingkat Analitik di ruang kerja Analitik Log Anda, tetapi ini dapat membebani biaya untuk lingkungan volume tinggi atau jenis log tertentu seperti log audit.
Anda dapat secara signifikan mengurangi biaya penyerapan data dengan mengonversi tabel yang menyimpan log kontainer ke log Dasar dan memanfaatkan strategi hemat biaya lainnya dari platform Analitik Log. Azure Monitor menyediakan opsi untuk peringatan berbasis peristiwa dan ringkasan pada tabel ini, memberi Anda kontrol lebih besar atas biaya tanpa mengorbankan visibilitas ke dalam kesehatan dan perilaku beban kerja AKS Anda.
Artikel ini menjelaskan beberapa strategi untuk memberi tahu tentang beban kerja AKS yang dipantau dengan konfigurasi log hemat biaya. Rekomendasi ini membantu Anda menyeimbangkan biaya dan performa sambil tetap memenuhi kebutuhan operasional dan tujuan tingkat layanan (SLA).
Tabel berikut ini meringkas strategi yang dibahas dalam artikel ini, termasuk kapan harus menggunakannya dan tabel mana yang paling berlaku untuk mereka:
| Strategi | Kapan harus menggunakan |
|---|---|
| Pemberitahuan Prometheus terkelola | Ketika metrik tersedia, terutama untuk status pod, node, atau kontainer. Metrik harus menjadi pilihan pertama Anda untuk memperingatkan jika memungkinkan. Pemberitahuan ini real time, dapat diskalakan, dan hemat biaya. Hanya gunakan pemberitahuan log saat metrik tidak tersedia. |
| Aturan pemberitahuan pencarian log sederhana (pratinjau) | Saat Anda perlu memantau pesan atau pola tertentu yang tidak tersedia dengan metrik. Ini adalah pemberitahuan cepat berbasis log per kejadian dengan kompleksitas rendah, seperti memperingatkan kesalahan akses yang tidak sah atau kesalahan agen. Mereka paling efektif ketika konten log membawa konteks kritis yang jelas pada saat terjadi kegagalan. |
| Aturan ringkasan | Saat Anda perlu melakukan agregasi dari waktu ke waktu, seperti menghitung peristiwa kesalahan atau pengelompokan menurut dimensi seperti ID kontainer. Gunakan aturan ringkasan saat pemberitahuan sederhana tidak cukup untuk kebutuhan Anda. Ini mungkin memberikan peringatan mengenai pola-pola tertentu, terkait jumlah kegagalan per menit, atau pada arah tren dari ukuran tertentu (misalnya, CrashLoopBackOffs berulang atau >10 kegagalan per menit) yang tidak mudah terdeteksi dengan peringatan atau metrik sederhana. |
| Tingkat analitik dengan transformasi | Gunakan untuk pemberitahuan hampir real-time pada data log bernilai tinggi ketika metode lain seperti Aturan Ringkasan terlalu lambat atau tidak cukup terperinci. Transformasi memungkinkan pemfilteran dan pembentukan log sebelum mengirimkannya ke tingkat Analitik, mengurangi biaya sambil mengaktifkan pemberitahuan dan dasbor terperinci. Ideal untuk wawasan yang penting untuk misi di mana ketepatan waktu sangat penting. |
Peringatan Prometheus yang dikelola
Jika memungkinkan, Anda harus memprioritaskan pemberitahuan pada metrik daripada log, karena ini biasanya lebih dapat diskalakan dan hemat biaya, terutama di lingkungan AKS besar. Metrik dirancang khusus agar ringkas dan untuk evaluasi cepat, serta menghasilkan biaya pemasukan, penyimpanan, dan kueri yang lebih rendah dibandingkan dengan log.
Azure Managed Prometheus memungkinkan pengambilan metrik dan pemberitahuan mendekati real-time tanpa beban mengelola infrastruktur Prometheus Anda sendiri. Ini terintegrasi langsung dengan kluster AKS Anda dan mendukung pengikisan metrik asli Kubernetes menggunakan format Prometheus. Aturan pemberitahuan dapat divisualisasikan dan dianalisis di Azure Managed Grafana atau diintegrasikan ke dalam Azure Monitor untuk perutean pemberitahuan.
Mulailah dengan mengaktifkan aturan pemberitahuan yang direkomendasikan. Ini termasuk pemberitahuan metrik platform seperti mengaktifkan ketika CPU dari suatu node melebihi ambang batas. Anda juga dapat mengaktifkan berbagai tingkat pemberitahuan Prometheus untuk berbagai skenario. Selain aturan pemberitahuan bawaan, buat aturan pemberitahuan kustom Anda sendiri menggunakan metrik Prometheus.
Pemberitahuan Prometheus terkelola biasanya dapat digunakan untuk mengganti pemberitahuan dari tabel berikut:
Aturan peringatan pencarian log sederhana (pratinjau)
Pemberitahuan pencarian log sederhana di Azure Monitor dirancang untuk menyediakan alternatif yang lebih sederhana dan lebih cepat untuk pemberitahuan pencarian log tradisional, dan didukung pada tabel Log Dasar. Tidak seperti pemberitahuan pencarian log yang menggabungkan baris selama periode yang ditentukan, pemberitahuan log sederhana mengevaluasi setiap baris satu per satu dan mengizinkan pencarian log kondisi tunggal. Mereka ideal untuk skenario seperti menonton peristiwa kesalahan atau perubahan status tertentu.
Misalnya, Anda dapat menetapkan aturan untuk memicu setiap terjadinya pesan kesalahan tertentu dari aplikasi berbasis cloud, atau Anda dapat memilih untuk memicu pada pesan apa pun dengan tingkat keparahan kesalahan.
Selain menjalankan setiap kali pesan muncul, Anda juga dapat menentukan ambang batas untuk jumlah kemunculan dalam jendela waktu tertentu. Misalnya, Anda mungkin memiliki pesan yang menunjukkan gagal masuk dan ingin diberi tahu ketika jumlah upaya masuk yang gagal dalam aplikasi mereka dalam satu menit melebihi ambang batas. Setelah diidentifikasi, Anda dapat menggunakan kueri log pada tabel itu sendiri untuk mengidentifikasi upaya masuk yang gagal
Pemberitahuan pencarian log sederhana umumnya digunakan untuk pemberitahuan dari tabel berikut:
Aturan ringkasan
Aturan ringkasan adalah kueri terjadwal yang berjalan pada interval yang ditentukan untuk melakukan agregasi atau transformasi dan menyimpan hasilnya dalam tabel tingkat Analitik kustom. Ini memungkinkan Anda untuk menyerap log kontainer Anda ke dalam tabel Log Dasar lalu melakukan analisis dan peringatan tingkat lanjut pada versi agregat data.
Pertimbangkan skenario di mana Anda ingin memantau tingkat kesalahan di log kontainer Anda. Menggunakan panduan di Membuat atau memperbarui aturan ringkasan, buat aturan ringkasan dengan kueri seperti berikut ini, yang menghitung jumlah log tingkat kesalahan untuk setiap kontainer.
ContainerLogv2
| where LogLevel == "Error"
| summarize ErrorCount = count() by ContainerID
Petunjuk / Saran
Untuk mengurangi biaya pemindaian, gunakan kueri yang mengembalikan beberapa agregasi dan dimensi yang dapat digunakan oleh beberapa aturan pemberitahuan.
Buat pemberitahuan kueri log dengan jendela yang lebih besar dari ukuran biner pada tabel tingkat Analitik baru untuk memberi tahu saat jumlah kesalahan melebihi ambang yang ditentukan. Misalnya, jika ukuran bin adalah 30 menit, Anda dapat membuat aturan pemberitahuan dengan jendela 1 jam sehingga setiap evaluasi pemberitahuan akan menyertakan dua ringkasan.
Nota
Aturan ringkasan saat ini mendukung ukuran minimum penyimpanan data 20 menit. Jika Anda memerlukan pemberitahuan dengan latensi yang lebih rendah, pertimbangkan untuk menggunakan tingkat Analitik dengan transformasi seperti yang dijelaskan di bawah ini.
Pemberitahuan dari aturan ringkasan umumnya digunakan untuk pemberitahuan dari tabel berikut:
Tingkatan analisis dengan transformasi
Aturan ringkasan mungkin tidak cukup responsif jika Anda memerlukan pemberitahuan hampir real time pada log kontainer. Dalam skenario sensitif secara operasional di mana pemberitahuan log mendekati real-time diperlukan, gunakan transformasi untuk merutekan log bernilai tinggi (seperti kesalahan dan peristiwa penting) ke tabel Log Analitik saat mengirim log lain ke tabel Log Dasar atau Log Tambahan. Dengan menggunakan strategi ini, Anda dapat melakukan pemberitahuan lanjutan pada tabel di tingkat Analitik sambil merutekan data lain ke tingkat biaya yang lebih rendah untuk penyimpanan hemat biaya dan analisis sesekali.
Konfigurasi terperinci untuk transformasi ini disediakan dalam Transformasi data dalam wawasan Kontainer.
Strategi ini umumnya digunakan untuk pemberitahuan dari tabel berikut: