Latensi, Lalu Lintas, Kesalahan, Saturasi

Empat Angka Mencakup Sebagian Besar Operasional

Dari buku Google SRE. Empat sinyal yang Anda ukur pada setiap lapisan layanan. Jika Anda menginstrumenkan keempatnya dengan baik, Anda akan menangkap sebagian besar masalah produksi sebelum pengguna melakukannya.

Latensi: berapa lama waktu yang dibutuhkan oleh sebuah permintaan? Laporkan distribusi, bukan hanya rata-rata. p99 (latensi persentil ke-99) lebih penting daripada rata-rata, karena latensi ekor adalah apa yang dirasakan pengguna sebagai 'lambat'. Layanan dengan rata-rata 50 ms & p99 5.000 ms memiliki masalah nyata yang tidak pernah diperhatikan oleh sebagian besar pengguna, tetapi 1% yang paling terdampak benar-benar merasakannya.

Lalu Lintas: berapa banyak permintaan per detik? Total permintaan, per-endpoint, per-kode-status, per-wilayah. Baseline diketahui; berikan peringatan pada anomali (penurunan mendadak = masalah ingress; lonjakan mendadak = peningkatan lalu lintas atau serangan).

Error: tingkat permintaan yang gagal. Bedakan 4xx (error klien, bukan kesalahan Anda) dari 5xx (error server, kesalahan Anda). Lacak tingkat error sebagai persentase dari lalu lintas, bukan sebagai jumlah absolut, agar peringatan berfungsi di berbagai tingkat beban.

Saturasi: seberapa penuh sistemnya? Utilisasi CPU, memori, kedalaman pool koneksi, panjang antrean. Indikator awal. Saturasi meningkat sebelum latensi atau error memburuk. Tier dengan saturasi 90% hanya satu menit buruk lagi dari keruntuhan antrean.

Khusus pada Tier Proxy

Setiap sinyal menyala di lapisan edge:

- Latensi pada proxy: durasi handshake TLS, waktu koneksi upstream, total permintaan-respons. Diukur secara terpisah karena mereka berada di bagian yang berbeda dari jalur.

- Lalu lintas pada proxy: total permintaan/detik, distribusi per-backend (backend yang panas menandakan bias load-balancer), rincian per-kode-status.

- Error pada proxy: 4xx dari klien (pengguna Anda mengakses endpoint yang salah), 5xx dari backend (layanan Anda gagal), error internal proxy (502 = backend tidak dapat dijangkau, 504 = timeout backend).

- Saturasi pada proxy: jumlah sesi TLS, kedalaman pool koneksi upstream, CPU pada proxy itu sendiri (terminasi TLS sangat berat untuk CPU).

Tips pro: kenaikan mendadak pada 502 dengan latensi backend yang rendah berarti backend memutus koneksi sebelum merespons (connection reset, crash, OOM). Kenaikan pada 504 berarti backend lambat tetapi masih menjawab. Baca kode errornya; kode tersebut memberi tahu Anda di mana letak kegagalannya.

Baca Sinyalnya

Dasbor Anda menunjukkan hal berikut dalam 10 menit terakhir:

- Lalu lintas: relatif datar di 800 req/s (tidak ada lonjakan)

- Latensi: p50 stabil di 40ms, p99 naik dari 200ms menjadi 2.500ms dalam 5 menit & masih terus naik

- Error: Tingkat 4xx stabil di 0,3% (latar belakang normal); tingkat 5xx naik dari 0,1% menjadi 1,2% (sebagian besar 504 Gateway Timeout)

- Saturasi: CPU backend naik dari 45% menjadi 78% dalam 5 menit yang sama; CPU proxy stabil di 30%

Kapan Skalakan, Kapan Kosongkan, Kapan Panggil

Keputusan Kapasitas Membutuhkan Pemicu

Mengamati metrik itu mudah. Mengetahui kapan harus bertindak berdasarkan metrik tersebut adalah disiplinnya.

Skalakan naik ketika: saturasi melewati ambang batas yang berkelanjutan (misalnya, CPU backend >70% selama 5 menit), atau kedalaman antrean melampaui target, atau latensi p99 melampaui SLO. Pemicu harus menyala sebelum sistem rusak, bukan saat rusak.

Kosongkan replika ketika: replika tersebut secara konsisten lambat / penuh dengan error sementara rekan-rekannya sehat (satu replika yang berjalan panas sering kali merupakan masalah tingkat host, bukan masalah aplikasi), atau saat meluncurkan versi baru, atau saat memensiunkan replika secara mulus.

Panggil manusia ketika: SLO terbakar lebih cepat daripada yang dapat ditanggung oleh anggaran error, atau pemicu saturasi menyala tanpa diserap oleh autoscaling, atau pola kaskade muncul (tingkat error + tingkat retry keduanya naik).

