Mengukur SLO

Last reviewed 2024-03-29 UTC

Dokumen dalam Framework Arsitektur Google Cloud ini dibuat berdasarkan diskusi sebelumnya tentang tujuan tingkat layanan (SLO) dengan mempelajari apa dan bagaimana pengukuran terkait beban kerja layanan umum. Dokumen ini dibuat berdasarkan konsep yang ditentukan dalam Komponen tujuan tingkat layanan.

Memutuskan apa yang harus diukur

Terlepas dari domain Anda, banyak layanan yang berbagi fitur umum dan dapat menggunakan SLO umum. Bagian ini membahas SLO umum untuk berbagai jenis layanan dan memberikan penjelasan mendetail tentang SLI yang berlaku untuk setiap SLO.

Masing-masing subbagian berikut mengidentifikasi jenis layanan tertentu dan memberikan deskripsi singkat tentang layanan tersebut. Kemudian, yang tercantum di bawah setiap jenis layanan adalah kemungkinan SLI, definisi indikator, dan informasi lain yang terkait dengan SLI.

Layanan berdasarkan permintaan

Jenis layanan ini menerima permintaan dari klien (pengguna atau layanan lain), melakukan beberapa komputasi, mungkin mengirim permintaan jaringan ke backend, lalu menampilkan respons ke klien.

Ketersediaan sebagai SLI

Ketersediaan adalah proporsi permintaan valid yang berhasil ditayangkan. Daftar berikut mencakup informasi yang perlu dipertimbangkan saat menggunakan ketersediaan sebagai SLI:

  • Sebagai pemilik layanan, Anda yang memutuskan permintaan apa yang valid. Definisi umum mencakup tidak panjang nol atau mematuhi protokol klien-server. Salah satu metode untuk mengukur validitas adalah meninjau kode respons HTTP (atau RPC). Misalnya, kode HTTP 5xx adalah error terkait server yang dihitung terhadap SLO, sedangkan kode 4xx adalah error klien yang tidak dihitung.
  • Setiap kode respons yang ditampilkan oleh layanan Anda harus diperiksa untuk memastikan bahwa aplikasi menggunakan kode tersebut dengan benar dan konsisten. Apakah kode merupakan indikator akurat dari pengalaman pengguna terhadap layanan? Misalnya, bagaimana situs e-commerce merespons saat pengguna mencoba memesan item yang stoknya habis? Apakah permintaan gagal dan menampilkan pesan error? Apakah situs menyarankan produk serupa? Kode error harus terkait dengan ekspektasi pengguna.
  • Developer dapat menyalahgunakan error secara tidak sengaja. Dengan menggunakan skenario stok habis dari poin sebelumnya, developer mungkin salah menampilkan error. Namun, sistem bekerja dengan baik dan tidak mengalami error. Kode harus menampilkan keberhasilan, meskipun pengguna tidak dapat membeli item. Meskipun pemilik layanan harus diberi tahu tentang inventaris yang rendah, ketidakmampuan untuk melakukan penjualan bukanlah error dari sudut pandang pelanggan dan tidak diperhitungkan terhadap SLO.
  • Contoh layanan yang lebih kompleks adalah layanan yang menangani permintaan asinkron atau menyediakan proses yang berjalan lama untuk pelanggan. Meskipun Anda dapat mengekspos ketersediaan dengan cara lain, sebaiknya tampilkan ketersediaan sebagai proporsi permintaan valid yang berhasil. Ketersediaan juga dapat didefinisikan sebagai jumlah menit saat beban kerja pelanggan berjalan (terkadang disebut sebagai pendekatan menit yang baik).
  • Pertimbangkan layanan yang menawarkan mesin virtual (VM). Anda dapat mengukur ketersediaan dalam hal jumlah menit setelah permintaan awal saat VM tersedia bagi pengguna.

Latensi sebagai SLI

Latensi (atau kecepatan) adalah proporsi permintaan valid yang ditayangkan lebih cepat dari nilai minimum. Dengan demikian, latensi menunjukkan kecepatan layanan, dan dapat diukur dengan menghitung perbedaan antara waktu mulai dan waktu berhenti untuk jenis permintaan tertentu. Ingat, hal ini adalah persepsi pengguna terhadap latensi, dan pemilik layanan biasanya mengukur nilai ini terlalu tepat. Pada kenyataannya, pengguna tidak dapat membedakan antara refresh 100 milidetik (md) dan refresh 300 md, dan bahkan mungkin menerima respons antara 300 milidetik dan 1.000 md seperti biasa. Untuk mengetahui informasi selengkapnya, lihat Model kereta.

