Dasbornya berwarna hijau, namun pelanggan mengeluh bahwa pembayarannya rusak. Jika Anda pernah berada di posisi ini, Anda sudah memahami perbedaan antara pemantauan vs kemampuan observasi. Pemantauan Anda hanya memeriksa apa yang ingin Anda periksa, dan kegagalan ini adalah sesuatu yang baru.

Panduan ini menjelaskan kedua ide tersebut tanpa bahasa pemasaran, dan mengikuti satu kejadian fiktif mulai dari peringatan hingga akar permasalahan. Log, jejak, dan angka diciptakan untuk mengilustrasikan prosesnya. Anda juga harus tahu bahwa vendor dan praktisi mengambil garis ini secara berbeda, dan beberapa orang menganggapnya sebagai bagian dari perbedaan pemasaran. Kami fokus pada bagian praktisnya.

Jawaban singkatnya

Pemantauan adalah sebuah aktivitas. Anda memutuskan terlebih dahulu apa yang harus diperhatikan, seperti CPU, tingkat kesalahan, atau ruang disk, dan Anda menetapkan ambang batas yang memicu peringatan. Ia menjawab: “Apakah hal yang saya khawatirkan terjadi?”

Observabilitas adalah properti sistem Anda. Istilah ini berasal dari teori kontrol, yang menggambarkan seberapa baik Anda dapat menyimpulkan keadaan internal suatu sistem dari keluaran eksternalnya. Dalam praktiknya, ia menjawab: “Apa yang terjadi dan mengapa, termasuk masalah yang tidak pernah saya perkirakan?”

Bayangkan sebuah mobil. Lampu peringatan di dashboard sedang memantau. Mereka mencakup serangkaian masalah yang diketahui. Port diagnostik lengkap seorang mekanik, yang memungkinkan seseorang mengajukan pertanyaan baru tentang bagian mana pun dari mesin, lebih dekat dengan kemampuan observasi.

Pemantauan vs observasi secara berdampingan

Ini bukanlah pilihan di antara keduanya. Anda masih memerlukan peringatan untuk memberi tahu Anda kapan harus mencarinya.

Mengapa pemantauan saja tidak cukup

Dengan satu aplikasi di satu server, daftar kesalahan yang mungkin terjadi cukup singkat, sehingga Anda dapat menonton semuanya. Sistem modern mungkin memiliki lusinan layanan, antrean, dan API pihak ketiga, ditambah container yang datang dan pergi. Kegagalan menjadi kombinasi yang tidak dapat diprediksi oleh siapa pun: satu wilayah, satu jenis pelanggan, versi aplikasi tertentu, dan satu ketergantungan lambat.

Anda tidak dapat menulis dasbor terlebih dahulu untuk pertanyaan yang belum terpikirkan. Anda memerlukan data yang memungkinkan Anda menanyakannya setelahnya.

Log, metrik, dan jejak

Ketiga jenis telemetri ini sering disebut sebagai pilar observabilitas. Masing-masing menjawab pertanyaan berbeda:

Metrik

http_requests_total{service="checkout", status="500"} 1832
http_request_duration_seconds{service="checkout", quantile="0.95"} 2.4

Metrik murah untuk disimpan dan cepat untuk dikueri, sehingga ideal untuk dasbor dan peringatan. Berhati-hatilah terhadap label berkardinalitas tinggi, seperti ID pengguna, di banyak sistem metrik, karena label tersebut dapat meningkatkan biaya secara drastis.

Jejak

Pelacakan mengikuti satu permintaan di seluruh layanan. Setiap langkah adalah span dengan waktu mulai dan durasi:

POST /checkout                      2410 ms
├─ auth-service: verify token         18 ms
├─ cart-service: load cart            42 ms
├─ pricing-service: calculate       2290 ms   <-- slow
│  └─ SELECT coupons ...            2265 ms
└─ payment-service: not reached

Jejak membuat langkah lambat menjadi jelas, yang sangat sulit dilihat di log terpisah dari layanan terpisah.

Log

Log memberikan detail tentang apa yang terjadi pada suatu saat. Kami melihat bagaimana menjadikannya berguna dalam sekejap.

Panduan insiden

Berikut adalah bagaimana potongan-potongan itu disatukan, dalam contoh fiksi.

Pemantauan ditangani pada langkah 1. Segala sesuatu setelah itu adalah observasi. Perhatikan bagaimana setiap pertanyaan muncul dari jawaban sebelumnya. Tidak ada yang bisa membuat dasbor sebelumnya untuk “permintaan kupon aplikasi seluler dari kampanye hari ini”. Untuk perbaikannya sendiri, panduan kami untuk optimasi kueri SQL menunjukkan cara membaca rencana semacam itu.

Log yang lebih baik

Log teks biasa dibuat untuk dilihat manusia, dan sulit untuk ditanyakan. Log terstruktur menggunakan kolom yang dapat difilter oleh mesin:

# Hard to search
ERROR Payment failed for user 42 after 3 tries

# Easy to search
{"level":"error","event":"payment_failed","user_id":"42",
 "attempts":3,"provider":"acme","trace_id":"a1b2c3","duration_ms":2410}

