Amati layanan dan penggunanya

Mulai dari pertanyaan

Pemantauan memeriksa kondisi yang sudah diketahui. Observability membantu menyelidiki perilaku sistem, termasuk kegagalan yang tidak diperkirakan. Lebih banyak dashboard tidak otomatis memberikan jawaban yang lebih baik.

Untuk layanan ekspor fiktif, mulai dari pertanyaan pengguna: dapatkah pengguna yang berwenang menerima ekspor yang benar dalam waktu yang disepakati? Lalu pilih sinyal yang mendukung pertanyaan tersebut dan membantu menjelaskan kegagalan.

OpenTelemetry menyediakan instrumentasi dan standar telemetri. OpenTelemetry dapat mengirimkan sinyal ke backend yang kompatibel. Anda tetap memerlukan penyimpanan, kueri, kontrol akses, retensi, dan orang yang menindaklanjuti bukti. Pengantar observability.

Hubungkan berbagai bentuk bukti

Metrik mengukur suatu besaran sepanjang waktu. Log mencatat kejadian. Trace menghubungkan operasi terkait saat permintaan melewati sistem. Span mewakili satu operasi dalam trace.

Untuk pekerjaan asinkron, pertahankan korelasi yang aman antara job yang dikirim dan eksekusi worker. Respons HTTP 202 dapat berarti pekerjaan diterima. Respons tersebut tidak membuktikan bahwa ekspor selesai.

Kirim peringatan ketika tindakan diperlukan

Tentukan SLI dan penyebutnya sebelum menetapkan SLO. Dalam contoh ini, hitung ekspor yang memenuhi syarat dan selesai dengan benar dalam durasi yang disepakati. Tentukan cara memasukkan job yang berlangsung lama dan job yang ditinggalkan ke dalam pengukuran.

Error budget menjelaskan kegagalan yang diizinkan dalam periode SLO. Burn rate menjelaskan seberapa cepat kegagalan menghabiskan anggaran tersebut. Panduan Google menggunakan beberapa rentang waktu untuk menyeimbangkan deteksi tepat waktu dan peringatan berlebihan. Peringatan berdasarkan SLO.

Panggil petugas ketika kondisi memerlukan tindakan segera. Masukkan pekerjaan dengan urgensi lebih rendah ke antrean. Setiap peringatan memerlukan penanggung jawab, penjelasan dampak, tautan penyelidikan, dan instruksi respons. Tinjau peringatan yang berulang kali tidak menghasilkan tindakan.

Jangan gunakan satu ambang umum untuk setiap layanan. Dampak pada pengguna, traffic, jam bisnis, dan kapasitas respons memengaruhi keputusan.

Lindungi pipeline telemetri

Telemetri dapat memuat data pribadi, token, parameter permintaan, dan dokumen rahasia. Tentukan field yang diizinkan sebelum pengumpulan. Batasi akses dan retensi. Hapus secret sebelum ekspor ke backend eksternal. Telemetri sensitif.

Jangan gunakan email pelanggan atau ID job unik sebagai label metrik. Label tanpa batas meningkatkan jumlah deret waktu dan dapat membuka pengenal. Gunakan dimensi terkendali untuk metrik. Tempatkan pengenal korelasi yang disetujui dalam log atau trace dengan kontrol akses.

Ukur pipeline itu sendiri. Periksa kegagalan penerimaan, data yang dibuang, dan usia pengamatan terbaru. Grafik error yang datar dapat berarti tidak ada error atau tidak ada telemetri yang masuk. Tampilkan perbedaan itu.

Selidiki kegagalan konkret

Layanan fiktif melaporkan HTTP 202 untuk setiap permintaan. Usia item dalam antreannya meningkat dari hitungan detik menjadi 15 menit. Log worker menunjukkan timeout database berulang. Sampel trace menunjukkan sebagian besar waktu worker dihabiskan dalam panggilan database.

Bukti ini mendukung penyelidikan terarah. Bukti tersebut belum memastikan apakah penyebabnya perubahan kueri, koneksi yang habis, atau kapasitas database. Bandingkan hipotesis ini dengan metode debugging.

Taiga Monitoring menyediakan tampilan kesehatan produk dengan sinyal ketersediaan dan pengalaman browser. Fitur ini melengkapi observability infrastruktur dan aplikasi; fitur ini tidak menggantikan sistem tersebut. Monitoring.