Kembangkan metrik yang berfokus pada aktivitas yang berfokus pada pengguna. Berikut adalah beberapa contoh metrik tersebut:

  • Interaktif: Pengguna menunggu 1.000 md untuk mendapatkan hasil setelah mengklik elemen.
  • Penulisan: Perubahan pada sistem terdistribusi yang mendasarinya memerlukan waktu 1.500 milidetik. Meskipun durasi waktu ini dianggap lambat, pengguna cenderung menerimanya. Sebaiknya Anda membedakan secara eksplisit antara operasi tulis dan baca di metrik Anda.
  • Latar belakang: Tindakan yang tidak terlihat oleh pengguna,seperti pembaruan data secara berkala atau permintaan asinkron lainnya, memerlukan waktu tidak lebih dari 5.000 milidetik untuk diselesaikan.

Latensi biasanya diukur sebagai distribusi dan seperti yang disebutkan dalam Memilih SLI Anda. Dengan mempertimbangkan distribusi, Anda dapat mengukur berbagai persentil. Misalnya, Anda mungkin mengukur jumlah permintaan yang lebih lambat daripada persentil ke-99 historis. Peristiwa yang lebih cepat dari batas ini dianggap baik; permintaan yang lebih lambat dianggap tidak begitu baik. Anda menetapkan nilai minimum ini berdasarkan persyaratan produk. Anda bahkan dapat menetapkan beberapa SLO latensi, misalnya latensi biasa versus latensi tail.

Jangan hanya menggunakan latensi rata-rata (atau median) sebagai SLI Anda. Jika latensi median terlalu lambat, separuh pengguna Anda sudah tidak puas. Selain itu, layanan dapat mengalami latensi buruk selama berhari-hari sebelum Anda menemukan masalahnya. Oleh karena itu, tentukan SLO untuk latensi tail (persentil ke-95) dan untuk latensi median (persentil ke-50).

Dalam artikel ACM Metrics That Matter, Benjamin Treynor Sloss menulis hal berikut:

  • "Aturan praktis yang bagus ... adalah bahwa latensi persentil ke-99 tidak boleh lebih dari tiga hingga lima kali latensi median."
  • "Kami mendapati bahwa ukuran latensi persentil ke-50, ke-95, dan ke-99 untuk suatu layanan masing-masing bernilai satu per satu, dan idealnya kami akan menetapkan SLO untuk masing-masing layanan tersebut."

Tentukan batas latensi Anda berdasarkan persentil historis, lalu ukur jumlah permintaan yang mencakup setiap bucket. Pendekatan ini adalah model yang baik untuk diikuti.

Kualitas sebagai bagian SLI

Kualitas adalah proporsi permintaan valid yang ditayangkan tanpa penurunan layanan. Sebagai contoh, kualitas adalah SLI yang berguna untuk layanan kompleks yang dirancang untuk gagal secara halus. Sebagai ilustrasi, bayangkan sebuah halaman web yang memuat konten utamanya dari satu datastore dan memuat aset opsional dari 100 layanan dan datastore lainnya. Jika salah satu elemen opsional tidak berfungsi atau terlalu lambat, halaman akan tetap dirender tanpa elemen opsional. Dalam skenario ini, Anda dapat menggunakan SLI untuk melakukan hal berikut:

  • Dengan mengukur jumlah permintaan yang menerima respons yang terdegradasi (respons tidak memiliki balasan dari setidaknya satu layanan backend), Anda dapat melaporkan rasio permintaan yang buruk.
  • Anda dapat melacak jumlah respons yang tidak memiliki balasan dari satu backend, atau dari beberapa backend.

Layanan pemrosesan data

Layanan ini menggunakan data dari input, memproses data tersebut, dan menghasilkan output. Performa layanan pada langkah menengah tidak sepenting hasil akhir. SLI terkuat adalah keaktualan, cakupan, ketepatan, dan throughput. Latensi dan ketersediaan kurang bermanfaat.

Keaktualan sebagai bagian SLI

