tutorial

39 Monitoring dan Tracing (Prometheus & OpenTelemetry)

“If you can’t measure it, you can’t improve it.” — Peter Drucker

Di era cloud native saat ini, sistem terdistribusi sudah menjadi makanan sehari-hari para engineer. Microservices, Kubernetes, auto-scaling, hingga CI/CD membuat sistem semakin dinamis, tetapi juga menambah kompleksitas. Bahkan masalah sederhana seperti “Mengapa layanan saya lambat?” bisa berubah menjadi petualangan debugging yang penuh misteri.

Monitoring dan tracing adalah dua alat utama yang benar-benar krusial dalam memastikan aplikasi kamu tetap sehat, scalable, dan reliable. Pada artikel ini, saya ingin berbagi bagaimana Prometheus dan OpenTelemetry bisa menjadi backbone solution untuk monitoring dan tracing modern, dilengkapi dengan kode riil, simulasi, dan best practice.


1. Monitoring vs. Tracing: Apa Bedanya?

Monitoring adalah proses pengumpulan, analisa, dan visualisasi metrics dari sistem—seperti CPU, memory, latency, error rate dsb. Tujuannya supaya kita tahu ada sesuatu yang tidak beres, bisa cepat bertindak, dan melihat trend performa.

Tracing adalah proses pelacakan flow eksekusi permintaan, biasanya dari satu layanan ke layanan lain secara end-to-end. Ini sangat powerful untuk mencari bottleneck maupun debugging distributed systems.

Monitoring (Prometheus)Tracing (OpenTelemetry)
DataMetrics (angka: counter, gauge)Traces (event, span, context)
TujuanAlert & observabilityRoot cause analysis
ModeTerus-menerus (periodik)On demand (per request/event)
OutputGrafana dashboard, AlertmanagerJaeger, Zipkin UI, log detail


2. Prometheus: Monitoring Canggih, Open Source

Prometheus adalah tools yang sangat populer untuk monitoring time-series metrics. Ia “menarik” (pull) data dari aplikasi kamu secara periodik, lalu menyimpannya untuk visualization atau alerting.

2.1 Arsitektur Prometheus (Sederhana)

flowchart LR
    subgraph A[Application]
        Svc1[Microservice 1] -->|Exposes /metrics| M[Prometheus]
        Svc2[Microservice 2] -->|Exposes /metrics| M
    end
    M -->|Time series| Storage[(Prometheus TSDB)]
    M -->|Monitoring| Grafana
    M -->|Alert| Alertmanager
  1. Application: Setiap microservice expose endpoint /metrics (format: Prometheus exposition format).
  2. Prometheus Server: Regularly scrape endpoint ini dan menyimpan metrics.
  3. Visualization & Alerts: Data bisa dipakai oleh Grafana/dashboard lain, atau di-trigger via Alertmanager ketika terjadi anomaly.

2.2 Example Kode: Ekspos Metrics di Go

Misal kita punya layanan order sederhana.

package main

import (
    "net/http"
    "github.com/prometheus/client_golang/prometheus"
    "github.com/prometheus/client_golang/prometheus/promhttp"
)

var (
    orderCounter = prometheus.NewCounter(prometheus.CounterOpts{
        Name: "order_created_total",
        Help: "Jumlah order yang berhasil dibuat",
    })
)

func init() {
    prometheus.MustRegister(orderCounter)
}

func orderHandler(w http.ResponseWriter, r *http.Request) {
    // some order logic...
    orderCounter.Inc()
    w.WriteHeader(http.StatusOK)
}

func main() {
    http.Handle("/metrics", promhttp.Handler())
    http.HandleFunc("/order", orderHandler)
    http.ListenAndServe(":8080", nil)
}

Penjelasan:

  • Ketika endpoint /order dihit, counter order_created_total akan naik.
  • Prometheus cukup mengkonfigurasi scrape: <host>:8080/metrics.

3. OpenTelemetry: Standar Baru Distributed Tracing

