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 oleh 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 menerapkan 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 performa sebenarnya yang 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 kumpulan 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 berasal 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 pengukuran lain tentang makna "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 jangka waktu, atau jendela, selama performa memenuhi kriteria kebaikan, seperti latensi respons di bawah nilai minimum tertentu.
SLI ini dijelaskan secara lebih mendetail dalam Kepatuhan dalam SLO berbasis permintaan dan 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, 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 menunjukkan awal terjadinya kegagalan. Memantau perubahan ini dapat memberi Anda peringatan yang cukup sehingga Anda dapat memperbaiki masalah sebelum terjadi cascading. Jadi, kebijakan pemberitahuan biasanya digunakan untuk memantau kepatuhan SLO. Untuk informasi selengkapnya, lihat Pemberitahuan tentang anggaran error.
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 anggaran error 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 jumlah peristiwa buruk individual (seperti permintaan) yang diizinkan untuk 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, tindakan berisiko seperti mendorong 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 agar 85% permintaan memiliki kualitas baik dalam periode bergulir 7 hari, anggaran error Anda akan mengizinkan 15% permintaan ini memiliki kualitas buruk. Misalnya, jika Anda menerima 60.480 permintaan dalam minggu terakhir, anggaran error Anda adalah 15% dari total tersebut, atau 9.072 permintaan yang diizinkan untuk buruk. Jika Anda menampilkan lebih banyak error dari ini, layanan Anda berada di luar SLO selama 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 tentang beberapa konsep umum di balik proses mendesain dan menggunakan 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 Anda inginkan dari layanan Anda. Secara umum, SLO harus tidak lebih tinggi dari yang diperlukan atau bermakna. Jika pengguna tidak dapat membedakan antara ketersediaan 99% dan ketersediaan 99,9% layanan Anda, gunakan nilai yang lebih rendah sebagai SLO. Nilai yang lebih tinggi akan 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 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 tersebut sebelum menyebabkan pelanggaran komitmen atau kontrak. Melanggar komitmen atau kontrak dapat memiliki implikasi reputasi, finansial, 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 bergulir (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 diketahui.
Untuk mengetahui nilai yang memungkinkan, 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 atau tidak. Saat menggunakan periode kalender, Anda hanya mendapatkan rating kepatuhan sekali setiap periode kepatuhan, meskipun Anda melihat performa selama periode tersebut. Namun, skor akhir periode memberi Anda nilai yang mudah dibaca dan cocok dengan periode penagihan pelanggan (jika Anda memiliki pelanggan eksternal yang membayar).
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 bergulir, sehingga Anda selalu mengevaluasi, misalnya, 30 hari terakhir. Dengan periode bergulir, data paling lama dalam penghitungan sebelumnya akan dihapus dari penghitungan saat ini dan data baru akan menggantikannya.
Dengan periode bergulir, Anda mendapatkan lebih banyak pengukuran kepatuhan; yaitu, Anda mendapatkan pengukuran kepatuhan selama 30 hari terakhir, bukan satu per bulan. Layanan dapat bertransisi antara kepatuhan dan ketidakpatuhan karena status SLO berubah setiap hari, karena titik data lama dihapus dan titik data baru ditambahkan.
Kepatuhan dalam SLO berbasis permintaan dan jendela
Penentuan apakah SLO sudah mematuhi kebijakan 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 saja yang merupakan “peristiwa”.
Jika SLO Anda adalah 99,9%, Anda memenuhinya jika kepatuhan Anda setidaknya 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 melebihi 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 mematuhi 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 kualitas terhadap jumlah total interval. SLO berbasis jendela terpenuhi jika rasio tersebut memenuhi atau melebihi sasaran untuk periode kepatuhan.
Misalnya, pertimbangkan SLO ini: “Metrik latensi persentil ke-95 kurang dari 100 md selama setidaknya 99% periode 10 menit”. Periode pengukuran yang baik adalah rentang 10 menit dengan 95% permintaan memiliki latensi di bawah 100 md. Ukuran kepatuhan adalah fraksi periode yang baik tersebut. Layanan mematuhi persyaratan jika pecahan 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 saat pelanggan menemukan bahwa layanan berfungsi dengan baik atau buruk. Jenis SLO ini dapat menyembunyikan efek perilaku "bursty": Interval pengukuran yang gagal dalam setiap panggilannya akan dihitung dalam SLO sama seperti interval pengukuran yang memiliki terlalu banyak error. Selain itu, interval dengan jumlah panggilan yang rendah akan mengurangi SLO sama seperti interval pengukuran dengan aktivitas yang berat.
Trajektori anggaran error
Anggaran error adalah selisih antara 100% layanan baik dan SLO Anda, yaitu tingkat layanan 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 telah meningkatkan aktivitas selama periode kepatuhan, anggaran error yang tersisa sebenarnya dapat meningkat.
Bagaimana mungkin? 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 selama waktu yang berlalu sejak awal periode kepatuhan, dikalikan dengan durasi periode kepatuhan.
Saat rasio aktivitas meningkat, traffic yang diharapkan untuk periode tersebut juga meningkat, dan akibatnya, anggaran error meningkat.
Jika Anda mengukur SLO selama periode kepatuhan bergulir, Anda secara efektif 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 saat ini, yang menggantikannya, sudah mematuhi kebijakan, anggaran error akan naik. Pada waktu kapan pun, anggaran error ≥ 0 menunjukkan periode SLO rolling yang sesuai, dan anggaran error < 0 menunjukkan periode SLO rolling yang tidak sesuai.
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 untuk mengetahui informasi selengkapnya.
Langkah selanjutnya
- 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 sehingga Anda mendapatkan pemberitahuan tentang kemungkinan masalah.
- Menggunakan SLO API menunjukkan cara menggunakan SLO API, subkumpulan Cloud Monitoring API, untuk membuat layanan, SLO, dan struktur terkait.