Keaktualan adalah proporsi data valid yang diperbarui lebih baru dari nilai minimum. Daftar berikut memberikan beberapa contoh penggunaan keaktualan sebagai SLI:

  • Dalam sistem batch, keaktualan diukur sebagai waktu yang berlalu selama proses pemrosesan yang berhasil diselesaikan untuk output tertentu.
  • Dalam pemrosesan real-time atau sistem yang lebih kompleks, keaktualan melacak usia dari kumpulan data terbaru yang diproses dalam pipeline.
  • Dalam game online yang membuat ubin peta secara real time, pengguna mungkin tidak memperhatikan seberapa cepat ubin peta dibuat, tetapi mereka mungkin menyadari jika data peta hilang atau tidak baru. Dalam hal ini, keaktualan melacak data yang hilang atau sudah tidak berlaku.
  • Dalam layanan yang membaca kumpulan data dari sistem pelacakan untuk menghasilkan pesan "X items in stock" (item X dalam stok) untuk sebuah situs e-commerce, SLI keaktualan dapat didefinisikan sebagai persentase permintaan yang menggunakan informasi stok yang baru saja dimuat ulang (dalam satu menit terakhir).
  • Anda juga dapat menggunakan metrik untuk menyajikan data yang tidak baru untuk memperbarui SLI untuk kualitas.

Cakupan sebagai SLI

Cakupan adalah proporsi data valid yang berhasil diproses.

Untuk menentukan cakupan, ikuti langkah-langkah berikut:

  1. Menentukan apakah akan menerima input sebagai valid atau melewatinya. Misalnya, jika kumpulan data input rusak atau panjang nol dan tidak dapat diproses, Anda dapat menganggap catatan tersebut tidak valid sebagai metrik.
  2. Menghitung jumlah catatan yang valid. Jumlah ini dapat dicapai dengan metode *count() *sederhana dan merepresentasikan jumlah total kumpulan data Anda.
  3. Terakhir, hitung jumlah catatan yang berhasil diproses dan bandingkan angka tersebut dengan total jumlah catatan yang valid. Nilai ini adalah SLI untuk cakupan.

Ketepatan sebagai bagian SLI

Benar adalah proporsi data valid yang menghasilkan output benar. Pertimbangkan poin-poin berikut saat menggunakan ketepatan sebagai SLI:

  • Dalam beberapa kasus, metode untuk menentukan ketepatan output digunakan untuk memvalidasi pemrosesan output. Misalnya, sistem yang memutar atau mewarnai gambar tidak boleh menghasilkan gambar nol byte, atau gambar dengan panjang atau lebar nol. Penting untuk memisahkan logika validasi ini dari logika pemrosesan itu sendiri.
  • Salah satu metode untuk mengukur SLI ketepatan adalah menggunakan data input pengujian yang diketahui-baik. Jenis data ini adalah data yang menghasilkan {i>output<i} benar yang diketahui. Ingat, data input harus mewakili data pengguna.
  • Dalam kasus lain, Anda dapat menggunakan pemeriksaan matematis atau logis terhadap output, seperti dalam contoh sebelumnya memutar gambar.
  • Terakhir, pertimbangkan sistem penagihan yang menentukan validitas transaksi dengan memeriksa perbedaan antara saldo sebelum dan setelah transaksi. Jika cocok dengan nilai transaksi itu sendiri, berarti transaksi tersebut valid.

Throughput sebagai bagian SLI

Throughput adalah proporsi waktu saat kecepatan pemrosesan data lebih cepat daripada nilai minimum. Berikut beberapa poin yang perlu dipertimbangkan saat menggunakan throughput sebagai SLI:

  • Throughput dalam sistem pemrosesan data sering kali lebih mewakili kepuasan pengguna daripada pengukuran latensi tunggal untuk operasi tertentu. Jika ukuran setiap input sangat bervariasi, mungkin tidak masuk akal untuk membandingkan waktu yang dibutuhkan setiap elemen untuk menyelesaikan (jika semua tugas berjalan dengan tarif yang dapat diterima).
  • Byte per detik adalah cara umum untuk mengukur jumlah pekerjaan yang diperlukan untuk memproses data, terlepas dari ukuran set data. Namun, metrik apa pun yang dapat diskalakan secara linear sehubungan dengan biaya pemrosesan akan dapat digunakan.
  • Mungkin ada baiknya Anda melakukan partisi sistem pemrosesan data berdasarkan rasio throughput yang diharapkan. Atau, terapkan sistem kualitas layanan yang memastikan input berprioritas tinggi ditangani, dan input berprioritas rendah diantrekan. Apa pun itu, mengukur throughput seperti yang dijelaskan di bagian ini membantu menentukan apakah sistem Anda berfungsi sebagaimana mestinya dalam SLO.

Layanan eksekusi terjadwal

Untuk layanan yang perlu menjalankan tindakan pada interval yang teratur (seperti cron job Kubernetes), ukur kemiringan dan durasi eksekusi. Berikut adalah contoh cron job Kubernetes terjadwal:

  apiVersion: batch/v1beta1
  kind: CronJob
  metadata:
  name: hello
  spec:

  schedule: "0 * * * *"