Tracing end-to-end pada microservices tidak bisa diandalkan hanya lewat log standar. OpenTelemetry (OTel) hadir sebagai toolkit vendor-neutral untuk tracing, metrics, dan logs. Ia jadi “standar de facto” sejak bergabungnya proyek OpenTracing & OpenCensus.

3.1 Arsitektur OpenTelemetry

flowchart TD
    UserReq(User Request)
    A[Service A] -->|span context| B[Service B]
    B -->|span context| C[Service C]
    A --> OTEL(OTel Collector)
    B --> OTEL
    C --> OTEL
    OTEL --> Jaeger
  1. Setiap service mendefinisikan span dan meneruskan context ke service selanjutnya.
  2. OpenTelemetry Collector adalah agent yang ngumpulin, memproses, lalu menyalurkan tracing data ke backend (Jaeger, Zipkin, dsb).

3.2 Eksplorasi Kode: Implementasi Tracing di Go

Install depedensi:

go get go.opentelemetry.io/otel
go get go.opentelemetry.io/otel/sdk
go get go.opentelemetry.io/otel/exporters/jaeger

Potongan kode:

import (
    "context"
    "go.opentelemetry.io/otel"
    "go.opentelemetry.io/otel/trace"
)

func processOrder(ctx context.Context) {
    tracer := otel.Tracer("order-service")
    ctx, span := tracer.Start(ctx, "ProcessOrder")
    defer span.End()

    // ... some process ...
    inventoryCheck(ctx)
}

func inventoryCheck(ctx context.Context) {
    tracer := otel.Tracer("order-service")
    _, span := tracer.Start(ctx, "InventoryCheck")
    defer span.End()

    // ... some inventory call ...
}

Pada dasarnya, setiap request/request handler membentuk hirarki span (parent-child). Ini yang kemudian divisualisasikan jadi diagram trace (waterfall) di Jaeger.


4. Simulasi: Mengamati Sistem dari Dua Sisi

Kita ingin menjawab pertanyaan: “Seberapa cepat order diproses? Bila lambat, bottleneck-nya di mana?”

  1. Dengan Prometheus, kita bisa melihat rate order masuk, error rate, hingga duration prosess lewat metrics seperti histogram:
    • order_created_total, order_error_total, order_processing_seconds_bucket
  2. Dengan OpenTelemetry, kita bisa lihat breakdown waktu setiap handler, service-to-service call, hingga root cause slow request.

5. Membandingkan Penggunaan: Kapan Pakai yang Mana?

SkenarioMonitoring (Prometheus)Tracing (OpenTelemetry)
Rata-rata permintaan/order per menit✅ (grafik time-series)✖️
Lonjakan error di hari Senin✅ (alert + metric)✖️
Tahu request lambat, kenapa?✖️✅ (bisa lihat span breakdown)
Analisa akar masalah error specfic✖️
Budget RAM/CPU tiap service✖️

Takeaway:

  • Gunakan Prometheus untuk kesehatan sistem secara makro dan alert.
  • Gunakan OpenTelemetry/Tracing untuk root-cause analysis permintaan individual.

6. Integrasi dan Saran Best Practice

  • Selalu monitor basic service metrics (rate, error rate, latency).
  • Tambahkan tracing pada jalur kritikal (transaksi, auth, dsb).
  • Integrasikan log, metric, dan trace agar troubleshooting makin cepat. Banyak tool modern (Grafana, Tempo/Jaeger) sudah support correlation ID.
  • Test load secara periodik dan validasi apakah trace bisa menangkan “bottleneck” sebenarnya, bukan hanya noise.

7. Penutup

Monitoring dan tracing bukan hanya alat debugging, tapi alat perekam kesehatan bisnis modern. Di observabilitas era cloud native, Prometheus dan OpenTelemetry adalah pondasi, bukan fitur tambahan.

Mulailah pasang sekarang, sebelum kamu butuh. Begitu insiden saat production, kamu akan bersyukur sudah investasi di observabilitas sejak awal!


Referensi

Semoga insight observabilitasmu bertambah tajam dan troubleshooting makin produktif 🎯


comments powered by Disqus