AI telah mengubah cara kita membangun perangkat lunak, tetapi ia tidak mengubah kebenaran mendasar tentang mesin. Mereka tenggelam dalam kebisingan (noise) sama seperti kita. Saat para insinyur pertama kali bereksperimen dengan debugging berbantuan AI, instingnya sederhana: berikan semua data ke model tersebut. Log mentah, trace, dan metrik semuanya dimasukkan ke dalam context window. Hasilnya bukanlah wawasan, melainkan kegagalan. Volumenya terlalu tinggi. Sinyalnya runtuh. Metrik berada di satu alat, trace di alat lain, dan model tidak dapat menyatukannya menjadi sebuah cerita yang koheren. Sebelum AI dapat membantu Anda mengamati sistem Anda, Anda harus mengamatinya sendiri terlebih dahulu. Anda harus membentuk datanya terlebih dahulu.

Mengapa Log Mentah Merusak Pipeline AI

Sistem modern menghasilkan telemetri pada kecepatan yang tidak dapat dibaca oleh manusia mana pun. Hal itu seharusnya membuat mereka sempurna untuk kecerdasan buatan. Kenyataannya tidak. Context window dari large language model, meskipun terus berkembang, tetaplah sebuah pipa yang terbatas. Isi dengan log produksi yang tidak terfilter dan Anda akan membuang-buang token untuk heartbeat cron job dan kebisingan health-check, sementara mengubur gangguan (outage) yang sebenarnya. Lebih buruk lagi, log mentah tidak memiliki hubungan (relationships). Lonjakan latensi pada pukul 14.00 dan kesalahan koneksi database dalam log pada timestamp yang sama jelas saling berhubungan, tetapi kecuali jika seseorang telah menyusun hubungan tersebut sebelumnya, AI harus menebak. Menebak itu mahal, lambat, dan sering kali salah.

Solusinya bersifat arsitektural, bukan algoritmik. Anda perlu memutuskan apa yang dikumpulkan, bagaimana data tersebut dibentuk, dan backend mana yang menjawab pertanyaan apa sebelum Anda memberikan prompt ke model.

Empat Poros Pemantauan

Di airCloset, tim engineering berhenti memperlakukan observability sebagai satu aliran data (firehose) tunggal. Mereka membagi pemantauan menjadi empat poros yang berbeda. Masing-masing memiliki bentuk tertentu dan menjawab pertanyaan tertentu.

  • Application: Log dan trace menjawab "Apa yang sedang terjadi saat ini?"
  • Infrastructure: Metrik menjawab "Apakah kita memiliki sumber daya yang cukup?"
  • CI: Log dan alert menjawab "Apa yang rusak dan kapan?"
  • LLM: Metrik dan catatan terstruktur menjawab "Berapa banyak yang kita habiskan?"

Pemisahan ini penting karena bentuk yang tepat untuk grafik latensi real-time tidak berguna untuk analisis biaya post-hoc. Memaksakan satu skema di keempat domain tersebut justru menciptakan jenis kebisingan yang membuat bantuan AI menjadi tidak berguna.

Observability CI: Tarik (Pull), Jangan Dorong (Push)

Continuous integration adalah tempat di mana kode bertemu dengan realitas. Saat build gagal, pengembang membutuhkan penjelasannya dengan cepat. Pendekatan naifnya adalah membiarkan CI runner mendorong (push) log secara langsung ke backend observability Anda saat sedang berjalan. Terasa efisien, padahal sebenarnya berbahaya.

Di airCloset, mereka membalik model tersebut. CI runner tidak menyentuh stack observability. Setelah workflow GitHub Actions selesai, mereka menarik (pull) log dari GitHub API dan memasukkannya (ingest) ke dalam Loki.

Arsitektur pull ini memberikan tiga keuntungan nyata.

Decoupling. Jika pipeline ingest mengalami kendala atau Grafana tidak dapat dijangkau, proses pengujian itu sendiri tidak akan terganggu. Build akan berhasil atau gagal berdasarkan kemampuannya sendiri. Kegagalan pada sistem observability tidak boleh menghentikan deployment.

Security. Workflow CI tidak pernah membutuhkan API key Grafana. Kode pengujian terkenal sering menyentuh rahasia (secrets) yang seharusnya tidak diakses, dan menghilangkan paparan tersebut akan memperkecil radius dampak (blast radius) jika ada dependensi yang terkompromi.

Cross-querying. Setelah CI