Skew sebagai bagian SLI

Skew adalah proporsi eksekusi yang dimulai dalam periode yang dapat diterima dari waktu mulai yang diharapkan. Saat menggunakan kemiringan, pertimbangkan hal berikut:

  • Skew mengukur perbedaan waktu antara saat tugas dijadwalkan untuk dimulai dan waktu mulainya yang sebenarnya. Pertimbangkan contoh cron job Kubernetes sebelumnya. Jika disetel untuk dimulai dari menit nol setiap jam, tetapi dimulai pada tiga menit lewat satu jam, kemiringannya adalah tiga menit. Ketika suatu pekerjaan berjalan di awal, Anda memiliki bias negatif.
  • Anda dapat mengukur kemiringan sebagai distribusi dari waktu ke waktu, dengan rentang terkait yang dapat diterima dan menentukan kemiringan yang baik. Untuk menentukan SLI, bandingkan jumlah operasi yang berada dalam rentang yang baik.

Durasi eksekusi sebagai SLI

Durasi eksekusi adalah proporsi eksekusi yang selesai dalam periode durasi yang dapat diterima. Berikut ini adalah konsep penting terkait penggunaan durasi eksekusi:

  • Durasi eksekusi adalah waktu yang dibutuhkan untuk menyelesaikan tugas. Untuk eksekusi tertentu, mode kegagalan umum adalah saat durasi yang sebenarnya melebihi durasi yang dijadwalkan.
  • Kasus yang menarik sedang menerapkan SLI ini ke tugas yang tidak pernah berakhir. Karena tugas ini tidak selesai, catat waktu yang dihabiskan untuk tugas tertentu, bukan menunggu tugas selesai. Pendekatan ini memberikan distribusi yang akurat tentang waktu yang diperlukan untuk menyelesaikan pekerjaan, bahkan dalam skenario kasus terburuk.
  • Seperti halnya kemiringan, Anda dapat melacak durasi eksekusi sebagai distribusi dan menentukan batas atas dan bawah yang dapat diterima untuk peristiwa yang baik.

Metrik untuk jenis sistem lainnya

Banyak workload lain memiliki metriknya sendiri untuk menghasilkan SLI dan SLO. Perhatikan contoh berikut:

  • Sistem penyimpanan: Ketahanan, throughput, waktu ke byte pertama, ketersediaan blob.
  • Media/video: Kontinuitas pemutaran klien, waktu untuk memulai pemutaran, kelengkapan eksekusi grafik transcode.
  • Game: Saatnya mencocokkan pemain aktif, saatnya membuat peta.

Menentukan cara mengukur

Bagian sebelumnya membahas apa yang Anda ukur. Setelah menentukan apa yang akan diukur, Anda dapat memutuskan cara mengukurnya. Anda dapat mengumpulkan metrik SLI dengan beberapa cara. Bagian berikut mengidentifikasi berbagai metode pengukuran, memberikan deskripsi singkat tentang metode, mencantumkan kelebihan dan kekurangan metode, serta mengidentifikasi alat implementasi yang sesuai untuk metode tersebut.

Logging sisi server

Metode logging sisi server melibatkan pemrosesan log permintaan atau data yang diproses di sisi server.

Logging sisi server Detail
Kelebihan
  • Memproses ulang log yang ada untuk mengisi ulang data SLI historis.
  • Gunakan ID sesi lintas layanan untuk merekonstruksi perjalanan pengguna yang kompleks di berbagai layanan.
Kekurangan
  • Permintaan yang tidak sampai ke server tidak akan dicatat.
  • Permintaan yang menyebabkan server error mungkin tidak dicatat.
  • Lama waktu untuk memproses log dapat menyebabkan SLI yang tidak berlaku, yang mungkin tidak memadai untuk respons operasional.
  • Menulis kode untuk memproses log bisa menjadi tugas yang rentan terhadap kesalahan dan memakan waktu.
Metode & alat penerapan

Metrik server aplikasi

Metode metrik server aplikasi melibatkan ekspor metrik SLI dari kode yang melayani permintaan pengguna atau memproses data mereka.

Metrik server aplikasi Detail
Kelebihan
  • Menambahkan metrik baru ke kode biasanya cepat dan murah.
Kekurangan
  • Permintaan yang tidak menjangkau server aplikasi tidak akan dicatat.
  • Permintaan multi-layanan mungkin sulit dilacak.
Metode & alat penerapan

Metrik infrastruktur frontend

Metode metrik infrastruktur fronted menggunakan metrik dari infrastruktur load balancing (seperti, load balancer Lapisan 7 global di Google Cloud).

