Pemantauan layanan dan SLO API membantu Anda mengelola layanan seperti Google mengelola layanannya sendiri. Konsep inti pemantauan layanan mencakup hal-hal berikut:
- Memilih metrik yang berfungsi sebagai indikator tingkat layanan (SLI).
- Menggunakan SLI untuk menetapkan tujuan tingkat layanan (SLO) untuk nilai SLI.
- Menggunakan anggaran error yang tersirat dalam SLO untuk memitigasi risiko dalam layanan Anda.
Halaman ini memperkenalkan konsep ini dan menjelaskan beberapa hal yang perlu dipertimbangkan saat mendesain SLO. Halaman lain di bagian ini mempraktikkan konsep-konsep ini.
Terminologi
Pemantauan layanan memiliki serangkaian konsep inti, yang diperkenalkan di sini:
- Indikator tingkat layanan (SLI): pengukuran performa.
- Tujuan tingkat layanan (SLO): pernyataan performa yang diinginkan.
- Anggaran error: dimulai dari 1 - SLO dan menurun seiring dengan performa aktual yang tidak memenuhi SLO.
Indikator tingkat layanan
Cloud Monitoring mengumpulkan metrik yang mengukur performa infrastruktur layanan. Contoh metrik performa meliputi hal-hal berikut:
- Jumlah permintaan: misalnya, jumlah permintaan HTTP per menit yang menghasilkan respons 2xx atau 5xx.
- Latensi respons: misalnya, latensi untuk respons HTTP 2xx.
Metrik performa diidentifikasi secara otomatis berdasarkan serangkaian jenis layanan yang diketahui: Cloud Service Mesh, Istio di Google Kubernetes Engine, dan App Engine. Anda juga dapat menentukan jenis layanan Anda sendiri dan memilih metrik performa untuk jenis layanan tersebut.
Metrik performa adalah dasar SLI untuk layanan Anda. SLI mendeskripsikan performa beberapa aspek layanan Anda. Untuk layanan di Cloud Service Mesh, Istio di Google Kubernetes Engine, dan App Engine, SLI yang berguna sudah diketahui. Misalnya, jika layanan Anda memiliki metrik jumlah permintaan atau latensi respons, indikator tingkat layanan (SLI) standar dapat diperoleh dari metrik tersebut dengan membuat rasio sebagai berikut:
- SLI ketersediaan adalah rasio jumlah respons yang berhasil terhadap jumlah semua respons.
- SLI latensi adalah rasio jumlah panggilan di bawah ambang batas latensi terhadap jumlah semua panggilan.
Anda juga dapat menyiapkan SLI khusus layanan untuk beberapa ukuran lain tentang arti “performa yang baik”. SLI ini umumnya dikelompokkan dalam dua kategori:
- SLI berbasis permintaan, yang mengukur layanan yang baik dengan menghitung unit layanan atomik, seperti jumlah permintaan HTTP yang berhasil.
- SLI berbasis jendela, di mana layanan yang baik diukur dengan menghitung jumlah periode waktu, atau jendela, selama performa memenuhi kriteria yang baik, seperti latensi respons di bawah nilai minimum tertentu.
SLI ini dijelaskan lebih mendetail dalam Kepatuhan dalam SLO berbasis permintaan dan berbasis periode.
Untuk contoh yang membuat SLI untuk layanan yang dipilih, lihat Membuat SLI dari metrik.
Tujuan tingkat layanan
SLO adalah nilai target untuk SLI, yang diukur selama jangka waktu tertentu. Layanan menentukan SLI yang tersedia, dan Anda menentukan SLO berdasarkan SLI. SLO menentukan apa yang memenuhi syarat sebagai layanan yang baik. Anda dapat membuat hingga 500 SLO untuk setiap layanan di Cloud Monitoring.
SLO dibuat berdasarkan beberapa jenis informasi berikut:
- SLI, yang mengukur performa layanan.
- Sasaran performa, yang menetapkan tingkat performa yang diinginkan.
- Jangka waktu, yang disebut periode kepatuhan, untuk mengukur perbandingan data SLI dengan sasaran performa.
Misalnya, Anda mungkin memiliki persyaratan seperti berikut:
- Latensi dapat melebihi 300 md hanya dalam 5 persen permintaan selama periode 30 hari bergulir.
- Sistem harus memiliki ketersediaan 99% yang diukur selama satu minggu kalender.
Persyaratan seperti ini dapat menjadi dasar untuk SLO. Lihat Mendesain dan menggunakan SLO untuk mendapatkan panduan tentang cara menetapkan SLO yang baik.
Perubahan pada kepatuhan SLO juga dapat mengindikasikan terjadinya kegagalan. Memantau perubahan ini dapat memberi Anda peringatan yang cukup sehingga Anda dapat memperbaiki masalah sebelum masalah tersebut meluas. Jadi, kebijakan pemberitahuan biasanya digunakan untuk memantau kepatuhan SLO. Untuk mengetahui informasi selengkapnya, lihat Pemberitahuan tentang anggaran error Anda.
SLO yang berguna menargetkan kurang dari 100%, karena SLO menentukan anggaran error Anda. SLO biasanya dijelaskan sebagai “jumlah sembilan”: 99% (2 sembilan), 99,9% (3 sembilan), dan seterusnya. Nilai tertinggi yang dapat Anda tetapkan adalah 99,9%, tetapi Anda dapat menggunakan nilai yang lebih rendah yang sesuai untuk layanan Anda.
Anggaran error
SLO menentukan tingkat performa layanan selama periode kepatuhan. Yang tersisa dalam periode kepatuhan menjadi anggaran error. Anggaran error mengukur sejauh mana layanan dapat gagal untuk bekerja selama periode kepatuhan dan masih memenuhi SLO.
Anggaran error memungkinkan Anda melacak berapa banyak peristiwa buruk (seperti permintaan) yang diizinkan terjadi selama sisa periode kepatuhan sebelum Anda melanggar SLO. Anda dapat menggunakan anggaran error untuk membantu mengelola tugas pemeliharaan seperti deployment versi baru. Jika anggaran error hampir habis, maka mengambil tindakan berisiko seperti mengirimkan update baru dapat menyebabkan Anda melanggar SLO.
Anggaran error Anda untuk periode kepatuhan adalah (1 − sasaran SLO) × (peristiwa yang memenuhi syarat dalam periode kepatuhan). Misalnya, jika SLO Anda adalah 85% permintaan harus bagus dalam periode berjalan 7 hari, maka anggaran error Anda mengizinkan 15% permintaan ini menjadi buruk. Misalnya, jika Anda menerima 60.480 permintaan dalam seminggu terakhir, anggaran error Anda adalah 15% dari total tersebut, atau 9.072 permintaan yang diizinkan untuk menjadi buruk. Jika Anda mengalami lebih banyak error daripada ini, layanan Anda tidak mematuhi SLO selama periode kepatuhan 7 hari.
Mendesain dan menggunakan SLO
Apa yang membuat SLO yang baik? Apa saja hal yang perlu dipertimbangkan dalam membuat pilihan? Bagian ini memberikan ringkasan beberapa konsep umum di balik perancangan dan penggunaan SLO. Topik ini dibahas secara lebih mendetail dalam Site Reliability Engineering: How Google Runs Production Systems, di bab tentang SLO.
SLO menentukan performa target yang diinginkan dari layanan Anda. Secara umum, SLO tidak boleh lebih tinggi dari yang diperlukan atau bermakna. Jika pengguna Anda tidak dapat membedakan antara ketersediaan layanan Anda sebesar 99% dan 99,9%, gunakan nilai yang lebih rendah sebagai SLO. Nilai yang lebih tinggi lebih mahal untuk dipenuhi, dan tidak akan memengaruhi pengguna Anda. Layanan yang harus memenuhi sasaran SLO 100% tidak memiliki anggaran error. Menetapkan SLO seperti itu adalah praktik yang buruk.
SLO biasanya lebih ketat daripada komitmen publik atau kontraktual. Anda ingin SLO lebih ketat daripada komitmen publik. Dengan cara ini, jika terjadi sesuatu yang menyebabkan pelanggaran SLO, Anda akan mengetahui dan memperbaiki masalah sebelum menyebabkan pelanggaran komitmen atau kontrak. Melanggar komitmen atau kontrak dapat menimbulkan implikasi reputasi, keuangan, atau hukum. SLO adalah bagian dari sistem peringatan dini untuk mencegah hal itu terjadi.
Periode kepatuhan
Ada dua jenis periode kepatuhan untuk SLO:
- Periode berbasis kalender (dari tanggal ke tanggal)
- Periode berjalan (dari n hari yang lalu hingga sekarang, dengan n berkisar dari 1 hingga 30 hari)
Periode kepatuhan berbasis kalender
Periode kepatuhan dapat ditetapkan ke periode kalender seperti seminggu atau sebulan.
Periode kepatuhan dan anggaran error direset pada batas kalender yang sudah dikenal.
Untuk mengetahui nilai yang mungkin, lihat CalendarPeriod.
Dengan periode kalender, Anda akan mendapatkan skor performa di akhir periode. Diukur berdasarkan nilai minimum performa, skor performa memungkinkan Anda mengetahui apakah layanan Anda mematuhi nilai minimum performa atau tidak. Saat menggunakan periode kalender, Anda hanya mendapatkan rating kepatuhan sekali setiap periode kepatuhan, meskipun Anda melihat performa sepanjang periode tersebut. Namun, skor akhir periode memberi Anda nilai yang mudah dibaca dan cocok dengan periode penagihan pelanggan (jika Anda memiliki pelanggan yang membayar secara eksternal).
Seperti bulan dalam kalender, periode kepatuhan bulanan bervariasi dalam jumlah hari yang dicakupnya.
Periode kepatuhan berbasis periode berkelanjutan
Anda juga dapat mengukur kepatuhan selama periode berkelanjutan, sehingga Anda selalu mengevaluasi, misalnya, 30 hari terakhir. Dengan periode bergulir, data terlama dalam perhitungan sebelumnya akan dikeluarkan dari perhitungan saat ini dan digantikan dengan data baru.
Dengan periode berkelanjutan, Anda mendapatkan lebih banyak pengukuran kepatuhan; yaitu, Anda mendapatkan pengukuran kepatuhan untuk 30 hari terakhir, bukan satu per bulan. Layanan dapat bertransisi antara kepatuhan dan ketidakpatuhan saat status SLO berubah setiap hari, karena poin data lama dihapus dan poin data baru ditambahkan.
Kepatuhan dalam SLO berbasis permintaan dan berbasis rentang waktu
Penentuan apakah SLO mematuhi bergantung pada dua faktor:
- Cara periode kepatuhan ditentukan. Penetapan ini dibahas dalam Periode kepatuhan.
- Jenis SLO. Ada dua jenis SLO:
- SLO berbasis permintaan
- SLO berbasis Windows
Kepatuhan adalah rasio peristiwa yang baik terhadap total peristiwa, yang diukur selama periode kepatuhan. Jenis SLO menentukan apa yang merupakan “peristiwa”.
Jika SLO Anda adalah 99,9%, maka Anda akan memenuhinya jika kepatuhan Anda minimal 99,9%. Nilai maksimumnya adalah 100%.
SLO berbasis permintaan
SLO berbasis permintaan didasarkan pada SLI yang ditentukan sebagai rasio jumlah permintaan yang baik terhadap jumlah total permintaan. SLO berbasis permintaan terpenuhi jika rasio tersebut memenuhi atau melampaui sasaran untuk periode kepatuhan.
Misalnya, pertimbangkan SLO berbasis permintaan ini: “Latensi di bawah 100 md untuk setidaknya 95% permintaan”. Permintaan yang baik adalah permintaan dengan waktu respons kurang dari 100 md, sehingga ukuran kepatuhan adalah fraksi permintaan dengan waktu respons di bawah 100 md. Layanan ini mematuhi SLO jika fraksi ini setidaknya 0,95.
SLO berbasis permintaan memberi Anda gambaran tentang persentase pekerjaan yang dilakukan layanan Anda dengan benar selama seluruh periode kepatuhan, terlepas dari cara beban didistribusikan selama periode kepatuhan.
SLO berbasis Windows
SLO berbasis jendela didasarkan pada SLI yang ditentukan sebagai rasio jumlah interval pengukuran yang memenuhi beberapa kriteria yang baik terhadap total jumlah interval. SLO berbasis jendela terpenuhi jika rasio tersebut memenuhi atau melampaui sasaran untuk periode kepatuhan.
Misalnya, pertimbangkan SLO ini: “Metrik latensi persentil ke-95 adalah kurang dari 100 md untuk setidaknya 99% periode 10 menit”. Periode pengukuran yang baik adalah rentang 10 menit saat 95% permintaan memiliki latensi di bawah 100 md. Ukuran kepatuhan adalah fraksi periode yang baik tersebut. Layanan ini mematuhi kebijakan jika fraksi ini minimal 0,99.
Sebagai contoh lain, misalkan Anda mengonfigurasi periode kepatuhan menjadi 30 hari bergulir, interval pengukuran menjadi satu menit, dan sasaran SLO menjadi 99%. Untuk memenuhi SLO ini, layanan Anda harus memiliki 42.768 interval “baik” dari 43.200 menit (99% dari jumlah menit dalam 30 hari).
SLO berbasis jendela memberi Anda gambaran tentang persentase waktu pelanggan Anda menganggap layanan berfungsi dengan baik atau buruk. Jenis SLO ini dapat menyembunyikan efek perilaku “beruntun”: Interval pengukuran yang gagal dalam setiap panggilannya dihitung terhadap SLO sebanyak interval pengukuran yang memiliki satu error terlalu banyak. Selain itu, interval dengan jumlah panggilan yang rendah dihitung terhadap SLO sama seperti interval pengukuran dengan aktivitas berat.
Lintasan anggaran error
Anggaran error adalah selisih antara 100% layanan yang baik dan SLO Anda, yaitu tingkat layanan yang baik yang diinginkan. Perbedaan di antara keduanya adalah ruang gerak Anda.
Secara umum, anggaran error dimulai sebagai nilai maksimum dan menurun seiring waktu, memicu pelanggaran SLO saat anggaran error turun di bawah 0.
Ada beberapa pengecualian penting untuk pola ini:
Jika Anda memiliki SLO berbasis permintaan yang diukur selama periode kepatuhan kalender, dan layanan telah meningkatkan aktivitas selama periode kepatuhan, anggaran error yang tersisa dapat meningkat.
Bagaimana mungkin? Sistem SLO tidak dapat mengetahui sebelumnya seberapa banyak aktivitas yang akan dimiliki layanan dalam setiap periode kepatuhan, sehingga sistem ini mengekstrapolasi kemungkinan nilai. Nilai ini adalah rasio panggilan hingga waktu saat ini terhadap waktu yang berlalu sejak awal periode kepatuhan, dikalikan dengan durasi periode kepatuhan.
Seiring dengan meningkatnya rasio aktivitas, perkiraan traffic untuk periode tersebut juga meningkat, dan sebagai hasilnya, anggaran error meningkat.
Jika Anda mengukur SLO selama periode kepatuhan bergulir, Anda pada dasarnya selalu berada di akhir periode kepatuhan. Daripada memulai dari awal, titik data lama terus dihapus dan titik data baru terus ditambahkan.
Jika periode kepatuhan yang buruk keluar dari periode kepatuhan, dan jika waktu saat ini, yang menggantikannya, mematuhi, anggaran error akan meningkat. Setiap saat, anggaran error ≥ 0 menunjukkan periode SLO bergulir yang mematuhi persyaratan, dan anggaran error < 0 menunjukkan periode SLO bergulir yang tidak mematuhi persyaratan.
Memantau anggaran error
Anda dapat membuat kebijakan pemberitahuan untuk memperingatkan Anda bahwa anggaran error Anda digunakan lebih cepat dari yang diinginkan. Lihat Pemberitahuan tentang anggaran error Anda untuk mengetahui informasi selengkapnya.
Langkah berikutnya
- Microservices menjelaskan microservice dan cara menggunakan konsol Google Cloud untuk mengonfigurasi, melihat, dan mengelola microservice Anda.
- Memberi pemberitahuan tentang laju pengeluaran menjelaskan cara memantau SLI Anda sehingga Anda akan diberi tahu tentang kemungkinan masalah.
- Bekerja dengan SLO API menunjukkan cara menggunakan SLO API, subkumpulan Cloud Monitoring API, untuk membuat layanan, SLO, dan struktur terkait.