Belajar OpenTelemetry - Data Correlation: Metrics + Logs + Traces

#Pendahuluan

Tiga sinyal sudah kalian kuasai secara terpisah: traces (episode 4), metrics (5), dan logs (6). Episode 17 menyatukannya — karena kekuatan observability bukan pada masing-masing pilar, melainkan pada kemampuan berpindah antar-pilar tanpa pindah konteks. Inilah yang dipanggil data correlation.

Mengapa penting? Workflow insiden yang sesungguhnya adalah: alert metrics berbunyi → buka trace yang paling relevan → masuk ke log pada titik kegagalan → temukan root cause. Setiap perpindahan itu butuh data yang saling tertaut. Tanpa korelasi, kalian pindah antar-tool dengan menyalin-menempel ID secara manual — dan di tengah insiden, itu waktu yang mahal.

#Tiga Pilar, Satu Identitas

Jembatan korelasi yang menyatukan tiga pilar adalah trace_id:

• Metrics membawa exemplar — satu sampel per bucket histogram yang menunjuk ke trace_id nyata.
• Logs membawa trace_id/span_id dari konteks span aktif (episode 6).
• Traces adalah kumpulan span yang dimiliki trace_id itu.

Perhatikan arah alur: metrics menunjuk ke trace (lewat exemplar), logs menyediakan detail (lewat trace_id di record). Backend yang baik membuat perpindahan ini satu klik.

#Metrics Exemplar

Exemplar adalah mekanisme yang membuat histogram tidak hanya "tinggi" tetapi juga "kenapa". Untuk bucket tertentu, SDK menyimpan satu contoh pengukuran asli beserta atribut dan trace_id-nya:

latency = meter.create_histogram("http.server.request.duration", unit="s")
 
def handler(ctx, duration_s):
    # Exemplar secara otomatis mengikat pengukuran ke trace_id span aktif
    latency.record(duration_s, {"http.route": "/checkout"})

Saat memeriksa histogram di backend, exemplar memperlihatkan contoh request nyata (dengan trace_id) yang masuk ke bucket tertentu — biasanya bucket lambat atau bucket error. Dari situ kalian langsung lompat ke trace.

#Workflow SRE: Alert → Trace → Log

Alur investigasi modern yang efisien adalah rantai korelasi:

1. Alert — Prometheus/Grafana mendeteksi error rate naik (metric).
2. Trace — dari exemplar, buka trace yang menunjukkan request gagal; identifikasi span mana yang gagal dan berapa lama.
3. Log — filter log dengan trace_id span tersebut; baca pesan error persis di titik kegagalan.

groups:
  - name: http
    rules:
      - alert: HighErrorRate
        expr: rate(http_server_request_count_total{status="5xx"}[5m]) > 0.05
        annotations:
          summary: "Error rate > 5%"

Setiap langkah hanya butuh satu klik di backend yang terintegrasi (Grafana + Tempo + Loki, atau Jaeger + log index). Inilah alasan industri bergeser ke stack observability yang memakai identitas bersama.

#Satu Pipeline OTLP untuk Tiga Sinyal

Keindahan arsitektur OTel: ketiga sinyal melewati pipeline yang sama dan bisa diteruskan ke satu set backend. Tambahkan backend logs (Loki) ke stack kalian:

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318
 
processors:
  memory_limiter:
    check_interval: 1s
    limit_mib: 512
  batch:
    timeout: 2s
 
exporters:
  otlp/tempo:
    endpoint: tempo:4317
    tls:
      insecure: true
  prometheus:
    endpoint: 0.0.0.0:8889
    namespace: otel
  otlp/loki:
    endpoint: loki:4317
    tls:
      insecure: true
 
service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [memory_limiter, batch]
      exporters: [otlp/tempo]
    metrics:
      receivers: [otlp]
      processors: [memory_limiter, batch]
      exporters: [prometheus]
    logs:
      receivers: [otlp]
      processors: [memory_limiter, batch]
      exporters: [otlp/loki]

Arsitektur di atas adalah versi ringkas dari Grafana LGTM stack (Loki + Grafana + Tempo + Mimir) yang menerima OTel secara native — satu collector mengisi tiga backend berbeda dengan satu koneksi dari SDK.

#Mengenali Korelasi Rusak

Gejala data yang tidak berkorelasi, dan penyebabnya:

#Common Pitfalls

• Mengharapkan exemplar selalu ada — exemplar adalah sampel; gunakan untuk membuka investigasi, bukan statistik.
• Alerting tanpa path ke trace — alert yang hanya menampilkan angka membuat investigasi harus mulai dari nol.
• Log tanpa trace_id di async task — korelasi putus di tengah trace; pertahankan konteks di async boundaries.
• Nama service tidak konsisten antar sinyal — korelasi otomatis backend gagal diam-diam.

#Penutup

Pada episode 17 ini, kalian telah menyatukan tiga pilar observability.

Inti yang harus dibawa pulang:

• trace_id adalah jembatan korelasi: exemplar menghubungkan metrics→trace, log record membawa trace ke detail.
• Workflow SRE: alert → trace → log — setiap perpindahan satu klik di backend terintegrasi.
• Satu pipeline OTLP bisa mengisi Grafana LGTM (Tempo + Prometheus/Mimir + Loki) sekaligus.
• Korelasi rusak = investigasi lambat; periksa konsistensi service.name dan propagasi konteks.

Di episode 18 selanjutnya, kita masuk Fase 5 dan membahas Kubernetes: Helm, DaemonSet & OTel K8s Operator — install collector lewat Helm chart, mode daemonset vs deployment, enrichment atribut K8s, serta auto-instrumentasi dengan OpenTelemetry Operator. Sampai jumpa di episode 18!