Apa Itu Observability? Panduan Ringkas untuk Spreadsheet

Apa itu observability? Observability adalah kemampuan untuk memahami apa yang sedang dilakukan sebuah sistem, dan mengapa, hanya dengan data yang dikeluarkannya: log, metrik, dan trace. Kalau monitoring memberi tahu bahwa ada yang rusak, observability membantumu mengajukan pertanyaan berikutnya: di mana, untuk siapa, dan sejak kapan. Kalau kamu sering bekerja di spreadsheet, sebenarnya kamu sudah melakukan versi kecilnya setiap kali menelusuri angka aneh sampai ke baris sumbernya.

Versi satu menit untuk kamu yang hidup di spreadsheet

Bayangkan sheet pendapatan bulanan yang totalnya kelihatan salah. Dashboard yang cuma bilang "total tidak beres" itu monitoring. Bisa memfilter per wilayah, per hari, dan per produk sampai menemukan satu impor yang menggandakan 400 baris, itu namanya observability.

Tim software mengalami tembok yang sama pada sistem yang sedang berjalan. Halaman checkout melambat. Alert menyala. Sekarang seseorang harus mencari tahu layanan mana, segmen pelanggan mana, dan deploy mana yang menjadi penyebabnya. Data yang membuat itu mungkin disebut telemetri, dan seberapa baik kamu bisa memakainya itulah yang dimaksud orang ketika bicara soal observability.

Biscuit punya versi sendiri dari hal ini. Dia tidak perlu diberi tahu bahwa bola sudah hilang. Dia cuma perlu menelusuri lagi di mana bola terakhir kelihatan.

Monitoring vs observability: masalah yang sudah diketahui vs kejutan

Monitoring mengawasi hal-hal yang kamu putuskan untuk diawasi sejak awal. CPU di atas 90 persen, tingkat error di atas 2 persen, atau halaman yang berhenti merespons. Kamu yang menulis aturannya, dan alatnya berteriak begitu aturan itu dilanggar.

Observability dibuat untuk masalah yang tidak pernah kamu tuliskan aturannya. Proyek OpenTelemetry menjelaskannya sebagai cara memahami sebuah sistem dari luar, tanpa harus tahu cara kerja bagian dalamnya. Ini yang membantu menghadapi "unknown unknowns", yaitu hal-hal yang sama sekali tidak kamu duga.

Jangan berpikir salah satunya menggantikan yang lain. Monitoring itu alarm asap di rumahmu. Observability itu denah rumah dan rekaman CCTV yang kamu putar setelah kejadian. Kamu butuh keduanya.

Log, metrik, dan trace: tiga bahan mentah utamanya

Hampir setiap penjelasan berujung pada tiga sinyal yang sama. Berikut masing-masing dalam istilah spreadsheet.

Log adalah pesan berstempel waktu tentang kejadian individual. Di sheet, ini berupa satu baris per kejadian: waktu, pengguna, aksi, dan hasilnya. Log menyimpan detail paling banyak dan paling banyak memakan tempat.

Metrik adalah angka yang diagregasi dari waktu ke waktu, seperti tingkat error, jumlah request per menit, atau memori yang terpakai. Di sheet, ini seperti tab ringkasan. Murah disimpan dan cepat dibuat grafiknya, tetapi tidak bisa memberi tahu request tunggal mana yang gagal.

Trace mengikuti satu request saat ia berpindah melewati beberapa layanan, lengkap dengan waktu yang dihabiskan di setiap langkah. Di sheet, bayangkan satu ID pesanan yang kamu lacak di lima tab, sambil mencatat berapa lama ia menunggu di setiap tab.

Singkatannya begini: metrik memberi tahu bahwa ada yang salah, trace memberi tahu kira-kira di mana, dan log memberi tahu detailnya. Begini tampilannya di sel yang nyata, dalam satu menit.

Kamu punya 5,000 baris log dalam satu file: contoh kerja di Sheets

Anggap kamu mengekspor 5,000 baris log aplikasi ke Google Sheets. Kolom A berisi timestamp, kolom B nama layanan, kolom C kode status, dan kolom D waktu respons dalam milidetik. Rumusnya berfungsi di Excel dan Sheets, kecuali disebutkan lain. Nama fungsi di bawah memakai bahasa Inggris. Kalau Excel atau Sheets kamu berbahasa Indonesia, nama fungsinya biasanya sudah diterjemahkan, jadi cek lagi di daftar fungsi.

