Service Mesh (ASM) menyediakan kemampuan pemantauan dan peringatan siap pakai berdasarkan tujuan tingkat layanan (SLO). Anda dapat memantau metrik kinerja panggilan antara layanan aplikasi, seperti latensi dan tingkat kesalahan. Topik ini menjelaskan konsep-konsep terkait SLO.
SLI dan SLO
Indikator tingkat layanan (SLI) adalah metrik yang mengukur kesehatan layanan. SLO adalah tujuan atau rentang tujuan yang harus dicapai oleh suatu layanan. SLO terdiri dari satu atau lebih SLI.
SLO memberikan cara formal untuk mendeskripsikan, mengukur, dan memantau kinerja, kualitas, dan keandalan aplikasi berbasis layanan mikro. SLO adalah tolok ukur kualitas bersama bagi pengembang aplikasi, operator platform, dan personel O&M. Mereka dapat menggunakan SLO sebagai referensi untuk mengukur dan terus meningkatkan kualitas layanan. SLO yang terdiri dari beberapa SLI membantu mendeskripsikan kesehatan layanan dengan cara yang lebih akurat.
Contoh SLO:
Rata-rata permintaan per detik (QPS) > 100.000/s
Latensi 99% permintaan akses < 500 ms
Bandwidth per menit untuk 99% permintaan akses > 200 MB/s
Jenis SLI dan tujuan
ASM mendukung jenis SLI berikut:
Ketersediaan layanan: menunjukkan proporsi permintaan akses yang berhasil direspons. Jenis plugin untuk jenis SLI ini adalah availability. Jika kode status HTTP yang dikembalikan ke permintaan akses adalah 429 atau 5XX, permintaan akses tidak berhasil direspons. 5XX berarti bahwa kode status dimulai dengan 5.
Latensi: menunjukkan waktu yang diperlukan untuk layanan mengembalikan respons terhadap permintaan. Jenis plugin untuk jenis SLI ini adalah latency. Anda dapat menentukan latensi maksimum. Respons yang dikembalikan lebih lambat dari periode waktu yang ditentukan dianggap tidak memenuhi syarat.
Selain mendefinisikan jenis SLI, Anda juga perlu menetapkan tujuan. Tujuan harus masuk akal. Misalnya, jika pengguna Anda tidak dapat membedakan antara latensi 200 ms dan 600 ms, tetapkan tujuan latensi menjadi 600 ms.
Anda juga perlu mempertimbangkan persyaratan pengguna saat menetapkan tujuan. Aplikasi yang berbeda perlu mencapai tujuan yang berbeda, bergantung pada persyaratan pengguna untuk aplikasi tersebut. Misalnya, pengguna mungkin mengharapkan sistem layanan non-kritis memenuhi tujuan ketersediaan 99%, dan sistem layanan kritis memenuhi tujuan ketersediaan 99,999%. Ketersediaan 99% memungkinkan sekitar tiga hari downtime per tahun, sedangkan ketersediaan 99,999% memungkinkan sekitar lima menit downtime per tahun.
Periode kepatuhan
Anda perlu menentukan periode waktu untuk SLO, selama mana SLI diukur. Misalnya, tujuan ketersediaan 99% yang berlaku dalam satu hari dan tujuan yang sama yang berlaku dalam satu bulan berbeda. Tujuan ketersediaan 99% yang berlaku dalam satu hari tidak mengizinkan downtime berkelanjutan lebih dari 14 menit (24 jam x 1%). Tujuan ketersediaan 99% yang berlaku dalam satu bulan mengizinkan downtime berkelanjutan hingga sekitar 7 jam (30 hari x 1%).
Untuk menyederhanakan konfigurasi, periode kepatuhan hanya bisa 7, 14, 28, dan 30 hari.
Anggaran kesalahan
Anggaran kesalahan menunjukkan tunjangan untuk jumlah kegagalan tertentu atau utang teknis dalam SLO. Oleh karena itu, Anda dapat menghitung anggaran kesalahan dengan menggunakan rumus berikut: Anggaran kesalahan = 100% - SLO. Dalam rumus tersebut, SLO adalah persentase yang harus dicapai.
Contoh:
Kegagalan SLI: kode status yang dikembalikan ke permintaan
Periode kepatuhan: 30 hari
SLO: 99,9%
Anggaran kesalahan: 0,1% (100% - 99,9%)
Total jumlah permintaan dalam 30 hari: 10.000
Jumlah permintaan kesalahan yang diizinkan: 10 (10.000 * 0,1%)
Untuk mencapai SLO, maksimal 10 permintaan kesalahan diizinkan setiap 30 hari. Anda dapat merencanakan dan mengelola tugas dengan lebih baik dengan merujuk pada anggaran kesalahan. Misalnya, Anda dapat memutuskan kapan menerapkan versi baru berdasarkan anggaran kesalahan:
Ketika Anda hampir kehabisan anggaran kesalahan, kami sarankan Anda tidak menerapkan versi baru.
Lakukan pembaruan versi ketika anggaran kesalahan cukup pada akhir periode kepatuhan. Dalam hal ini, probabilitas pelanggaran SLO rendah.
Anggaran kesalahan diperbarui melalui jendela bergulir yang memiliki rentang waktu yang sama dengan periode kepatuhan.
Jika anggaran kesalahan lebih besar dari atau sama dengan 0, itu menunjukkan bahwa SLO tercapai dalam periode kepatuhan.
Jika anggaran kesalahan lebih kecil dari 0, itu menunjukkan bahwa pelanggaran SLO terjadi dalam periode kepatuhan.
Laju pembakaran
Laju pembakaran menunjukkan kecepatan anggaran kesalahan Anda dikonsumsi. Laju pembakaran adalah rasio tingkat kesalahan saat ini terhadap anggaran kesalahan yang ditentukan. Laju pembakaran yang lebih tinggi menunjukkan kesalahan yang lebih parah. Aturan peringatan dikonfigurasikan berdasarkan laju pembakaran. Peringatan dipicu jika laju pembakaran mencapai nilai yang ditentukan.
Rumus perhitungan: Laju pembakaran = Tingkat kesalahan/(1 - SLO)
Anggaplah periode kepatuhan adalah 30 hari:
Laju pembakaran 1: Jika tingkat kesalahan dipertahankan pada level saat ini, 100% anggaran kesalahan akan digunakan selama periode kepatuhan penuh. Artinya, anggaran kesalahan habis dalam 30 hari.
Laju pembakaran 2: Jika tingkat kesalahan dipertahankan pada level saat ini, 200% anggaran kesalahan akan digunakan selama periode kepatuhan penuh. Artinya, anggaran kesalahan habis dalam 15 hari.
Laju pembakaran 60: Jika tingkat kesalahan dipertahankan pada level saat ini, 6000% anggaran kesalahan akan digunakan selama periode kepatuhan penuh. Artinya, anggaran kesalahan habis dalam 12 jam.
Aturan peringatan
Aturan peringatan memungkinkan Anda menerima peringatan berbagai tingkat berdasarkan tingkat keparahan kesalahan. Dengan cara ini, Anda dapat menangani kesalahan secara tepat waktu untuk mencegah anggaran kesalahan dikonsumsi secara berlebihan.
ASM memungkinkan Anda mengonfigurasi aturan peringatan yang menentukan ambang batas laju pembakaran yang berbeda untuk jendela waktu yang berbeda. Metode konfigurasi ini berlaku untuk sebagian besar skenario. Baik tingkat kesalahan tinggi dalam periode waktu singkat maupun tingkat kesalahan rendah dalam periode waktu panjang memicu peringatan. Sementara itu, hanya tingkat kesalahan tinggi dalam periode waktu singkat atau tingkat kesalahan rendah dalam periode waktu panjang yang memicu peringatan. Ini mencegah personel O&M melewatkan masalah penting karena peringatan yang tidak perlu mengalihkan perhatian mereka. Anda dapat menetapkan jendela waktu pendek saat menghitung tingkat kesalahan dalam periode waktu tertentu. Saat tingkat kesalahan dalam jendela waktu pendek lebih rendah dari ambang batas yang ditentukan, peringatan diakhiri. Konfigurasi jendela waktu pendek memastikan bahwa peringatan dapat dibersihkan secara tepat waktu.
Contoh jendela waktu pendek untuk SLO 30 hari:
Jika 2% anggaran kesalahan dikonsumsi dalam satu jam atau 5% anggaran kesalahan dikonsumsi dalam enam jam, peringatan tingkat Page dipicu. Artinya, jika tingkat kesalahan 14,4 kali atau enam kali ambang batas yang ditentukan, peringatan tingkat Page dipicu. Jika 10% anggaran kesalahan dikonsumsi dalam satu hari atau tiga hari, peringatan tingkat Tiket dipicu. Artinya, jika tingkat kesalahan 3 kali ambang batas atau mencapai ambang batas, peringatan tingkat Tiket dipicu.
Jendela waktu pendek diatur ke 1/12.
Anggaplah tingkat kesalahan tetap dua kali lipat ambang batas selama 3 hari, dan kesalahan diperbaiki pada hari ketiga. Konfigurasi jendela waktu pendek memungkinkan peringatan dibersihkan enam jam kemudian. Jika tidak ada jendela waktu pendek yang dikonfigurasi, peringatan berlangsung selama 3 hari meskipun tidak ada kesalahan.