Dengan formulir kedua, Anda bisa langsung bertanya “berapa kegagalan per penyedia dalam satu jam terakhir?” Bidang trace_id sangat berharga karena menghubungkan baris log ke seluruh permintaan, di setiap layanan yang disentuhnya.

Jangan pernah mencatat kata sandi, token, atau nomor kartu, dan berhati-hatilah dengan data pribadi. Seperti yang dijelaskan oleh panduan kami, JWT dapat digunakan kembali oleh siapa saja yang membacanya dari log.

Sinyal emas

Tidak yakin apa yang harus dipantau? Buku Site Reliability Engineering Google menyarankan empat sinyal untuk sistem yang dihadapi pengguna:

Gunakan persentil untuk latensi, karena rata-rata menyembunyikan permintaan yang lambat, seperti yang kami tunjukkan di pengujian beban vs pengujian stres.

Memperingatkan kepercayaan orang

Jika peringatan menyala sepanjang waktu, orang akan berhenti membacanya. Yang bagus mengikuti beberapa aturan:

• Peringatan tentang gejala yang dirasakan pengguna. “Kesalahan pembayaran di atas 2%” mengalahkan “CPU pada 85%”. CPU tinggi yang tidak merugikan siapa pun seharusnya tidak membangunkan siapa pun.
• Jadikan setiap peringatan dapat ditindaklanjuti. Jika tidak ada yang perlu melakukan apa pun, jadikan itu sebagai item dasbor atau hapus.
• Tautan ke runbook. Beri tahu responden di mana mencarinya dan apa yang harus dicoba.
• Tinjau secara berkala. Hapus atau perbaiki peringatan apa pun yang diabaikan bulan lalu.

Tujuan tingkat layanan

SLO mengubah “situs harus cepat dan andal” menjadi target yang terukur, seperti “99,9% permintaan pembayaran berhasil dalam 30 hari”. Hal ini memungkinkan terjadinya sekitar 0,1% kegagalan, yang dikenal sebagai anggaran kesalahan. Jika masih banyak, Anda dapat mengirim lebih cepat, dan jika hampir habis, Anda dapat memprioritaskan keandalan. Ini adalah cara yang berguna untuk menyelesaikan perselisihan antara kecepatan pengiriman dan stabilitas.

OpenTelemetri dan alat

OpenTelemetry adalah standar sumber terbuka dan netral vendor untuk menghasilkan dan mengekspor telemetri. Ini adalah proyek dari Cloud Native Computing Foundation. Menginstrumentasikannya berarti Anda dapat mengubah backend Anda nanti tanpa menulis ulang kode Anda. Ini bukan produk penyimpanan atau dasbor itu sendiri, jadi Anda memasangkannya dengan salah satu produk berikut:

Periksa sendiri fitur dan harga terkini, karena produk ini sering berubah. Biaya dapat bertambah dengan cepat seiring dengan volume data, jadi gunakan pengambilan sampel dan tetapkan batas retensi.

Bagaimana memulainya

1. Mulailah dengan sinyal emas untuk layanan terpenting Anda.
2. Tambahkan satu atau dua peringatan tentang gejala yang diperhatikan pengguna.
3. Beralih ke log terstruktur, dengan ID permintaan di setiap baris.
4. Tambahkan penelusuran ke perjalanan pengguna utama Anda dengan OpenTelemetry, karena instrumentasi otomatis dapat mencakup banyak kerangka kerja umum.
5. Tautkan penerapan ke grafik Anda, sehingga Anda dapat melihat apakah rilis dari pipa CI/CD Anda menyebabkan perubahan.
6. Belajarlah dari setiap kejadian. Setelah setiap kejadian, tanyakan data apa yang dapat mempercepat penyelesaian masalah, dan tambahkan data tersebut.

Sebuah tim kecil dengan satu layanan tidak memerlukan platform yang besar. Metrik dasar, log yang bagus, dan beberapa peringatan mungkin sudah cukup. Penelusuran semakin bermanfaat seiring dengan bertambahnya jumlah layanan.

Kesalahan umum

• Membeli alat dan menyebutnya sebagai kemampuan observasi. Nilainya berasal dari instrumentasi yang baik dan cara Anda menggunakan data.
• Memperlakukan tiga pilar sebagai daftar periksa. Data yang terpisah tanpa cara untuk menghubungkannya membuat Anda harus menelusuri tab. ID bersama itu penting.
• Mengumpulkan semuanya. Telemetri tanpa filter menjadi mahal dan menambah kebisingan.
• Terlalu banyak dasbor. Beberapa tampilan tepercaya mengalahkan seratus tampilan yang tidak dibuka oleh siapa pun.
• Menganggapnya menggantikan pengujian. Anda masih memerlukan pengujian sebelum rilis. Rilis Canary berpasangan dengan baik dengan sinyal-sinyal ini.

Penutup

Pemantauan memberi tahu Anda bahwa ada sesuatu yang tidak beres, dan kemampuan observasi memberi Anda sarana untuk mencari tahu alasannya. Tes praktisnya sederhana: ketika masalah asing muncul, dapatkah Anda menemukan penyebabnya tanpa mengirimkan kode baru? Lain kali Anda mengalami suatu insiden, tuliskan setiap pertanyaan yang tidak dapat Anda jawab. Daftar itu adalah peta jalan Anda.

Pertanyaan yang sering diajukan

Teruslah belajar