Pertama, tingkat error, metrik klasik:

=COUNTIF(C2:C5001, ">=500") / COUNTA(C2:C5001)

• Rentangnya C2:C5001, yaitu kode status.

• Kriteria ">=500" menghitung semua error server.

• Dibagi dengan COUNTA untuk mendapatkan porsinya dari seluruh request. Format sel sebagai persentase.

Itu monitoring: satu angka dan satu ambang batas. Sekarang bagian observability-nya. Layanan mana yang bertanggung jawab?

=QUERY(A1:D5001, "select B, count(C) where C >= 500 group by B order by count(C) desc", 1)

Rumus ini hanya ada di Sheets, karena QUERY tidak punya padanan di Excel. Argumennya:

• Datanya A1:D5001, termasuk header.

• Teksnya adalah kueri kecil mirip SQL: hitung error per layanan, dari yang paling banyak.

• Angka 1 di akhir berarti ada satu baris header.

Di Excel 365, kamu mendapat jawaban yang sama dengan resep yang berbeda:

=LET(s, FILTER(B2:B5001, C2:C5001>=500), u, UNIQUE(s), HSTACK(u, COUNTIF(s, u)))

Itu butuh Excel 365 atau 2021, karena FILTER, UNIQUE, dan HSTACK tidak ada di Excel 2016. Untuk versi yang lebih lama, pivot table lebih cocok.

Untuk request yang lambat, persentil ke-95 lebih jujur daripada rata-rata:

=PERCENTILE(D2:D5001, 0.95)

Kalau rata-rata waktu respons 180 ms tetapi persentil ke-95 mencapai 2,400 ms, berarti satu dari dua puluh pengguna sedang mengalami hari yang buruk. Rata-rata menyembunyikan itu, dan itulah jebakan yang coba dihindari oleh alat observability.

Biscuit sudah mengambilkannya untukmu kalau rumus adalah bagian yang sering kamu lupa. Formula.dog mengubah deskripsi dalam bahasa biasa menjadi rumus seperti ini.

Di mana observability muncul dalam hari kerja biasa

Kamu tidak perlu menjalankan server untuk bertemu dengannya. Lead support yang bertanya "kenapa tiket naik dua kali lipat hari Selasa?" sedang melakukannya. Begitu juga analis keuangan yang menelusuri selisih sampai ke satu faktur pemasok, atau staf operasional yang menemukan bahwa impor malam hari diam-diam melewatkan satu file.

Di dunia software, pertanyaan seperti ini makin tajam karena sistemnya terdistribusi. Satu klik tombol bisa menyentuh API gateway, layanan autentikasi, database, dan penyedia pembayaran. Saat gagal, pesan error yang kamu lihat jarang berada di tempat masalahnya dimulai. Trace menampilkan seluruh rantai, dengan tautan yang lambat atau rusak disorot, sehingga tidak ada yang perlu menebak-nebak.

Ada tiga istilah yang sering muncul, jadi ini penjelasannya dengan bahasa biasa:

• Instrumentasi adalah menambahkan kode yang memancarkan telemetri. Bayangkan menambahkan kolom timestamp dan ID ke laporan yang dulu tidak punya keduanya.

• Kardinalitas adalah jumlah nilai berbeda yang bisa diambil sebuah field. Region punya kardinalitas rendah, sedangkan user ID punya kardinalitas sangat tinggi. Field berkardinalitas tinggi menjawab pertanyaan paling tajam, tetapi paling mahal untuk disimpan.

• SLO (service level objective) adalah target yang kamu janjikan pada diri sendiri, misalnya "99.5 persen checkout selesai di bawah dua detik". Ini mengubah kekhawatiran samar menjadi angka yang bisa kamu pantau.

Kumpulan dashboard belum tentu observability

Inilah opini yang bikin vendor kesal: punya ketiga sinyal tidak otomatis berarti kamu punya observability. Kalau metrik ada di satu alat, log di alat lain, dan trace di alat ketiga, seseorang harus mencocokkannya secara manual pada jam 2 pagi. Itu sama saja dengan tiga workbook tanpa kolom ID yang sama.

