Keuntungan:
- Kemampuan untuk memahami tiga pilar observabilitas (metrik, log, jejak) dan empat sinyal emas serta memiliki kecerdasan buatan menghasilkan kueri PromQL, aturan alarm, dan dasbor
- Kemampuan untuk mencegah kelelahan alarm dengan menjaga alarm tetap berorientasi pada tindakan dan pada urgensi yang tepat serta menguji ambang batas terhadap data historis sistem Anda sendiri
- Kemampuan untuk mencegah kebocoran privasi dan rahasia dengan menutupi area sensitif sebelum memberikan log ke kecerdasan buatan
Meskipun suatu sistem tampak berfungsi, mungkin di dalamnya sedang sekarat: memori perlahan terisi, waktu respons meningkat, tingkat kesalahan meningkat. Satu-satunya cara untuk memperhatikan hal ini adalah dengan terus memantau sistem. Konsep yang lebih maju adalah observabilitas: kemampuan untuk memahami apa yang terjadi di dalam sistem dengan melihat tanda-tanda eksternalnya. Ada tiga pilar observabilitas, dan profesional DevOps menggunakan ketiganya:
- Metrik: Nilai numerik diukur dari waktu ke waktu — penggunaan CPU, jumlah permintaan, waktu respons, tingkat kesalahan. "Berapa harganya?" menjawab pertanyaan itu.
- Log: Catatan peristiwa teks yang dihasilkan oleh sistem—"pengguna masuk", "koneksi basis data terputus". Apa yang sebenarnya terjadi? menjawab pertanyaan itu.
- Jejak: Jalur yang diikuti permintaan saat meneruskan dari layanan ke layanan dalam sistem dan durasi setiap langkah. “Di mana kelambatannya?” menjawab pertanyaan itu.
Alat yang paling umum: Prometheus untuk metrik, Grafana untuk visualisasi, Loki/ELK untuk log, Jaeger/OpenTelemetry untuk pelacakan. AI sangat ahli dalam menulis bahasa kueri (terutama PromQL Prometheus), aturan alarm, dan konfigurasi dasbor untuk alat ini. Di sinilah AI berada pada posisi terkuatnya: merangkum sejumlah besar log dan metrik serta menandai anomali.
Mari kita perjelas perbedaan antara monitoring dan observability dalam satu kalimat: monitoring menanyakan pertanyaan yang sudah Anda ketahui (“Apakah CPU melewati 90%?”); observabilitas adalah kemampuan untuk mengajukan pertanyaan yang belum Anda ketahui ("mengapa kelambatan yang aneh ini hanya terjadi pada pelanggan tertentu pada waktu tertentu?"). Sistem modern sangat kompleks sehingga Anda tidak dapat memprediksi semua cara kegagalan; Oleh karena itu, kemampuan untuk mengumpulkan metrik, log, dan jejak yang kaya, lalu menanyakannya secara mendalam — yaitu, kemampuan observasi — menjadi sangat penting. Di sinilah AI berperan ketika menjawab "pertanyaan yang sebelumnya tidak diketahui": AI dengan cepat memindai data mentah yang Anda miliki, menyarankan pola dan anomali, dan Anda menemukan akar permasalahan dengan memverifikasi petunjuk-petunjuk ini.
Langkah demi langkah: apa dan bagaimana cara memantaunya?
- Pilih metrik yang tepat. Dalam industri ini, "empat sinyal emas" diambil sebagai dasar: latensi, lalu lintas, kesalahan, saturasi — seberapa penuh sumber dayanya. Ini merangkum kesehatan sebagian besar layanan.
- Kumpulkan metrik. Biarkan aplikasi menyajikan titik akhir yang dapat dibaca oleh Prometheus.
- Siapkan dasbor. Visualisasikan metrik ini di Grafana.
- Tulis aturan alarm. Siapa yang akan diberi peringatan ketika ambang batas terlampaui dan bagaimana caranya?
- Sentralisasi log. Jadikan semua log layanan dapat dicari di satu tempat.
- Kurangi kebisingan. Terlalu banyak alarm menciptakan “kelelahan kewaspadaan”; Alarm penting menghilang.
Tip: Alarm yang baik memenuhi dua hal: dapat ditindaklanjuti dan memiliki urgensi yang tepat. Alarm yang membangunkan seseorang pada jam 3 pagi pasti merupakan sesuatu yang benar-benar memerlukan intervensi malam hari. Jangan membangunkan siapa pun untuk sesuatu yang tidak memerlukan tindakan sendiri, seperti "CPU 70%"; menampilkannya di papan.
Bagaimana cara menulis aturan alarm?
Peringatan terdiri dari tiga komponen: kondisi (metrik mana yang melebihi ambang batas dan berapa lama), durasi (“selama 5 menit” untuk menghindari pemicuan fluktuasi sesaat), dan kepentingan/tindakan (kepada siapa, melalui saluran mana). AI dengan ahli menetapkan ketiga hal ini dalam konteks yang tepat. Misalnya, menerjemahkan aturan seperti “alarm kritis jika tingkat kesalahan melebihi 5% selama 5 menit” ke dalam PromQL adalah tugas sepersekian detik untuk AI — tetapi Anda memutuskan apakah ambang batas tersebut tepat untuk sistem Anda.
Perhatian: Ambang batas alarm yang disarankan oleh AI adalah asumsi umum. Beban normal, toleransi, dan dampak kerja sistem Anda berbeda. Sebelum Anda langsung memasukkan ambang batas ke dalam produksi, Anda melihat data historis dan bertanya "berapa kali ambang batas ini dipicu di masa lalu, berapa banyak di antaranya yang merupakan masalah nyata?" Jawab pertanyaannya.
Privasi log: peringatan kritis
Kayu gelondongan adalah sumber kebocoran yang paling sering diabaikan. Baris log mungkin secara tidak sengaja berisi kata sandi, nomor kartu kredit, atau data pribadi (berdasarkan KVKK/GDPR). Saat menempelkan log ke AI untuk dianalisis:
- Tutupi area sensitif. Ganti nilai seperti token, kata sandi, email, nomor ID dengan <DISUNTING>.
- Berikan contoh, tidak semua. Daripada satu juta baris, beberapa ratus baris representatif seringkali sudah cukup.
- Pilih kendaraan yang disetujui institusi. Khusus untuk log produksi, gunakan alat yang datanya tidak masuk ke pelatihan.
Empat sinyal emas dan tabel alarm
sinyal
diukur dengan
Contoh ambang batas alarm
urgensi
latensi
waktu respons
hal95 > 800 mdtk, 5 mnt
tinggi
lalu lintas
Permintaan/detik
Mendadak naik/turun 300%.
sedang
Kesalahan
Tingkat permintaan gagal
> 5%, 5 menit
kritis
Saturasi
okupansi sumber daya
Disk > 85%
tinggi
tiga kasus mini
Kasus 1 — 400 baris log diringkas dalam 30 detik. Sebuah layanan melambat. Insinyur memberikan 400 baris log yang disamarkan kepada AI dan berkata, "ringkas pola kesalahan yang berulang dan intensitas waktu." AI menunjukkan bahwa waktu panggilan API eksternal tertentu habis setiap 30 detik. Akar permasalahan ditemukan dalam 30 detik; Memindai log secara manual akan memakan waktu setengah jam.
Kasus 2 — kelelahan alarm teratasi. Satu tim menerima 200 alarm sehari dan mengabaikan semuanya — sampai alarm pemadaman listrik yang sebenarnya juga terabaikan. Berikan AI semua aturan peringatan dan tanyakan "mana yang tidak dapat ditindaklanjuti dan mana yang dapat digabungkan?" mereka bertanya. Jumlah alarm berkurang menjadi 12 per hari; Setiap alarm kini ditanggapi dengan serius.
Kasus 3 — ambang batas yang salah diketahui lebih awal. YZ menyarankan "Peringatkan ketika 95% penuh" untuk disk. Insinyur melihat data historis: setelah disk mencapai 95%, hanya ada sedikit waktu untuk melakukan intervensi. Mereka menurunkan ambang batas menjadi 80% dan menambahkan peringatan kedua berdasarkan “tingkat pertumbuhan.” Verifikasi mencegah pemadaman tengah malam yang sebenarnya.
Empat templat yang dapat disalin
1) Peringkasan log (disamarkan):
Analisis contoh log di bawah ini (saya menutupi nilai sensitif dengan <REDACTED>). Beri saya: (1) pola kesalahan yang berulang, (2) konsentrasi dari waktu ke waktu, (3) kemungkinan besar penyebab utama, dan (4) 3 metrik yang akan saya lihat untuk diverifikasi. Catatan: [GARIS]
2) Pembuatan aturan alarm:
Tulis aturan alarm untuk Prometheus/Alertmanager: Buat alarm [SEVERITY] jika [THRESHOLD] melebihi [METRIC][DURATION]. Aturan harus berorientasi pada tindakan dan menyertakan bidang anotasi dan link runbook. Jelaskan PromQL dan tulis mengapa ambang batas ini masuk akal.
3) Menulis/mendeklarasikan kueri PromQL:
Tulis kueri PromQL yang mengukur: [EX. Persentase tingkat kesalahan 5xx dalam 5 menit terakhir]. Jelaskan pertanyaannya langkah demi langkah. Lalu beri tahu saya berapa kisaran sehat untuk nilai ini.
4) Desain dasbor:
Rancang dasbor Grafana untuk [LAYANAN]: dengan panel manakah saya harus menampilkan empat sinyal emas (latensi, lalu lintas, kesalahan, saturasi)? Sarankan metrik, jenis visualisasi, dan ambang batas yang wajar untuk setiap panel. Tujuan: untuk melihat status kesehatan seorang penjaga dalam 10 detik.
Perintah lemah / Perintah kuat
Lemah: "Apa isi log itu?" (diikuti oleh 5000 baris log mentah, token di dalamnya)
Hasilnya: Anda membocorkan rahasia dan AI memberikan ringkasan dangkal yang tidak ditargetkan.
Kuat: "Temukan pola kesalahan berulang dan intensitas waktu dalam contoh log bertopeng 300 baris di bawah; beri tahu saya penyebab utama yang paling mungkin dan metrik yang akan saya lihat untuk memverifikasi. Saya membuat tokennya <DISUNTING>."
Perbedaan: perintah kedua memberikan contoh yang terselubung dan terfokus, meminta keluaran analisis yang jelas; Ini aman dan bermanfaat.
Kesalahan umum
- Menempelkan log ke AI tanpa menutupinya. Kebocoran rahasia/data pribadi yang paling umum.
- Menyetel alarm untuk semuanya. Kelelahan karena alarm mengubur alarm yang sebenarnya.
- Alarm yang tidak dapat ditindaklanjuti. Ini adalah suara peringatan yang tidak dapat dilakukan oleh siapa pun.
- Menerima ambang batas AI tanpa pertanyaan. Ambang batas harus ditetapkan berdasarkan riwayat sistem Anda.
- Hanya melihat metriknya. Tanpa pencatatan dan penelusuran, akar permasalahan hampir selalu tidak dapat ditemukan.
- Tidak mengatur waktu alarm (untuk). Fluktuasi sesaat menghasilkan alarm palsu.
Singkatnya
Observabilitas; Ini adalah kemampuan untuk memahami bagian dalam sistem dari luar dengan metrik, log, dan jejak. Empat sinyal emas (latensi, lalu lintas, kesalahan, saturasi) merangkum kesehatan sebagian besar layanan. AI sangat hebat dalam menulis kueri PromQL, aturan alarm, dan dasbor, serta dalam meringkas sejumlah besar log dan menemukan anomali. Namun Anda bertanggung jawab untuk memverifikasi ambang batas alarm terhadap riwayat sistem Anda, menjaga alarm tetap berorientasi pada tindakan, dan jangan pernah membagikan log tanpa menyembunyikannya.
Tugas aplikasi
Untuk layanan (atau layanan sampel): (1) Buat aturan alarm untuk tingkat kesalahan dengan templat "Pembuatan aturan alarm" dan tetapkan ambang batas yang disarankan ke "berapa kali aturan tersebut dipicu di masa lalu?" Ujilah dengan pertanyaan; (2) menutupi sampel log yang Anda miliki dan menganalisisnya dengan templat "Peringkasan log"; (3) catat metrik mana yang akan Anda lihat untuk memastikan penyebab utama yang paling mungkin terjadi.
daftar periksa
- [ ] Saya memilih metrik untuk dilacak berdasarkan empat sinyal emas.
- [ ] Saya menutupi semua log yang saya berikan kepada AI dalam hal area sensitif.
- [ ] Saya memverifikasi bahwa setiap alarm berorientasi pada tindakan dan memiliki urgensi yang benar.
- [ ] Saya menguji ambang batas alarm terhadap data historis sistem saya.
- [ ] Saya memfilter fluktuasi sesaat dengan menambahkan (durasi) ke alarm.
- [] Saya menggunakan metrik + log + jejak bersama-sama untuk akar permasalahan.