Metrik infrastruktur frontend Detail
Kelebihan
  • Metrik dan data historis sering kali sudah ada, sehingga mengurangi upaya teknis untuk memulai.
  • Pengukuran diambil di titik terdekat dengan pelanggan, tetapi masih dalam infrastruktur penayangan.
Kekurangan
  • Tidak dapat digunakan untuk SLI pemrosesan data.
  • Hanya dapat memperkirakan perjalanan pengguna multi-permintaan.
Metode & alat penerapan

Klien atau data sintetis

Metode data atau klien sintetis melibatkan penggunaan klien yang mengirim permintaan yang dibuat secara berkala dan memvalidasi respons tersebut.

Klien atau data sintetis Detail
Kelebihan
  • Mengukur semua langkah perjalanan pengguna multi-permintaan.
  • Mengirim permintaan dari luar infrastruktur Anda menangkap lebih banyak keseluruhan jalur permintaan di SLI.
Kekurangan
  • Perkiraan pengalaman pengguna dengan permintaan sintetis mungkin menyesatkan (baik positif palsu maupun negatif palsu).
  • Mencakup semua corner case sulit dan dapat berubah menjadi pengujian integrasi.
  • Target keandalan tinggi memerlukan pemeriksaan yang sering untuk pengukuran yang akurat.
  • Menyelidiki lalu lintas dapat menutupi lalu lintas yang sebenarnya.
Metode & alat penerapan

Instrumentasi klien

Metode instrumentasi klien melibatkan penambahan fitur kemampuan observasi ke klien yang berinteraksi dengan pengguna, dan logging kembali peristiwa ke infrastruktur penayangan Anda yang melacak SLI.

Instrumentasi klien Detail
Kelebihan
  • Memberikan ukuran pengalaman pengguna yang paling akurat.
  • Dapat mengukur keandalan pihak ketiga, misalnya, CDN atau penyedia pembayaran.
Kekurangan
  • Penyerapan log klien dan latensi pemrosesan membuat SLI ini tidak cocok untuk memicu respons operasional.
  • Pengukuran SLI berisi sejumlah faktor yang sangat bervariasi yang berpotensi berada di luar kontrol langsung.
  • Membangun instrumentasi ke dalam klien dapat melibatkan banyak pekerjaan teknis.
Metode & alat penerapan

Pilih metode pengukuran

Setelah memutuskan apa dan cara mengukur SLO, langkah selanjutnya adalah memilih metode pengukuran yang paling sesuai dengan pengalaman pelanggan terkait layanan, dan hal ini membutuhkan upaya paling minimal. Untuk mencapai hal yang ideal, Anda mungkin perlu menggunakan kombinasi metode di tabel sebelumnya. Berikut adalah saran pendekatan yang dapat Anda terapkan dari waktu ke waktu, dicantumkan sesuai urutan peningkatan upaya:

  • Gunakan ekspor server aplikasi dan metrik infrastruktur. Biasanya, Anda dapat langsung mengakses metrik ini, dan metrik ini memberikan nilai dengan cepat. Beberapa alat APM menyertakan alat SLO bawaan.
  • Menggunakan instrumentasi klien. Karena sistem lama biasanya tidak memiliki instrumentasi klien pengguna akhir bawaan, penyiapan instrumentasi mungkin memerlukan investasi yang signifikan. Namun, jika menggunakan framework APM atau frontend yang menyediakan instrumentasi klien, Anda dapat dengan cepat mendapatkan insight tentang kebahagiaan pelanggan.
  • Gunakan pemrosesan log. Jika Anda tidak dapat menerapkan ekspor server atau instrumentasi klien (poin sebelumnya), tetapi log memang ada, pemrosesan log mungkin merupakan pendekatan terbaik Anda. Metode lainnya adalah menggabungkan ekspor dan pemrosesan log. Gunakan ekspor sebagai sumber langsung untuk beberapa SLI (seperti ketersediaan langsung) dan pemrosesan log untuk sinyal jangka panjang (seperti pemberitahuan lambat yang dibahas dalam panduan SLO dan Notifikasi).
  • Terapkan pengujian sintetis. Setelah memiliki pemahaman dasar tentang cara pelanggan menggunakan layanan Anda, uji layanan Anda. Misalnya, Anda dapat melakukan kueri awal akun pengujian dengan data yang diketahui-baik dan membuat kueri untuk akun tersebut. Pendekatan ini dapat membantu menyoroti mode kegagalan yang belum terpantau, seperti untuk layanan dengan traffic rendah.

Apa langkah selanjutnya?