Service Mesh (ASM) menyediakan Pemantauan Peringatan bawaan berdasarkan Service Level Objectives (SLO). Pemantauan SLO melacak metrik kinerja—seperti latensi dan laju error—untuk panggilan antar layanan aplikasi, memberikan tolok ukur bersama bagi pengembang aplikasi, operator platform, dan personel O&M guna mengukur serta meningkatkan kualitas layanan.
Istilah kunci
Service level indicator (SLI): Metrik kuantitatif yang mengukur kesehatan layanan, seperti ketersediaan atau latensi respons.
Service level objective (SLO): Persentase target untuk SLI dalam periode tertentu. Satu SLO terdiri dari satu atau beberapa SLI. Menggabungkan beberapa SLI ke dalam satu SLO memberikan gambaran yang lebih akurat mengenai kesehatan layanan secara keseluruhan.
Error budget: Jumlah ketidakandalan yang diperbolehkan yang dihitung dari target SLO (100% – target SLO). Gunakan error budget untuk menyeimbangkan keandalan dengan kecepatan pengembangan—budget ini merepresentasikan anggaran risiko yang dapat Anda alokasikan untuk merilis fitur.
Contoh SLO:
Rata-rata queries per second (QPS) > 100.000/s
Latensi 99% permintaan < 500 ms
Bandwidth per menit untuk 99% permintaan > 200 MB/s
Jenis SLI
ASM mendukung dua jenis SLI:
| Jenis SLI | Apa yang diukur | Jenis plug-in | Kondisi kegagalan |
|---|---|---|---|
| Service availability | Proporsi permintaan yang menerima respons sukses | availability | Kode status HTTP adalah 429 atau 5XX (kode apa pun yang dimulai dengan 5) |
| Latency | Waktu yang dibutuhkan layanan untuk memberikan respons | latency | Waktu respons melebihi batas maksimum yang ditentukan |
Tetapkan tujuan yang bermakna
Tujuan harus mencerminkan dampak nyata terhadap pengguna. Misalnya, jika pengguna tidak dapat membedakan antara latensi 200 ms dan 600 ms, tetapkan tujuan latensi menjadi 600 ms.
Layanan yang berbeda memerlukan target berbeda berdasarkan tingkat kritisnya:
| Target ketersediaan | Downtime perkiraan per tahun | Penggunaan umum |
|---|---|---|
| 99% | ~3 hari | Layanan non-kritis |
| 99,999% | ~5 menit | Layanan mission-critical |
Periode kepatuhan
Periode kepatuhan menentukan durasi pengukuran SLI terhadap target SLO. Persentase target yang sama memiliki implikasi sangat berbeda pada skala waktu yang berbeda:
| Periode kepatuhan | Ketersediaan 99% memungkinkan downtime berkelanjutan hingga |
|---|---|
| 1 hari | ~14 menit (24 jam x 1%) |
| 30 hari | ~7 jam (30 hari x 1%) |
ASM mendukung periode kepatuhan 7, 14, 28, dan 30 hari.
Error budget
Error budget mengkuantifikasi seberapa banyak kegagalan yang diizinkan oleh SLO sebelum terjadi pelanggaran.
Rumus: Error budget = 100% – target SLO
Contoh: Pertimbangkan layanan dengan parameter berikut:
| Parameter | Nilai |
|---|---|
| Kondisi kegagalan SLI | Kode status HTTP adalah 429 atau 5XX |
| Periode kepatuhan | 30 hari |
| Target SLO | 99,9% |
| Error budget | 0,1% (100% – 99,9%) |
| Total permintaan dalam 30 hari | 10.000 |
| Permintaan error yang diizinkan | 10 (10.000 x 0,1%) |
Untuk memenuhi SLO ini, tidak boleh lebih dari 10 permintaan gagal dalam jendela 30 hari tersebut.
Gunakan error budget untuk membimbing keputusan
Error budget menyediakan kerangka berbasis data untuk menyeimbangkan keandalan dengan kecepatan pengembangan:
Budget hampir habis: Hindari deployment versi baru. Fokus pada keandalan.
Budget tersisa di akhir periode kepatuhan: Lakukan deployment pembaruan, karena risiko pelanggaran SLO rendah.
Error budget dihitung menggunakan jendela rolling yang setara dengan periode kepatuhan:
Error budget >= 0: SLO terpenuhi dalam periode kepatuhan.
Error budget < 0: Terjadi pelanggaran SLO.
Burn rate
Burn rate mengukur seberapa cepat error budget dikonsumsi relatif terhadap periode kepatuhan. Burn rate sebesar 1 berarti budget akan habis tepat dalam periode kepatuhan. Burn rate sebesar 2 berarti budget akan habis dalam separuh waktu tersebut.
Rumus: Burn rate = Laju error / (1 – SLO)
Untuk menghitung berapa lama hingga budget habis, bagi periode kepatuhan dengan burn rate.
Contoh untuk periode kepatuhan 30 hari:
| Burn rate | Waktu hingga error budget habis | Makna |
|---|---|---|
| 1 | 30 hari (30 / 1) | Budget dikonsumsi persis sesuai kecepatan yang diharapkan |
| 2 | 15 hari (30 / 2) | Budget dikonsumsi dengan kecepatan 2x dari yang diharapkan |
| 60 | 12 jam (30 / 60) | Budget dikonsumsi dengan kecepatan 60x dari yang diharapkan — perlu perhatian segera |
Aturan peringatan
Aturan peringatan memberi tahu Anda saat error budget dikonsumsi terlalu cepat, memberi waktu untuk merespons sebelum terjadi pelanggaran SLO.
ASM menggunakan pendekatan multi-window burn rate. Metode ini mendeteksi baik burn cepat (laju error tinggi dalam periode singkat) maupun burn lambat (laju error moderat dalam periode panjang), sekaligus menyaring peringatan yang tidak perlu akibat lonjakan singkat dan kecil.
Cara kerja peringatan multi-jendela
Setiap aturan peringatan menggunakan dua jendela waktu:
| Jendela | Peran | Unit |
|---|---|---|
| Jendela panjang | Detection — mengukur burn rate dalam periode panjang untuk mengidentifikasi masalah berkelanjutan | Jam hingga hari |
| Jendela pendek | Recovery — memeriksa burn rate terkini untuk segera menghapus peringatan setelah masalah terselesaikan | Menit (1/12 dari jendela panjang) |
Peringatan hanya aktif jika burn rate melebihi ambang batas di kedua jendela. Desain dua jendela ini mencegah peringatan usang tetap aktif setelah kesalahan diperbaiki.
Peringatan fast burn vs. slow burn
Untuk SLO 30 hari, ASM mendukung dua tingkat keparahan peringatan yang sesuai dengan pola burn berbeda:
| Jenis peringatan | Pola Pembakaran | Kondisi pemicu | Ambang batas burn rate |
|---|---|---|---|
| Tingkat Halaman (pembakaran cepat) | Laju error tinggi dalam periode singkat — memerlukan perhatian segera | 2% error budget dikonsumsi dalam 1 jam, atau 5% dikonsumsi dalam 6 jam | 14,4x atau 6x |
| Ticket-level (bertahap) | Laju error moderat dalam periode panjang — selidiki selama jam kerja | 10% error budget dikonsumsi dalam 1 hari, atau lebih dari 3 hari | 3x atau 1x |
Mengapa jendela pendek penting
Tanpa jendela pendek, peringatan tetap aktif sepanjang durasi jendela panjang meskipun kesalahan dasar telah diperbaiki. Dengan jendela pendek yang diatur menjadi 1/12 dari jendela panjang, peringatan akan hilang tak lama setelah laju error turun.
Contoh: Laju error tetap pada 2x ambang batas selama 3 hari. Kesalahan diperbaiki pada hari ke-3. Dengan konfigurasi jendela pendek, peringatan akan hilang sekitar 6 jam kemudian. Tanpa jendela pendek, peringatan akan tetap aktif selama 3 hari penuh setelah kesalahan diperbaiki.