Belajar Observability dengan LGTM Stack - Instrumenting Applications for Metrics

#Pendahuluan

Di episode 6 kalian mengenal Mimir dan di episode 7 kalian belajar membaca metrik dengan PromQL. Namun pertanyaan mendasar belum dijawab: dari mana metrik itu berasal? Jawabannya adalah instrumentation — proses menambahkan kode ke aplikasi agar menghasilkan pengukuran.

Episode ini membahas dua jalur instrumentasi: memakai Prometheus client library langsung dan memakai OpenTelemetry SDK for metrics. Kalian akan belajar membuat counter, gauge, dan histogram secara manual, memanfaatkan auto-instrumentation, lalu mengekspos hasilnya agar bisa di-scrape atau diekspor lewat OTLP ke Mimir.

#Instrumentation Libraries

#Dua Jalur Utama

Ada dua pendekatan yang saling melengkapi:

• Prometheus client libraries: langsung mengekspos metrik dalam format Prometheus di endpoint HTTP. Sederhana dan langsung terhubung ke Mimir via scrape.
• OpenTelemetry SDK for metrics: menghasilkan metrik dalam model OTel, lalu diekspor ke Collector. Lebih fleksibel karena satu kode bisa dikirim ke mana saja.

Pilihan bahasa tergantung tim kalian. Library resmi tersedia untuk Go, Java, Python, dan Node.js, misalnya prometheus_client untuk Python dan prometheus-client untuk Go.

pip install prometheus-client

Perintah pip install prometheus-client memasang library yang akan dipakai pada contoh di episode ini.

#Kapan Memakai Mana

Gunakan Prometheus client bila stack kalian sederhana dan Mimir menjadi satu-satunya tujuan metrik. Gunakan OpenTelemetry SDK bila kalian sudah mengadopsi OTel untuk trace dan log — satu SDK menangani semua sinyal secara konsisten.

#Manual Instrumentation

#Membuat Counter dan Gauge

Contoh paling sederhana dengan prometheus_client:

metrics.py - counter dan gauge

from prometheus_client import Counter, Gauge, Histogram, start_http_server
 
REQUESTS = Counter("http_requests_total", "Total HTTP requests", ["method"])
IN_FLIGHT = Gauge("http_requests_in_flight", "Requests sedang diproses")
LATENCY = Histogram("http_request_duration_seconds", "Latency request")
 
def handle(method):
    IN_FLIGHT.inc()
    with LATENCY.time():
        REQUESTS.labels(method=method).inc()
    IN_FLIGHT.dec()
 
start_http_server(8000)

Perhatikan pola start_http_server(8000) — ini menyalakan server HTTP kecil yang mengekspos metrik di port 8000.

#Konvensi Penamaan dan Label

• Nama metrik diakhiri _total untuk counter dan _seconds untuk durasi.
• Label hanya untuk dimensi bernilai rendah dan stabil: method, status, service. Jangan pernah memakai user_id atau trace_id sebagai label.
• Gunakan huruf kecil dan underscore, sesuai gaya Prometheus.

#Auto-Instrumentation

Menulis instrumentasi manual untuk setiap framework tidak realistis. Di sinilah auto-instrumentation membantu: library otomatis menginstrumentasi HTTP server, database client, dan message queue.

#Runtime dan HTTP Metrics

Dengan OpenTelemetry SDK, metrik runtime dan HTTP bisa diaktifkan lewat beberapa baris:

app.py - metrik runtime dan HTTP

from opentelemetry import metrics
from opentelemetry.sdk.metrics import MeterProvider
from opentelemetry.sdk.metrics.export import PeriodicExportingMetricReader
from opentelemetry.exporter.otlp.proto.grpc.metric_exporter import OTLPMetricExporter
from opentelemetry.instrumentation.system_metrics import SystemMetricsInstrumentor
 
reader = PeriodicExportingMetricReader(OTLPMetricExporter(endpoint="http://localhost:4317"))
metrics.set_meter_provider(MeterProvider(metric_readers=[reader]))
SystemMetricsInstrumentor().instrument()

Setelah menjalankan SystemMetricsInstrumentor().instrument(), metrik CPU dan memori sistem mulai diekspor setiap periode ke Collector.

#Beragam Framework

Konsep yang sama berlaku di bahasa lain: opentelemetry-instrumentation-express untuk Node.js, opentelemetry-instrumentation-jdbc untuk Java, dan opentelemetry-instrumentation-net-http untuk Go. Setiap paket menambah span dan metrik untuk framework target tanpa mengubah logika bisnis.

#Menyajikan Metrik ke Mimir

#Pull Model dengan /metrics

Prometheus dan Mimir menarik metrik dengan cara pull: secara berkala menghubungi endpoint /metrics milik aplikasi.

curl -s http://localhost:8000/metrics

Output dari curl -s http://localhost:8000/metrics berbentuk Prometheus exposition format — baris teks dengan nama metrik, label, dan nilai.

#Push Model dengan Remote Write

Jalur kedua adalah push: aplikasi atau agent mengirim data secara periodik ke endpoint remote write Mimir. Ini dipakai saat aplikasi berjalan di belakang network yang tidak bisa diakses scraper, atau saat memakai collector seperti Alloy.

url: http://mimir:9009/api/v1/push
send_interval: 15s

Mekanisme remote write lebih detail dibahas di episode 11 saat kalian memakai Grafana Alloy sebagai collector.

#Service Discovery

Saat jumlah service banyak, endpoint tidak mungkin dicatat manual. Prometheus dan Mimir memakai service discovery — misalnya label Kubernetes — untuk menemukan target scrape secara otomatis. Pendekatan ini dibahas mendalam di episode 27.

#Penutup

Di episode 8 ini kalian memahami dua jalur instrumentasi metrik: Prometheus client library dan OpenTelemetry SDK, membuat counter, gauge, dan histogram secara manual, memanfaatkan auto-instrumentation untuk runtime dan HTTP metrics, serta menyajikan metrik lewat pull maupun remote write.

Inti yang harus dibawa pulang:

• Instrumentasi adalah sumber dari semua metrik; tanpa kode, tidak ada data.
• Counter untuk kejadian, gauge untuk nilai, histogram untuk distribusi.
• Label hanya untuk dimensi rendah dan stabil.
• Auto-instrumentation menangani framework populer tanpa mengubah logika.
• Pull memakai endpoint metrics, push memakai remote write.

Di episode 9 selanjutnya kita akan membahas logs dengan Loki — arsitektur distributor, ingester, querier, dan compactor, perbedaan pendekatan index-free dengan Elasticsearch, serta format log dan strategi parsing. Metrik sudah berjalan, kini giliran log untuk melengkapi pillar kedua.