Pemantauan layanan dan SLO API membantu Anda mengelola layanan seperti Google mengelola layanannya sendiri. Konsep inti pemantauan layanan mencakup hal berikut:
- Memilih metrik yang bertindak sebagai indikator tingkat layanan (SLI).
- Menggunakan SLI untuk menetapkan tujuan tingkat layanan (SLO) untuk nilai SLI.
- Menggunakan anggaran error yang tersirat oleh SLO untuk mengurangi risiko dalam layanan Anda.
Halaman ini memperkenalkan konsep-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 saat performa sebenarnya tidak memenuhi SLO.
Indikator tingkat layanan
Cloud Monitoring mengumpulkan metrik yang mengukur performa infrastruktur layanan. Contoh metrik performa mencakup 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 untuknya.
Metrik performa adalah dasar SLI untuk layanan Anda. SLI menjelaskan 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 diturunkan 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 dari arti “performa yang baik”. SLI ini umumnya termasuk dalam dua kategori:
- SLI berbasis permintaan, dengan layanan yang baik diukur dengan menghitung unit layanan atomik, seperti jumlah permintaan HTTP yang berhasil.
- SLI berbasis jendela, dengan layanan yang baik diukur dengan menghitung jumlah periode waktu, atau jendela, selama performa memenuhi kriteria yang baik, seperti latensi respons di bawah ambang batas tertentu.
SLI ini dijelaskan lebih mendetail di Kepatuhan dalam SLO berbasis permintaan dan jendela.
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, disebut periode kepatuhan, untuk mengukur perbandingan data SLI dengan sasaran performa.
Misalnya, Anda mungkin memiliki persyaratan seperti berikut:
- Latensi hanya dapat melebihi 300 md dalam 5 persen permintaan selama periode 30 hari berkelanjutan.
- Sistem harus memiliki ketersediaan 99% yang diukur selama satu minggu kalender.
Persyaratan seperti ini dapat memberikan dasar untuk SLO. Lihat Mendesain dan menggunakan SLO untuk panduan tentang cara menetapkan SLO yang baik.
Perubahan dalam kepatuhan SLO juga dapat menunjukkan awal kegagalan. Memantau perubahan ini dapat memberi Anda peringatan yang cukup sehingga Anda dapat memperbaiki masalah sebelum masalah tersebut meluas. Oleh karena itu, 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. Sisa 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 jumlah peristiwa individual yang 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, 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 yang baik dalam periode 7 hari berkelanjutan, anggaran error Anda mengizinkan 15% permintaan ini menjadi buruk. Jika Anda menerima, misalnya, 60.480 permintaan dalam seminggu terakhir, anggaran error Anda adalah 15% dari total tersebut, atau 9.072 permintaan yang diizinkan menjadi buruk. Jika Anda menayangkan lebih banyak error daripada ini, layanan Anda berada di luar SLO untuk periode kepatuhan 7 hari.
Mendesain dan menggunakan SLO
Apa yang membuat SLO menjadi baik? Apa saja hal yang perlu dipertimbangkan dalam membuat pilihan? Bagian ini memberikan ringkasan beberapa konsep umum di balik desain dan penggunaan SLO. Topik ini dibahas 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 99% dan ketersediaan 99,9% layanan Anda, gunakan nilai yang lebih rendah sebagai SLO. Nilai yang lebih tinggi lebih mahal untuk dipenuhi, dan tidak akan membuat perbedaan bagi pengguna Anda. Layanan yang diwajibkan untuk memenuhi sasaran SLO 100% tidak memiliki anggaran error. Menetapkan SLO seperti itu adalah praktik yang buruk.
SLO biasanya lebih ketat daripada komitmen publik atau kontrak. Anda ingin SLO lebih ketat daripada komitmen publik. Dengan cara ini, jika terjadi sesuatu yang menyebabkan pelanggaran SLO, Anda akan mengetahui dan memperbaiki masalah tersebut sebelum menyebabkan pelanggaran komitmen atau kontrak. Melanggar komitmen atau kontrak dapat memiliki implikasi reputasi, keuangan, atau hukum. SLO adalah bagian dari sistem peringatan dini untuk mencegah hal tersebut terjadi.
Periode kepatuhan
Ada dua jenis periode kepatuhan untuk SLO:
- Periode berbasis kalender (dari tanggal ke tanggal)
- Periode berkelanjutan (dari n hari yang lalu hingga sekarang, dengan n berkisar antara 1 hingga 30 hari)
Periode kepatuhan berbasis kalender
Periode kepatuhan dapat ditetapkan ke periode kalender seperti satu minggu atau satu bulan.
Periode kepatuhan dan anggaran error direset pada batas kalender yang dikenal.
Untuk nilai yang mungkin, lihat CalendarPeriod.
Dengan periode kalender, Anda akan mendapatkan skor performa di akhir periode. Diukur terhadap ambang batas performa, skor performa memberi tahu Anda apakah layanan Anda mematuhi atau tidak. Saat menggunakan periode kalender, Anda hanya mendapatkan rating kepatuhan sekali setiap periode kepatuhan, meskipun Anda melihat performa sepanjang periode. Namun, skor akhir periode memberi Anda nilai yang mudah dibaca dan cocok dengan periode penagihan pelanggan Anda (jika Anda memiliki pelanggan eksternal yang membayar).
Seperti bulan di kalender, periode kepatuhan bulanan bervariasi dalam jumlah hari yang dicakupnya.
Periode kepatuhan berbasis jendela berkelanjutan
Anda juga dapat mengukur kepatuhan selama periode berkelanjutan, sehingga Anda selalu mengevaluasi, misalnya, 30 hari terakhir. Dengan periode berkelanjutan, data terlama dalam penghitungan sebelumnya akan dihapus dari penghitungan saat ini dan data baru akan menggantikannya.
Dengan jendela berkelanjutan, Anda mendapatkan lebih banyak pengukuran kepatuhan; yaitu, Anda mendapatkan ukuran 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 jendela
Menentukan apakah SLO mematuhi atau tidak bergantung pada dua faktor:
- Cara periode kepatuhan ditentukan. Penentuan ini dibahas dalam Periode kepatuhan.
- Jenis SLO. Ada dua jenis SLO:
- SLO berbasis permintaan
- SLO berbasis jendela
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%, berarti Anda 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 dipenuhi 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 bagian permintaan dengan waktu respons di bawah 100 md. Layanan ini mematuhi jika bagian ini minimal 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 jendela
SLO berbasis jendela didasarkan pada SLI yang ditentukan sebagai rasio jumlah interval pengukuran yang memenuhi beberapa kriteria yang baik terhadap jumlah total interval. SLO berbasis jendela dipenuhi jika rasio tersebut memenuhi atau melampaui sasaran untuk periode kepatuhan.
Misalnya, pertimbangkan SLO ini: “Metrik latensi persentil ke-95 kurang dari 100 md untuk setidaknya 99% jendela 10 menit”. Periode pengukuran yang baik adalah rentang 10 menit yang di dalamnya 95% permintaan memiliki latensi di bawah 100 md. Ukuran kepatuhan adalah bagian dari periode yang baik tersebut. Layanan ini mematuhi jika bagian ini minimal 0,99.
Untuk contoh lain, misalkan Anda mengonfigurasi periode kepatuhan menjadi 30 hari berkelanjutan, 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 menemukan layanan berfungsi dengan baik atau buruk. Jenis SLO ini dapat menyembunyikan efek perilaku “bursty”: Interval pengukuran yang gagal setiap kali panggilan dihitung terhadap SLO sebanyak interval pengukuran yang memiliki satu error terlalu banyak. Selain itu, interval dengan jumlah panggilan yang rendah dihitung terhadap SLO sebanyak interval pengukuran dengan aktivitas yang berat.
Trajektori anggaran error
Anggaran error adalah perbedaan antara layanan yang baik 100% dan SLO Anda, tingkat layanan yang baik yang diinginkan. Perbedaan di antara keduanya adalah ruang gerak Anda.
Secara umum, anggaran error dimulai sebagai nilai maksimum dan menurun dari waktu ke waktu, yang 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 memiliki peningkatan aktivitas selama periode kepatuhan, anggaran error yang tersisa sebenarnya dapat meningkat.
Bagaimana hal itu mungkin terjadi? Sistem SLO tidak dapat mengetahui sebelumnya berapa banyak aktivitas yang akan dimiliki layanan dalam setiap periode kepatuhan, sehingga sistem ini mengekstrapolasi nilai yang mungkin. Nilai ini adalah rasio panggilan hingga saat ini terhadap waktu yang berlalu sejak awal periode kepatuhan, dikalikan dengan panjang periode kepatuhan.
Saat tingkat aktivitas meningkat, traffic yang diharapkan untuk periode tersebut juga meningkat, dan akibatnya, anggaran error meningkat.
Jika Anda mengukur SLO selama periode kepatuhan berkelanjutan, Anda secara efektif selalu berada di akhir periode kepatuhan. Daripada memulai dari awal, poin data lama terus dihapus dan poin data baru terus ditambahkan.
Jika periode kepatuhan yang buruk keluar dari jendela kepatuhan, dan jika waktu saat ini, yang menggantikannya, mematuhi, anggaran error akan meningkat. Pada waktu tertentu, anggaran error ≥ 0 menunjukkan jendela SLO berkelanjutan yang mematuhi, dan anggaran error < 0 menunjukkan jendela SLO berkelanjutan yang tidak mematuhi.
Memantau anggaran error
Anda dapat membuat kebijakan pemberitahuan untuk memperingatkan Anda bahwa anggaran error Anda digunakan dengan kecepatan yang 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.
- Pemberitahuan tentang laju pengeluaran Anda menjelaskan cara memantau SLI sehingga Anda akan diberi tahu tentang kemungkinan masalah.
- Bekerja dengan SLO API menunjukkan cara menggunakan SLO API, yang merupakan subkumpulan Cloud Monitoring API, untuk membuat layanan, SLO, dan struktur terkait.