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 mengurangi risiko dalam layanan Anda.
Halaman ini memperkenalkan konsep-konsep tersebut dan menjelaskan beberapa hal yang perlu dipertimbangkan saat mendesain SLO. Halaman lain di bagian ini menerapkan 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 memiliki 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 otomatis diidentifikasi berdasarkan sekumpulan jenis layanan yang diketahui: Anthos Service Mesh, Istio di Google Kubernetes Engine, dan App Engine. Anda juga dapat menentukan jenis layanan Anda sendiri dan memilih metrik performanya.
Metrik performa merupakan dasar SLI untuk layanan Anda. SLI menjelaskan performa beberapa aspek layanan Anda. Untuk layanan di Anthos 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 availability adalah rasio jumlah respons yang berhasil terhadap jumlah semua respons.
- SLI latensi adalah rasio jumlah panggilan di bawah nilai minimum latensi terhadap jumlah semua panggilan.
Anda juga dapat menyiapkan SLI khusus layanan untuk mengukur arti “performa yang baik”. SLI ini secara umum terbagi dalam dua kategori:
- SLI berbasis permintaan, dengan layanan yang baik diukur dengan menghitung unit atom layanan, seperti jumlah permintaan HTTP yang berhasil.
- SLI berbasis Windows, dengan layanan yang baik diukur dengan menghitung jumlah jangka waktu, atau periode, saat performa memenuhi kriteria kebaikan, seperti latensi respons di bawah batas tertentu.
SLI ini dijelaskan secara lebih mendetail di Kepatuhan pada 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 periode waktu tertentu. Layanan menentukan SLI yang tersedia, dan Anda menentukan SLO berdasarkan SLI. SLO mendefinisikan hal 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 antara SLI dengan sasaran performa.
Misalnya, Anda mungkin memiliki persyaratan seperti berikut:
- Latensi dapat melebihi 300 milidetik hanya untuk 5 persen permintaan selama periode 30 hari yang berkelanjutan.
- Ketersediaan sistem harus mencapai 99% yang diukur selama satu minggu kalender.
Persyaratan seperti ini dapat memberikan dasar untuk SLO. Lihat Mendesain dan menggunakan SLO untuk panduan cara menetapkan SLO yang baik.
Perubahan pada kepatuhan SLO juga dapat menunjukkan awal kegagalan. Memantau perubahan ini dapat memberikan peringatan yang cukup, sehingga Anda dapat memperbaiki masalah sebelum menurun. Jadi, kebijakan pemberitahuan biasanya digunakan untuk memantau kepatuhan SLO. Untuk informasi selengkapnya, lihat Memberikan 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 ditetapkan adalah 99,9%, tetapi Anda dapat menggunakan nilai lebih rendah yang sesuai untuk layanan Anda.
Anggaran error
SLO menentukan sejauh mana performa layanan selama periode kepatuhan. Yang tersisa selama periode kepatuhan akan menjadi anggaran error. Anggaran error mengukur sejauh mana layanan dapat gagal untuk berperforma selama periode kepatuhan dan masih memenuhi SLO.
Anggaran error memungkinkan Anda melacak jumlah peristiwa buruk individual (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, melakukan 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 untuk 85% permintaan memiliki performa baik dalam periode yang berkelanjutan selama 7 hari, anggaran error Anda memungkinkan 15% permintaan ini berstatus 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 bersifat buruk. Jika Anda menerima lebih banyak error dari ini, berarti layanan Anda tidak berada di SLO selama periode kepatuhan 7 hari.
Mendesain dan menggunakan SLO
Apa yang membuat SLO yang baik? Apa saja 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 di Site Reliability Engineering: Bagaimana Google Menjalankan Sistem Produksi, dalam bab tentang SLO.
SLO menentukan performa target yang Anda inginkan dari layanan Anda. Secara umum, SLO tidak boleh lebih tinggi dari yang diperlukan atau bermakna. Jika pengguna tidak dapat membedakan antara ketersediaan 99% dan ketersediaan 99,9% dari layanan Anda, gunakan nilai yang lebih rendah sebagai SLO. Nilai yang lebih tinggi akan lebih mahal untuk dipenuhi, dan tidak akan berpengaruh bagi pengguna Anda. Layanan yang diperlukan untuk memenuhi sasaran SLO 100% tidak memiliki anggaran error. Menetapkan SLO semacam itu adalah praktik yang buruk.
SLO biasanya lebih ketat daripada komitmen publik atau kontraktual. Anda ingin SLO lebih ketat daripada komitmen publik. Dengan demikian, jika terjadi sesuatu yang menyebabkan pelanggaran SLO, Anda mengetahui dan mengatasi masalah tersebut sebelum menyebabkan pelanggaran komitmen atau kontrak. Melanggar komitmen atau kontrak dapat menimbulkan implikasi reputasi, finansial, atau hukum. SLO adalah bagian dari sistem peringatan awal untuk mencegah hal tersebut terjadi.
Periode kepatuhan
Ada dua jenis periode kepatuhan untuk SLO:
- Periode berbasis kalender (dari tanggal hingga saat ini)
- Periode berkelanjutan (dari n hari yang lalu hingga sekarang, dengan n berkisar dari 1 hingga 30 hari)
Periode kepatuhan berbasis kalender
Periode kepatuhan dapat disetel ke periode kalender seperti satu minggu atau satu bulan.
Periode kepatuhan dan anggaran error direset pada batas kalender yang diketahui.
Untuk mengetahui kemungkinan nilai, lihat CalendarPeriod.
Dengan periode kalender, Anda akan mendapatkan skor performa di akhir periode. Diukur terhadap nilai minimum performa, skor performa memungkinkan Anda mengetahui apakah layanan Anda mematuhi kebijakan atau tidak. Saat menggunakan periode kalender, Anda hanya mendapatkan rating kepatuhan satu kali setiap periode kepatuhan, meskipun Anda melihat performa selama periode tersebut. Namun, skor akhir periode memberi Anda nilai yang mudah dibaca dan mudah dicocokkan dengan periode penagihan pelanggan (jika Anda memiliki pelanggan yang membayar eksternal).
Seperti bulan di kalender, periode kepatuhan bulanan bervariasi dalam jumlah hari yang dicakup.
Periode kepatuhan berbasis periode berjalan
Anda juga dapat mengukur kepatuhan selama periode yang berkelanjutan, sehingga Anda selalu mengevaluasi, misalnya, 30 hari terakhir. Dengan periode bergulir, data terlama dalam penghitungan sebelumnya akan keluar dari penghitungan saat ini dan data baru akan menggantikannya.
Dengan periode yang berkelanjutan, Anda akan mendapatkan lebih banyak pengukuran kepatuhan. Artinya, Anda mendapatkan ukuran 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 pada SLO berbasis permintaan dan jendela
Ada dua faktor dalam menentukan kepatuhan SLO:
- Cara periode kepatuhan ditentukan. Penentuan ini dibahas dalam Periode kepatuhan.
- Jenis SLO. Ada dua jenis SLO:
- SLO berbasis permintaan
- SLO berbasis Windows
Kepatuhan adalah rasio peristiwa baik terhadap total peristiwa, yang diukur selama periode kepatuhan. Jenis SLO menentukan apa yang merupakan “peristiwa”.
Jika SLO Anda 99,9%, maka Anda memenuhinya jika kepatuhan Anda setidaknya 99,9%. Nilai maks adalah 100%.
SLO berbasis permintaan
SLO berbasis permintaan didasarkan pada SLI yang didefinisikan sebagai rasio jumlah permintaan baik terhadap jumlah total permintaan. SLO berbasis permintaan terpenuhi saat rasio tersebut memenuhi atau melebihi sasaran untuk periode kepatuhan.
Misalnya, perhatikan 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 sesuai jika fraksi ini setidaknya 0,95.
SLO berbasis permintaan memberi Anda gambaran tentang persentase pekerjaan yang telah 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 didefinisikan sebagai rasio jumlah interval pengukuran yang memenuhi beberapa kriteria kebaikan terhadap jumlah total interval. SLO berbasis jendela terpenuhi saat rasio tersebut memenuhi atau melampaui sasaran untuk periode kepatuhan.
Misalnya, pertimbangkan SLO ini: “Metrik latensi persentil ke-95 kurang dari 100 md selama setidaknya 99% dari jendela 10 menit”. Periode pengukuran yang baik adalah rentang 10 menit saat 95% permintaan memiliki latensi di bawah 100 md. Ukuran kepatuhan adalah bagian dari periode yang baik tersebut. Layanan mematuhi kebijakan jika pecahan ini setidaknya 0,99.
Untuk contoh lainnya, 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% jumlah menit dalam 30 hari).
SLO berbasis jendela memberi Anda gambaran tentang persentase waktu pelanggan mendapati bahwa layanan berfungsi dengan baik atau buruk. Jenis SLO ini dapat menyembunyikan efek perilaku “bursty”: Interval pengukuran yang gagal pada setiap panggilannya dihitung terhadap SLO sebanyak interval pengukuran yang memiliki terlalu banyak error. Selain itu, interval dengan jumlah panggilan yang rendah akan dihitung terhadap SLO sebanyak interval pengukuran dengan aktivitas berat.
Jalur anggaran error
Anggaran error adalah selisih antara layanan yang 100% baik dan SLO, yaitu tingkat layanan yang baik yang diinginkan. Perbedaan di antara mereka adalah ruang gerak Anda.
Secara umum, anggaran error dimulai sebagai nilai maksimum dan menurun seiring waktu, sehingga 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, sisa anggaran error sebenarnya dapat meningkat.
Bagaimana mungkin? Sistem SLO tidak dapat mengetahui lebih awal seberapa banyak aktivitas yang akan dimiliki layanan di setiap periode kepatuhan, sehingga sistem ini mengekstrapolasi kemungkinan nilai. Nilai ini adalah rasio panggilan hingga waktu saat ini selama waktu yang telah berlalu sejak awal periode kepatuhan, dikalikan dengan lama periode kepatuhan.
Saat rasio aktivitas naik, traffic yang diharapkan untuk periode tersebut juga naik, dan akibatnya, anggaran error meningkat.
Jika Anda mengukur SLO selama periode kepatuhan berkelanjutan, secara efektif Anda 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 diluncurkan dari periode kepatuhan, dan jika periode kepatuhan ini diganti, anggaran error akan meningkat. Kapan pun, anggaran error ≥ 0 menunjukkan jendela SLO yang berjalan yang sesuai, dan anggaran error < 0 menunjukkan jendela SLO bergulir yang tidak mematuhi kebijakan.
Memantau anggaran error Anda
Anda dapat membuat kebijakan pemberitahuan yang memperingatkan bahwa anggaran error habis lebih cepat dari yang diinginkan. Lihat Membuat pemberitahuan tentang anggaran error untuk mengetahui informasi selengkapnya.
Langkah selanjutnya
- Microservice menjelaskan microservice dan cara menggunakan konsol Google Cloud untuk mengonfigurasi, melihat, dan mengelola microservice Anda.
- Pemberitahuan tentang laju pengeluaran menjelaskan cara memantau SLI sehingga Anda dapat lebih waspada terhadap kemungkinan masalah.
- Menggunakan SLO API menunjukkan cara menggunakan SLO API, yang merupakan subset Cloud Monitoring API, untuk membuat layanan, SLO, dan struktur terkait.