Jangan panggil ketika: satu menit buruk yang terselesaikan dengan sendirinya, atau tugas batch latar belakang menyebabkan lonjakan periodik yang diharapkan, atau noise melampaui ambang batas (ambang batasnya yang salah, bukan sistemnya).

SLO & Pembakaran Anggaran Kesalahan

SLO (service level objective) mendefinisikan kinerja yang dapat diterima: 'tingkat keberhasilan >= 99,9% dalam jendela 28 hari'. Pelengkapnya (0,1%) adalah anggaran kesalahan.

Tingkat pembakaran (Burn rate): seberapa cepat Anda mengonsumsi anggaran kesalahan. Jika Anda membakar 10% dari anggaran dalam 1 jam, tingkat pembakarannya 240 kali lebih cepat dari yang berkelanjutan (1 jam adalah 1/672 dari jendela 28 hari; membakar 10% dalam jendela tersebut = 10% × 672 = 6720% yang diproyeksikan untuk jendela penuh, padahal hanya 100% yang diizinkan).

Alert tingkat pembakaran multi-jendela: memicu panggilan (page) ketika baik jendela pendek (5 menit pada tingkat 14,4x) & jendela panjang (1 jam pada tingkat 6x) membakar lebih cepat dari yang berkelanjutan. Mendeteksi baik gangguan cepat & degradasi lambat.

Mengapa ini penting untuk kapasitas: layanan yang berjalan pada SLO 99,9% dengan ruang longgar 1% dapat menyerap gangguan kecil. Layanan pada 99,93% (hanya saja memenuhi SLO) hanya satu hari buruk dari pelanggaran. Keputusan kapasitas harus menargetkan margin SLO yang nyaman, bukan minimum yang memenuhinya.

Keputusan Kapasitas di Bawah Pengamatan

Layanan Anda memiliki SLO 99,9% permintaan yang berhasil selama 28 hari. Kondisi saat ini dari pemantauan selama satu jam terakhir:

- Tingkat keberhasilan: 99,5% (terjaga selama 30 menit)

- CPU Backend: rata-rata 82% di seluruh armada (target 70%)

- Latensi p99: 800 ms (target SLO: <500 ms)

- Trafik: 1.400 req/s, naik dari baseline 1.000 req/s (40% di atas normal; tren masih naik)

- Autoscaling: dikonfigurasi untuk menambah replika ketika CPU > 80% selama 5 menit; saat ini sedang dalam proses scale-up yang akan menambah 3 replika dalam ~90 detik

Rancang Rencana Observabilitas Peluncuran

Sintesis

Anda sekarang dapat merancang /health yang mendeteksi kegagalan nyata, /version yang memungkinkan Anda memverifikasi deployment, dasbor empat sinyal emas di tingkat proxy, & pemicu kapasitas yang terikat pada laju pembakaran SLO.

Terapkan keempatnya.

Tim Anda akan meluncurkan search.example.com (layanan pencarian dari pelajaran mode kegagalan). Tim ingin merilis observabilitas yang mendeteksi masalah sebelum pengguna melakukannya, dengan matriks keputusan halaman-atau-tidak yang jelas. SLO: 99,9% permintaan berhasil, latensi p99 < 300 ms, dalam jendela 28 hari.

Penutupan Kursus

Penutupan Kursus

Anda telah menyelesaikan semua lima pelajaran:

- Proksi & Asal: bentuk lapisan tepi yang hampir digunakan oleh setiap layanan web publik

- Skala Horizontal Tanpa State: mengapa lapisan tanpa state dapat diperbanyak secara murah & cara menentukan ukurannya

- Pemisahan Ingress & Egress: mengapa satu kotak menjadi dua, & mode kegagalan yang memaksakannya

- Mode Kegagalan & Jangkauan Ledakan: SPOF, kaskade, pascabencana, item tindakan tanpa menyalahkan

- Observabilitas & Kapasitas (yang ini): apa yang harus diukur agar masalah muncul sebelum pengguna menyadarinya

Benang merahnya: sistem terdistribusi berskala web bukanlah keajaiban. Ini adalah kumpulan kecil pola (proxy terbalik, replika tanpa state, pemisahan ingress/egress, bulkhead & circuit breaker, empat sinyal emas) yang disusun secara cermat. Begitu Anda mengenali polanya, Anda akan melihatnya di setiap arsitektur produksi.

Pelajaran pendamping: lima pelajaran geometri-* mengemas ulang materi yang sama sebagai teori graf & geometri. Keduanya cocok diikuti dalam urutan mana pun.

Bagus sekali.