Belajar Observability dengan LGTM Stack - Sejarah, Latar Belakang & Mengapa Membutuhkan Observability

#Pendahuluan

Sebelum membangun stack, kita perlu memahami mengapa observability menjadi kata kunci di era cloud-native. Istilah ini bukan sekadar pengganti kata "monitoring" yang lebih keren — ia membawa perubahan fundamental dalam cara berpikir tentang sistem yang kompleks.

Episode ini menelusuri evolusi dari monitoring tradisional menuju observability, masalah konkret yang ia selesaikan, memperkenalkan LGTM Stack, lalu membandingkannya dengan alternatif populer seperti ELK Stack dan solusi komersial. Di akhir episode, kalian akan tahu kapan dan mengapa memilih LGTM.

#Evolusi Observability

#Dari Monitoring Tradisional ke Observability

Monitoring tradisional bekerja dengan premis "kita tahu apa yang harus diukur": CPU, memori, disk, dan beberapa metrik aplikasi yang sudah dikenal. Pendekatan ini lahir di era monolith dan server statis, ketika prediksi kegagalan relatif mudah karena sistem bersifat deterministik.

Era cloud-native mengubah segalanya. Microservices membuat jumlah komponen meledak, container hidup mati secara dinamis, dan kegagalan bisa datang dari banyak kombinasi. Konsep monitoring vs observability kemudian muncul: monitoring bertanya "apakah sistem ini sehat?", sedangkan observability bertanya "mengapa sistem ini berperilaku seperti ini?" — bahkan untuk pertanyaan yang belum pernah kalian pikirkan sebelumnya.

Perbedaan tersebut bukan sekadar permainan kata. Monitoring bergantung pada daftar metrik yang sudah diketahui, sehingga kalian hanya bisa menemukan masalah yang sudah diduga. Observability berfokus pada kemampuan sistem dieksplorasi, sehingga masalah baru yang belum pernah diduga pun bisa diselidiki dari data yang sudah dikumpulkan.

#Three Pillars dan Cloud-Native Challenges

Praktik observability modern berlandaskan three pillars of observability: metrics, logs, dan traces. Ketiganya akan kalian dalami di episode 2. Yang penting sekarang adalah memahami bahwa pillars ini saling melengkapi — metrik memberi tahu apa yang terjadi, log memberi tahu apa yang persis terjadi, dan trace memberi tahu di mana masalahnya.

Alat observability sendiri berevolusi cepat: dari SNMP dan Nagios, ke Prometheus dan Grafana, lalu munculnya backend terskalakan seperti Loki, Tempo, dan Mimir. Tantangan terbesar era ini adalah volume data yang membesar dan kebutuhan correlation antar sinyal telemetry.

#Masalah yang Diselesaikan

Kompleksitas sistem terdistribusi membuat debugging manual menjadi mustahil. Ketika sebuah request melewati dua puluh service, di mana kalian mencari sumber keterlambatan? Di sinilah observability menjawabnya.

• Distributed systems complexity: banyak komponen, banyak titik kegagalan, sulit dinalar tanpa data.
• Microservices debugging: tanpa trace, kalian hanya menebak service mana yang bermasalah.
• Black box vs white box monitoring: white box melihat ke dalam sistem lewat metrik internal, bukan sekadar menebak dari luar.
• MTTD dan MTTR: observability mempersingkat waktu deteksi (Mean Time To Detection) dan perbaikan (Mean Time To Resolution).
• Unknown unknowns: kegagalan yang tidak pernah terpikirkan sebelumnya — observability memungkinkan kalian menyelidikinya.
• Correlation across telemetry signals: menghubungkan metrik, log, dan trace dalam satu alur penyelidikan.

Istilah MTTD dan MTTR akan kembali dibahas di episode 21 bersama incident response. Untuk sekarang, pahami bahwa keduanya adalah ukuran bisnis yang paling sering dipakai untuk menjual pentingnya observability.

Inti dari semua masalah di atas sama: semakin besar dan tersebar sebuah sistem, semakin mahal biaya ketidaktahuan. Observability adalah investasi untuk menghapus biaya tersebut sejak dini, bukan setelah insiden besar terjadi.

#LGTM Stack Overview

#Komponen dan Alasan Memilih

LGTM Stack terdiri dari empat produk open-source yang dikembangkan Grafana Labs:

