Observability untuk DevOps — Logs, Metrics, Traces, dan lainnya

Dalam praktik DevOps modern, observability bukan lagi fitur tambahan—melainkan fondasi. Tapi observability bukan sekadar menambahkan library logging atau membuka dashboard Grafana. Ini soal memahami sistem dari dalam, bahkan ketika terjadi masalah yang kompleks.

Artikel ini membahas pendekatan praktis membangun observability yang efektif menggunakan tools seperti Prometheus, Grafana, Loki, Tempo, OpenTelemetry, dan ELK Stack.

Apa Itu Observability (dan Apa Bukan)

Observability ≠ Monitoring.

• Monitoring memberi tahu bahwa ada masalah.
• Observability menjelaskan kenapa masalah itu terjadi.

Sistem yang observable memungkinkan kamu:

• Mengajukan pertanyaan baru tanpa deploy ulang
• Debug across microservice dan async jobs
• Ukur SLO, deteksi anomali, dan trace dependencies

Tiga Pilar Observability

1. Logs — Cerita dari Sistem

Logs memberitahu apa yang terjadi.

✅ Gunakan structured logging (JSON):

{
  "timestamp": "2025-06-23T09:34:56Z",
  "level": "error",
  "message": "Koneksi ke DB gagal",
  "context": {
    "user_id": 42,
    "retry_count": 3
  }
}

Gunakan stack log terpusat:

• ELK Stack
• Grafana Loki (efisien untuk Kubernetes)

Index log berdasarkan:

• Nama service
• Environment (dev/staging/prod)
• Correlation ID (untuk trace)

2. Metrics — Detak Infrastruktur

Metrics menunjukkan insight kuantitatif:

Gunakan Prometheus:

# Scraping metrics dari Pod Kubernetes
- job_name: 'kubernetes-pods'
  kubernetes_sd_configs:
    - role: pod
  relabel_configs:
    - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape]
      action: keep
      regex: true

Contoh:

• Request per second (RPS)
• CPU/mem usage
• Queue length
• Error rate, latency

Alert via Grafana:

alert: TingkatErrorTinggi
expr: rate(http_requests_total{status=~"5.."}[5m]) > 0.05
for: 2m
labels:
  severity: critical
annotations:
  summary: "Error rate tinggi di production"

3. Traces — Perjalanan Request

Traces menunjukkan alur request antar service.

Gunakan OpenTelemetry SDK:

npm install @opentelemetry/sdk-node

Contoh:

import { NodeSDK } from '@opentelemetry/sdk-node';
const sdk = new NodeSDK({
  serviceName: 'auth-service',
  traceExporter: new OTLPTraceExporter({ url: 'http://tempo:4317' }),
});
sdk.start();

Backend tracing:

• Tempo (untuk Grafana)
• Jaeger
• Datadog / Honeycomb (komersial)

Gunakan Correlation ID untuk hubungkan logs, metrics, dan traces.

Di Luar Pilar: Events & Profiling

• Event timeline (deploy, config changes) bantu konteks
• Continuous profiling (Pyroscope, Parca) tunjukkan penggunaan CPU/mem tiap waktu

🔍 Sangat berguna untuk deteksi bottleneck atau memory leak yang tidak tampak di metric biasa.

Contoh Stack Observability

Stack OSS:

• Prometheus (metrics)
• Loki (logs)
• Tempo (tracing)
• Grafana (dashboard & alert)

Arsitektur:

[ App ]
   │
   ├─> OpenTelemetry SDK → Tempo (trace)
   ├─> Log terstruktur → Loki
   └─> Exporter Prometheus → Prometheus
                               ↘ Grafana

Contoh Alert:

• CPU > 85% selama 5 menit
• Latency P95 > 1s
• Error rate > 5%
• Heartbeat hilang (service mati)

Best Practice

• Gunakan request ID unik di semua log
• Standarkan label (env, service, region)
• Alert berbasis SLO bukan hanya metric mentah
• Dashboard harus menyampaikan konteks, bukan hanya grafik
• Backup log jangka panjang ke S3/GCS
• Routing alert otomatis (PagerDuty, Slack, Email)

Kesimpulan

Observability bukan tentang tools, tapi soal kemampuan DevOps untuk melihat sistem sebagai ekosistem hidup. Dengan stack yang tepat dan kebiasaan yang disiplin, kamu bisa menjawab pertanyaan paling sulit saat sistem sedang bermasalah.

Kamu sudah pakai observability stack di proyekmu? Cerita pengalamanmu yuk di LinkedIn.

🔗 Baca Juga

• DevSecOps dalam Praktik — Menggeser Keamanan ke Kiri dalam Pipeline CI/CD