Metrics #
Metrics adalah pengukuran numerik yang dikumpulkan secara berkala untuk menggambarkan kondisi sistem dari waktu ke waktu. Berbeda dengan log yang mencatat peristiwa individual, metrics memberi gambaran agregat — berapa banyak request per detik, berapa persen CPU yang terpakai, berapa milidetik rata-rata latensi. Metrics adalah cara tercepat untuk mengetahui apakah ada masalah, sebelum kamu menggali log untuk mengetahui apa masalahnya. Dashboard metrics yang baik adalah pandangan pertama yang kamu buka setiap pagi dan yang pertama dilihat saat menerima alert.
Metrics vs Log — Dua Alat yang Berbeda #
Log menjawab: "Apa yang terjadi?"
→ Peristiwa individual yang discrete
→ "User 12345 gagal login karena wrong password pada 10:23:45"
→ Detail tinggi, volume tinggi, biaya tinggi untuk query
Metrics menjawab: "Seberapa baik sistem berjalan?"
→ Agregat numerik dari waktu ke waktu
→ "500 login attempt per menit, 12% diantaranya gagal"
→ Query cepat, visualisasi mudah, biaya relatif rendah
Keduanya dibutuhkan:
Dashboard metrics: ada spike error rate → ada masalah (DETEKSI)
Log search: query log untuk cari error tersebut → tahu apa masalahnya (INVESTIGASI)
Jenis Metrik #
Counter — Hanya Naik #
Counter adalah metrik yang hanya bisa bertambah.
Ia menghitung berapa kali sesuatu terjadi secara kumulatif.
Contoh Counter:
http_requests_total ← total request sejak service start
http_errors_total ← total error sejak service start
payment_processed_total ← total transaksi berhasil
user_registered_total ← total user yang mendaftar
Cara menggunakan Counter:
Nilai absolut counter kurang berguna (terus naik sejak awal)
Yang berguna: RATE perubahan counter
http_requests_total meningkat 3000 dalam 1 menit
→ Request rate: 3000 / 60 = 50 request/detik
Visualisasi: selalu tampilkan sebagai rate (per detik/menit)
bukan nilai absolut kumulatif
Gauge — Naik dan Turun #
Gauge adalah metrik yang bisa naik maupun turun.
Ia merepresentasikan nilai pada saat tertentu.
Contoh Gauge:
cpu_utilization_percent ← 0-100%, berfluktuasi
memory_used_bytes ← naik turun seiring alokasi
active_connections ← berapa koneksi aktif saat ini
queue_depth ← berapa item dalam antrian
temperature_celsius ← nilai sensor saat ini
Cara menggunakan Gauge:
Nilai saat ini langsung bermakna
active_connections = 450 → mendekati limit? ada masalah?
queue_depth = 10.000 → antrian menumpuk, worker tidak cukup?
Visualisasi: tampilkan nilai saat ini dan tren waktu
Histogram — Distribusi Nilai #
Histogram mengukur distribusi nilai observasi.
Paling berguna untuk mengukur latensi dan ukuran request.
Contoh penggunaan Histogram:
http_request_duration_seconds ← berapa lama setiap request
response_size_bytes ← berapa besar setiap response
Histogram menyimpan:
→ Jumlah observasi per "bucket" (range nilai)
→ Total nilai semua observasi (untuk hitung rata-rata)
→ Total jumlah observasi
Dari histogram, kamu bisa hitung:
→ P50 (median): 50% request selesai dalam X ms
→ P95: 95% request selesai dalam Y ms
→ P99: 99% request selesai dalam Z ms
→ Average (rata-rata): total_time / total_requests
Mengapa Percentile lebih baik dari Average:
100 request dengan durasi (ms):
95 request: 50ms
4 request: 200ms
1 request: 5000ms (timeout atau masalah)
Average: (95×50 + 4×200 + 1×5000) / 100 = 99.5ms
→ Average terlihat "normal"
P95: 200ms → 5% user mengalami ini
P99: 5000ms → 1% user mengalami ini (ada masalah serius!)
Average menyembunyikan masalah di ekor distribusi.
Percentile (terutama P95 dan P99) mengungkapnya.
The Four Golden Signals #
Google SRE Book memperkenalkan “Four Golden Signals” — empat metrik yang paling penting untuk dipantau pada hampir semua layanan.
1. Latency — Berapa lama melayani request?
→ Waktu dari request masuk hingga response keluar
→ Ukur: P50, P95, P99 (bukan hanya average)
→ Pisahkan: latency request sukses vs request gagal
(error yang cepat bisa membuat latency terlihat rendah
padahal sistem bermasalah)
2. Traffic — Seberapa banyak demand pada sistem?
→ Request per detik, transaksi per menit, byte per detik
→ Baseline traffic yang normal membantu deteksi anomali
→ Kenaikan trafik tiba-tiba = mungkin DDoS atau viral event
3. Errors — Berapa banyak request yang gagal?
→ Error rate: errors / total_requests × 100%
→ Pisahkan jenis error: 4xx (client error) vs 5xx (server error)
→ Juga: error yang "silent" — response 200 tapi data salah
(perlu custom business metric untuk ini)
4. Saturation — Seberapa penuh resource sistem?
→ CPU utilization, memory usage, disk I/O, connection pool usage
→ Mengukur seberapa dekat sistem ke batas kapasitasnya
→ Saturation tinggi = akan ada masalah jika beban naik sedikit lagi
→ Prediktif: bisa deteksi masalah sebelum terjadi
RED Method dan USE Method #
Dua framework lain yang berguna untuk mendefinisikan metrik berdasarkan konteks.
RED Method (untuk service/microservice):
R — Rate: berapa banyak request per detik?
E — Errors: berapa banyak request yang gagal?
D — Duration: berapa lama setiap request?
Sangat cocok untuk: API server, microservice, user-facing service
Tiga metrik ini cukup untuk gambaran kesehatan service secara umum
USE Method (untuk resource/infrastruktur):
U — Utilization: berapa persen resource terpakai? (CPU 70%)
S — Saturation: seberapa banyak pekerjaan yang menunggu?
(request queue depth, I/O wait)
E — Errors: berapa error pada resource tersebut?
Sangat cocok untuk: CPU, memory, disk, network interface, database
Membantu menemukan resource yang menjadi bottleneck
Custom Business Metrics #
Di luar metrik teknis (CPU, latency, error rate), metrik bisnis yang mencerminkan outcome nyata seringkali lebih bermakna untuk mendeteksi masalah.
Contoh Custom Business Metrics:
E-commerce:
→ orders_placed_per_minute ← drop tiba-tiba = ada masalah?
→ payment_success_rate ← turun = payment gateway bermasalah?
→ cart_abandonment_rate ← naik = UX bermasalah?
→ revenue_per_minute ← turun = ada insiden bisnis
Aplikasi B2B:
→ api_calls_per_tenant ← anomali per tenant
→ active_users_per_hour ← drop = ada masalah login?
→ sync_jobs_completed ← gagal = data tidak tersinkronisasi
Mengapa ini penting:
Sistem teknis bisa terlihat "sehat" (CPU rendah, error rate rendah)
tapi ada bug yang menyebabkan order tidak tersimpan ke database.
Technical metrics tidak akan mendeteksi ini.
orders_placed_per_minute yang drop dari 100 ke 0 langsung terlihat.
Instrumentasi Aplikasi #
Cara menambahkan metrik ke aplikasi:
Gunakan library client sesuai bahasa:
→ Prometheus client (Python, Go, Java, Ruby, Node.js)
→ OpenTelemetry SDK (multi-bahasa, vendor-agnostic)
→ Cloud provider SDK
Contoh instrumentasi (pseudocode):
# Counter: hitung request
REQUEST_COUNTER = Counter(
name="http_requests_total",
labels=["method", "path", "status_code"]
)
# Histogram: ukur durasi
REQUEST_DURATION = Histogram(
name="http_request_duration_seconds",
buckets=[0.01, 0.05, 0.1, 0.25, 0.5, 1.0, 2.5, 5.0]
)
def handle_request(method, path):
start = time.now()
try:
response = process_request()
REQUEST_COUNTER.inc(method=method, path=path, status_code=200)
return response
except Exception as e:
REQUEST_COUNTER.inc(method=method, path=path, status_code=500)
raise
finally:
duration = time.now() - start
REQUEST_DURATION.observe(duration, method=method, path=path)
Ringkasan #
- Metrics mengukur kondisi agregat sistem dari waktu ke waktu — bukan peristiwa individual seperti log, tapi gambaran kesehatan sistem secara keseluruhan.
- Tiga jenis metrik utama: counter (hanya naik), gauge (naik turun), histogram (distribusi) — pilih yang sesuai dengan apa yang diukur.
- Percentile (P95, P99) lebih informatif dari average untuk latensi — average menyembunyikan masalah di ekor distribusi; P99 mengungkapnya.
- Four Golden Signals: latency, traffic, errors, saturation — empat metrik ini cukup untuk gambaran umum kesehatan hampir semua layanan.
- Custom business metrics mendeteksi masalah yang technical metrics lewatkan — orders_placed_per_minute yang drop adalah sinyal yang tidak bisa dilihat dari CPU utilization.
- OpenTelemetry untuk instrumentasi yang vendor-agnostic — satu SDK yang bisa dikirim ke backend mana pun (Prometheus, Datadog, Grafana, dll).