• Loki: agregasi log yang hemat biaya, memakai label ala Prometheus dan tidak memerlukan indexing penuh.
• Grafana: platform visualisasi, dashboard, dan query yang menyatukan semua data source.
• Tempo: backend distributed tracing berbasis object storage dengan dukungan OTLP native.
• Mimir: storage metrik jangka panjang yang kompatibel dengan Prometheus dan scalable horizontal.

Keunggulan utama LGTM adalah integrasi yang mulus: ketiganya dipasangkan ke Grafana secara native, berbagi model data, dan mendukung query terpadu. Tidak ada vendor lock-in karena seluruhnya open-source dan berkomunikasi lewat protokol standar seperti OTLP dan remote write.

grafana:  http://localhost:3000
loki:     http://localhost:3100  -> log dari Alloy
tempo:    http://localhost:3200  -> trace dari OTel SDK
mimir:    http://localhost:9009  -> metrik dari remote write

Skema alamat di atas akan kalian wujudkan nyata di episode 4. Untuk sekarang, cukup ingat empat port khas masing-masing komponen.

#Perbandingan dengan Alternatif

• LGTM vs ELK Stack (Elasticsearch, Logstash, Kibana): ELK unggul di full-text search, tapi mahal karena mengindex setiap baris log. LGTM menukar kemampuan search penuh dengan biaya storage yang jauh lebih rendah.
• LGTM vs PLG Stack (Prometheus, Loki, Grafana): PLG menggunakan Prometheus untuk metrik jangka pendek. Mimir menggantikan Prometheus untuk kebutuhan retention panjang dan skala besar.
• LGTM vs solusi komersial (Datadog, New Relic, Dynatrace): solusi komersial hemat waktu setup dan punya dukungan, tapi mahal per-host dan menciptakan lock-in.

Bagi tim yang sudah terbiasa dengan grafana, biaya operasional rendah, dan kebutuhan skala tinggi, LGTM adalah pilihan yang sangat menarik. Solusi komersial tetap layak dipertimbangkan bila tim kecil dan ingin go-live secepat mungkin.

Keputusan akhir biasanya ditentukan oleh tiga faktor: kematangan tim, anggaran, dan kebutuhan kepatuhan. Bagi tim yang sudah mengadopsi OpenTelemetry, LGTM menjadi pilihan paling alami karena seluruh komponennya menerima data lewat protokol standar secara native. Hal yang sama tidak selalu mudah dilakukan pada solusi komersial yang menutup ekosistemnya.

#Common Use Cases

LGTM Stack menangani beragam skenario produksi:

• Application performance monitoring (APM): melacak latency, error rate, dan throughput per service.
• Infrastructure monitoring: memantau CPU, memori, disk, dan jaringan dari seluruh host.
• Distributed tracing: memetakan perjalanan request antar microservices.
• Log aggregation dan analysis: menyatukan log dari ribuan container ke satu tempat.
• Incident response dan debugging: mempercepat root cause analysis.
• SLO dan SLA monitoring: memantau target keandalan layanan secara terus menerus.
• Capacity planning: memakai data historis untuk merencanakan kebutuhan resource.

curl -s http://localhost:3000/api/health | jq .

Perintah curl di atas akan kalian pakai terus untuk memeriksa kesehatan komponen. Latih sekarang agar terbiasa memvalidasi API dari terminal.

#Penutup

Di episode 1 ini kalian memahami bahwa observability adalah evolusi monitoring tradisional untuk menjawab kompleksitas cloud-native, mengenal masalah yang ia selesaikan, memahami peran tiap komponen LGTM Stack, dan membandingkannya dengan ELK, PLG, serta solusi komersial.

Inti yang harus dibawa pulang:

• Observability menjawab "mengapa", bukan hanya "apakah sehat".
• Three pillars metrics, logs, dan traces saling melengkapi.
• LGTM Stack terdiri dari Loki, Grafana, Tempo, dan Mimir.
• LGTM menawarkan biaya lebih rendah daripada ELK dan solusi komersial.
• MTTD dan MTTR adalah ukuran bisnis utama yang ditekan observability.
• Use case mencakup APM, infrastructure, tracing, log, incident, dan SLO.

Di episode 2 selanjutnya kita akan membedah three pillars of observability — konsep dan filosofi di balik metrics, logs, dan traces, termasuk metode USE dan RED, hingga cara mengorelasikan ketiganya. Siapkan catatan, karena episode ini menjadi fondasi semua pembahasan teknis berikutnya.