DevOps
Menguasai Observabilitas: Integrasi Loki dan Prometheus untuk Lingkungan yang Diskalakan Horizontal
Januari 202612 menit baca
Pernah dibangunkan jam 3 pagi oleh alert kritis, hanya untuk menghabiskan berjam-jam melompat antara berbagai tools mencoba mencari tahu apa yang salah? Anda tidak sendirian. Di dunia microservice yang diskalakan horizontal saat ini, pendekatan monitoring tradisional tidak lagi memadai. Perkenalkan Loki dan Prometheus—duo dinamis observabilitas cloud-native.
Dalam artikel ini, kita akan mendalami bagaimana kedua tools powerful ini bekerja bersama untuk memberikan visibilitas lengkap ke sistem terdistribusi Anda. Baik Anda menjalankan beberapa pod atau ribuan container, arsitektur ini akan menskalakan bersama Anda.
Pro tip: Buka diagram arsitektur saat membaca artikel ini—akan membantu Anda memvisualisasikan setiap komponen yang kita bahas.
Prometheus adalah standar industri untuk pengumpulan metrik di lingkungan cloud-native. Awalnya dikembangkan di SoundCloud dan sekarang menjadi proyek CNCF graduated, ia unggul dalam mengumpulkan, menyimpan, dan mengkueri data time-series. Anggap saja sebagai monitor detak jantung sistem Anda—terus-menerus mengambil metrik dari aplikasi dan infrastruktur Anda.
Loki adalah jawaban Grafana Labs untuk agregasi log dalam skala besar. Berbeda dengan solusi logging tradisional yang mengindeks seluruh konten log, Loki hanya mengindeks metadata (label), membuatnya sangat hemat biaya dan cepat. Ini seperti Prometheus, tapi untuk log—dan itulah mengapa mereka bekerja sangat baik bersama.
Keajaiban terjadi ketika Anda menggabungkan metrik dan log dengan labeling yang konsisten. Ketika alert Prometheus berbunyi karena lonjakan CPU, Anda dapat langsung melompat ke log yang sesuai di Loki menggunakan label pod, namespace, dan service yang sama. Tidak perlu lagi berpindah konteks antara tools berbeda dengan bahasa query berbeda.
Grafana berfungsi sebagai lapisan visualisasi terpadu, memungkinkan Anda membuat dashboard yang menggabungkan metrik dari Prometheus dan log dari Loki dalam tampilan yang sama.
| Aspect | Prometheus | Loki |
|---|---|---|
| Data Type | Metrik time-series | Agregasi log |
| Query Language | PromQL | LogQL |
| Storage | TSDB (lokal) | Object storage (S3/GCS) |
| Best For | Monitoring resource, alerting | Pencarian log, debugging |
Diagram di atas mengilustrasikan aliran data lengkap dari aplikasi Anda ke visualisasi. Mari kita telusuri setiap lapisan:
Instance aplikasi yang diskalakan horizontal (pod/container) berfungsi sebagai sumber data. Setiap instance mengekspos endpoint /metrics untuk Prometheus dan menulis log ke stdout/stderr untuk Loki.
Prometheus Exporter mengekspos metrik dari setiap instance aplikasi. Server Prometheus secara berkala mengambil endpoint ini, mengumpulkan penggunaan CPU, konsumsi memori, request rate, error rate, dan metrik aplikasi kustom.
Agent Promtail berjalan bersama setiap instance aplikasi (biasanya sebagai DaemonSet di Kubernetes). Mereka mengikuti file log, melampirkan label (nama pod, namespace, nama container), dan mengirimnya ke server Loki.
Prometheus menyimpan metrik dalam Time-Series Database (TSDB) bawaannya, dioptimalkan untuk query cepat dalam rentang waktu. Loki menyimpan log di object storage (S3, GCS, atau MinIO) dengan hanya indeks label, membuatnya sangat hemat biaya untuk volume log tinggi.
Grafana mengkueri kedua sumber data menggunakan PromQL untuk metrik dan LogQL untuk log, menyajikan dashboard terpadu yang menggabungkan metrik performa, stream log, dan tampilan terkorelasi untuk analisis akar masalah.
Ketika Horizontal Pod Autoscaler Anda membuat instance baru, baik Prometheus maupun Loki secara otomatis menemukannya. Prometheus menggunakan service discovery untuk menemukan endpoint /metrics baru, sementara agent Promtail (berjalan sebagai DaemonSet) secara otomatis mulai mengikuti log dari pod baru.
Di sinilah arsitektur benar-benar bersinar. Dengan menggunakan label yang konsisten (pod, namespace, service, instance) di metrik dan log, Anda dapat:
Metrik setiap pod dilacak secara individual, memungkinkan Anda mengidentifikasi outlier. Jika pod-3 mengonsumsi memori jauh lebih banyak dari saudaranya, Anda akan langsung melihatnya di dashboard dan dapat mendalami log spesifiknya.
Metrik Prometheus langsung mempengaruhi keputusan Horizontal Pod Autoscaler Kubernetes. Ketika CPU atau memori melebihi threshold, HPA menskalakan deployment Anda naik. Sepanjang waktu, Loki menangkap log dari event scaling ini, memberikan gambaran lengkap tentang apa yang terjadi.
Kunci integrasi yang mulus adalah konsistensi label. Ketika Anda melihat metrik seperti container_cpu_usage_seconds_total{pod="api-server-xyz"}, Anda dapat langsung mengkueri Loki dengan {pod="api-server-xyz"} untuk melihat apa yang dilakukan pod tersebut.
Baik Prometheus maupun Loki menggunakan timestamp yang tersinkronisasi. Ketika Anda menemukan anomali di metrik pada 14:32:15, Anda dapat mengkueri Loki untuk log dalam jendela waktu yang tepat. Grafana membuat ini trivial—cukup klik pada lonjakan dan pilih 'Show logs'.
Fitur Explore Grafana memungkinkan Anda beralih dengan mulus antara metrik dan log. Menyelidiki alert latency tinggi? Mulai dengan metrik, identifikasi rentang waktu, lalu beralih ke log dengan konteks yang dipertahankan. Alur kerja ini menghemat berjam-jam waktu debugging.
Untuk korelasi yang lebih dalam, sertakan trace ID di log Anda. Ketika Anda menemukan entri log bermasalah, Anda dapat mengikuti trace antar service, melihat metrik dan log untuk setiap hop dalam rantai request.
Skenario: Aplikasi Anda auto-scale dari 3 ke 10 pod, tapi latency meningkat alih-alih menurun. Menggunakan Prometheus, Anda mengidentifikasi pod baru memiliki waktu respons lebih tinggi. Mengkueri Loki dengan label pod spesifik mengungkapkan error database connection pool exhaustion. Akar masalah ditemukan dalam menit, bukan jam.
Skenario: Error rate naik, tapi kesehatan sistem keseluruhan terlihat baik. Dengan memecah metrik error berdasarkan label pod, Anda menemukan pod-7 memiliki error rate 40% sementara lainnya 0.1%. Log Loki menunjukkan pod ini berjalan di node dengan masalah disk I/O.
Skenario: Pelanggan melaporkan timeout intermiten. Anda membuat dashboard Grafana yang menampilkan persentil durasi request bersama error log. Korelasi mengungkapkan timeout terjadi tepat ketika API eksternal tertentu mengembalikan error 503, terlihat di metrik (request_duration_seconds) dan log ("upstream_status": 503).
Menggunakan kemampuan alerting Loki, Anda menyiapkan alert untuk pola log spesifik seperti "OutOfMemoryError" atau "connection refused". Dikombinasikan dengan alert Prometheus pada threshold resource, Anda menangkap masalah sebelum menjadi insiden yang berdampak pada pelanggan.
Gunakan label yang konsisten dan bermakna: app, service, environment, version. Hindari label high-cardinality seperti user_id atau request_id di metrik (gunakan log untuk itu). Jaga nilai label lowercase dan gunakan underscore untuk keterbacaan.
Tentukan retensi berdasarkan kebutuhan compliance dan debugging. Hot storage (log terbaru): 7-14 hari untuk akses cepat. Warm storage (log lebih lama): 30-90 hari untuk investigasi insiden. Cold storage: Arsipkan ke object storage murah untuk compliance.
Selalu filter berdasarkan label sebelum menggunakan regex di LogQL. Gunakan recording rules di Prometheus untuk agregasi yang sering digunakan. Hindari mengkueri rentang waktu panjang saat jam sibuk. Gunakan query inspector Grafana untuk memahami performa query.
Set threshold yang tepat dengan durasi 'for' yang memadai untuk menghindari flapping. Gunakan severity level (critical, warning, info) secara konsisten. Sertakan link runbook di anotasi alert. Test alert secara teratur—alert yang tidak ditest sama saja tidak ada.
scrape_configs:
- job_name: 'kubernetes-pods'
kubernetes_sd_configs:
- role: pod
relabel_configs:
- source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape]
action: keep
regex: true
- source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_path]
action: replace
target_label: __metrics_path__
regex: (.+)
- source_labels: [__meta_kubernetes_namespace]
action: replace
target_label: namespace
- source_labels: [__meta_kubernetes_pod_name]
action: replace
target_label: pod# Find error logs for a specific pod in the last hour
{namespace="production", pod="api-server-xyz"}
|= "error"
| json
| level="error"
# Count errors by service in the last 5 minutes
sum by (service) (
count_over_time(
{namespace="production"} |= "error" [5m]
)
)Mulai dengan deploy Prometheus menggunakan Helm chart kube-prometheus-stack—sudah termasuk Prometheus, Alertmanager, dan monitoring Kubernetes yang sudah dikonfigurasi. Selanjutnya, deploy Loki dan Promtail menggunakan Helm chart loki-stack. Terakhir, konfigurasi data source Grafana dan impor dashboard komunitas sebagai titik awal.
Dokumentasi resmi Prometheus dan Loki adalah titik awal yang excellent. Blog Grafana Labs secara teratur menerbitkan artikel deep-dive tentang pola observabilitas. Untuk pembelajaran hands-on, coba lingkungan Grafana Play dengan data sampel.
Mengimplementasikan Loki dan Prometheus bersama menyediakan stack observabilitas terpadu yang menskalakan dengan mulus bersama aplikasi yang diskalakan horizontal. Labeling konsisten antara metrik dan log menghilangkan perpindahan konteks dan secara dramatis mengurangi mean time to resolution (MTTR) untuk insiden.
Arsitektur yang kita bahas bukan hanya teoretis—ini sudah teruji di production environment yang menangani jutaan request per detik. Baik Anda menjalankan MVP startup atau infrastruktur kritis enterprise, pola-pola ini akan melayani Anda dengan baik.
Siap meningkatkan kemampuan observabilitas Anda? Mulai dengan deploy stack di lingkungan development dan migrasi monitoring yang ada. Diri Anda di masa depan jam 3 pagi akan berterima kasih.