Tesnya sederhana. Ketika sesuatu yang tak terduga rusak, bisakah kamu mengajukan pertanyaan baru ke datamu tanpa harus merilis kode baru? Kalau jawabannya "kami harus menambah logging lalu deploy ulang", berarti kamu hanya punya monitoring dengan langkah tambahan.

Contohnya begini. Dashboard penjualan yang menampilkan omzet harian sudah bagus untuk memantau. Tetapi begitu omzet turun di satu kota, kamu perlu menelusuri pesanan dari kota itu, memisahkannya per kanal pembayaran, lalu melihat apakah ada kode promo yang gagal dipakai. Dashboard tidak bisa menjawab ketiga pertanyaan itu sekaligus. Data mentah yang punya kolom kota, kanal, dan kode promo bisa.

Ada dua hal yang membuat perbedaan dalam praktik:

• Konteks di setiap kejadian. Setiap baris log membawa request ID, nama layanan, dan versi, sehingga kamu bisa mengelompokkan dan memfilternya nanti. Ini kolom ID yang kamu harapkan ada di setiap ekspor.

• Detail disimpan cukup lama. Data berkardinalitas tinggi, seperti user ID dan order ID, adalah tempat jawaban sering bersembunyi, dan juga yang membuat tagihan naik.

Alat yang benar-benar dipakai orang, dan biayanya

Kamu tidak perlu membeli apa pun untuk memahami ide ini, tetapi pasar alatnya layak dikenali.

OpenTelemetry adalah standar terbuka untuk menghasilkan telemetri, bukan tempat menyimpan atau melihatnya. Kamu memasang instrumentasi sekali lalu mengirim datanya ke mana pun kamu mau.

Grafana Cloud dibangun di atas standar terbuka, dengan tier gratis 10,000 active metric series dan 50 GB log, trace, serta profil per bulan. Kamu juga bisa self-host stack open-source, dengan konsekuensi harus merakit sendiri Prometheus, Loki, dan Tempo.

Datadog adalah pilihan siap pakai: pasang agent, dapatkan dashboard yang berfungsi dalam hitungan menit, dan satu tempat untuk infrastruktur, APM, serta log. Jebakannya ada di tagihan. Harga per host (sekitar $15 per host per bulan hanya untuk infrastruktur) ditambah biaya terpisah untuk log dan custom metric bisa melonjak cepat setelah sekitar 50 host, dan tidak ada tier gratis permanen.

New Relic berada di tengah dari sisi harga: ingest data 100 GB per bulan gratis, lalu $0.40 per GB, dengan satu pengguna platform penuh sudah termasuk.

Layak dibayar kalau kamu punya tim platform kecil dan tidak punya minat menjalankan infrastruktur hanya untuk memantau infrastruktur. Lewati kalau kamu punya dua server dan satu developer. Format log yang baik dan rumus di atas sudah membawamu cukup jauh.

Apa yang bisa dilakukan Senin ini kalau kamu bukan engineer

Kamu mungkin tidak pernah menyentuh trace. Tapi cara berpikir observability mudah dipakai oleh siapa pun yang melaporkan angka untuk pekerjaannya.

Misalnya, tim marketing yang mengekspor data iklan setiap minggu tanpa kolom tanggal dan kanal akan kesulitan menjelaskan kenapa biaya per klik naik. Dengan dua kolom itu, pertanyaannya bisa dijawab dalam beberapa menit, tanpa menunggu siapa pun membuat laporan baru.

1. Tambahkan ID ke setiap ekspor. Kolom yang bisa kamu join lebih berguna daripada rumus pintar mana pun.

2. Simpan baris mentahnya. Jangan menimpa tab detail dengan nilai hasil tempel. Ringkasan itu metrik, baris mentah itu log.

3. Tulis apa yang dimaksud "normal". Ambang batas yang tidak pernah kamu definisikan tidak akan pernah menyala.

4. Ajukan pertanyaan ketiga. "Pendapatan turun" adalah alertnya. "Turun di mana?" adalah metriknya. "Turun karena baris yang mana?" adalah observability.

Lakukan itu, dan total aneh berikutnya di sheet kamu akan butuh sepuluh menit untuk dijelaskan, bukan setengah hari. Good boy, spreadsheet.

Kalau kamu cuma ingat satu hal: observability bukan produk yang dibeli, melainkan seberapa baik data yang dikeluarkan sistemmu membantu menjawab pertanyaan yang tidak kamu rencanakan.