Metrics #

Dalam menjaga keandalan sistem berskala besar di cloud, kita harus memiliki metrik kuantitatif untuk mengukur status kesehatan infrastruktur dan aplikasi secara terus-menerus. Metrics adalah kumpulan pengukuran numerik yang dikumpulkan secara berkala (misal setiap 10 atau 15 detik) untuk merepresentasikan kondisi sistem dari waktu ke waktu. Berbeda dengan log yang bertugas mencatat rincian peristiwa individual secara diskrit, metrik menyajikan data agregasi statistik — seperti berapa banyak request HTTP yang masuk per detik, berapa persen beban utilisasi CPU rata-rata, atau berapa milidetik latensi respon aplikasi kita. Metrik adalah indikator tercepat dan paling efisien untuk mendeteksi apakah terjadi masalah pada sistem (detection), sebelum akhirnya kita menyelami file log atau runut tracing untuk mengidentifikasi apa penyebab masalah tersebut (investigation). Artikel ini akan membahas perbedaan metrik dengan log, klasifikasi jenis metrik, framework monitoring Google SRE, serta instrumentasi kode menggunakan standar industri OpenTelemetry.

Perbedaan Fundamental: Metrics vs Logging #

Meskipun metrik dan log adalah pilar observabilitas, keduanya dirancang untuk memecahkan dua masalah yang berbeda:

1. Logging (“Mencari Detail Jarum dalam Tumpukan Jerami”) #

Log mencatat riwayat peristiwa individual secara detail.

• Kelebihan: Rincian informasi sangat tinggi (stack trace, detail payload request).
• Keterbatasan: Mengonsumsi ruang penyimpanan yang sangat besar dan memakan biaya komputasi yang tinggi untuk di-query saat beban trafik padat.

2. Metrics (“Memantau Ketinggian Air Sungai Secara Real-time”) #

Metrik mengabaikan detail individual dan hanya fokus pada angka agregat numerik yang ringan.

• Kelebihan: Konsumsi penyimpanan sangat kecil, pemrosesan query sangat cepat, dan sangat mudah divisualisasikan dalam bentuk grafik tren di dashboard.
• Kombinasi Sinergis: Dashboard metrik memicu alarm (Alert) saat mendeteksi lonjakan error rate melampaui batas aman, kemudian engineer menggunakan Trace ID dari metrik tersebut untuk mencari baris log spesifik guna melakukan perbaikan.

Tabel Komparasi Metrik vs Log #

Jenis-Jenis Tipe Data Metrik #

Untuk merepresentasikan berbagai kondisi sistem, kita menggunakan tiga tipe data metrik utama yang disepakati oleh standar Prometheus dan OpenTelemetry:

1. Counter (Metrik Akumulatif) #

Counter adalah tipe data metrik yang nilainya hanya bisa bertambah (naik) atau kembali ke angka nol (reset) saat aplikasi dijalankan ulang (reboot). Counter tidak pernah bergerak turun.

• Penggunaan: Menghitung jumlah total request HTTP (http_requests_total), jumlah total error (http_errors_total), atau jumlah transaksi sukses.
• Rate Calculation: Nilai absolut dari counter tidak terlalu berguna di dashboard. Yang kita butuhkan adalah menghitung laju perubahan nilai (rate of change) counter tersebut dalam satuan waktu tertentu: $$\text{RPS (Request Per Second)} = \frac{\Delta\text{Counter}}{\Delta t}$$

2. Gauge (Metrik Fluktuatif) #

Gauge adalah tipe data metrik yang nilainya dapat naik maupun turun secara bebas untuk merepresentasikan kondisi instan pada satu waktu tertentu.

• Penggunaan: Mengukur suhu CPU (cpu_temperature), penggunaan memori dalam byte (memory_used_bytes), jumlah koneksi aktif database, atau panjang antrean pesan (queue depth).

Visualisasi Karakteristik Nilai Metrik:

Counter (Hanya Naik):
   100  │                                    ┌───
    80  │                            ┌───────┘
    60  │                    ┌───────┘
    40  │            ┌───────┘
    20  │    ┌───────┘
        └─────────────────────────────────────────> Waktu

Gauge (Bisa Naik & Turun):
   100  │            ┌──┐
    80  │    ┌───────┘  │            ┌──┐
    60  │    │          └────┐       │  └──────┐
    40  │────┘               └───────┘         │
    20  │                                      └──
        └─────────────────────────────────────────> Waktu

3. Histogram (Distribusi Nilai & Persentil) #

Histogram digunakan untuk mengukur frekuensi penyebaran durasi atau ukuran data ke dalam kelompok batas (buckets) yang telah ditentukan. Histogram sangat krusial untuk mengukur latensi respon aplikasi.

flowchart TD
    Request["Request Latency (e.g., 120ms)"] --> BucketCheck{"Evaluasi Buckets"}
    BucketCheck -->|"< 50ms"| B1["Bucket: le_50 (Count +0)"]
    BucketCheck -->|"< 100ms"| B2["Bucket: le_100 (Count +0)"]
    BucketCheck -->|"< 250ms"| B3["Bucket: le_250 (Count +1)"]
    BucketCheck -->|"< 500ms"| B4["Bucket: le_500 (Count +1)"]

Bahaya Menjebak Rata-Rata (The Average Latency Trap) #

Menggunakan nilai rata-rata (average/mean) untuk mengukur latensi aplikasi adalah kesalahan fatal yang sering menyembunyikan masalah di ekor distribusi.

• Skenario: Kita menerima 100 request:
  • 95 request selesai sangat cepat dalam waktu 50ms.
  • 4 request selesai dalam waktu 200ms.
  • 1 request mengalami bottleneck dan selesai dalam waktu 5.000ms (5 detik).
• Perhitungan Rata-rata: $$\text{Rata-rata} = \frac{(95 \times 50) + (4 \times 200) + 5000}{100} = 105.5\text{ ms}$$ Grafik rata-rata 105.5ms terlihat sangat aman dan sehat di dashboard kita. Namun, dalam kenyataannya, 1% dari pengguna kita mengalami kelambatan ekstrem selama 5 detik!
• Solusi (Percentile):
  • P50 (Median): 50% request selesai di bawah 50ms.
  • P95: 95% request selesai di bawah 50ms.
  • P99: 99% request selesai di bawah 5.000ms. Dengan memantau metrik P99, lonjakan latensi ekstrem 5 detik pada ekor distribusi akan langsung terdeteksi di dashboard.

Framework Pemantauan: Four Golden Signals, RED, dan USE #

Untuk mempermudah kita mendesain dashboard yang bermakna tanpa kebanjiran informasi (information overload), kita dapat mengadopsi tiga framework standar industri berikut:

1. Four Golden Signals (Google SRE Book) #

• Latency (Latensi): Waktu yang dibutuhkan untuk menyelesaikan request. Kita wajib memisahkan latensi request sukses dengan request gagal.
• Traffic (Trafik): Mengukur seberapa besar beban permintaan pada sistem (misal: RPS, transaksi per menit).
• Errors (Kesalahan): Rasio kegagalan dari request yang masuk (misal: jumlah HTTP 5xx dibagi total request).
• Saturation (Kejenuhan): Mengukur seberapa penuh kapasitas sumber daya kita (misal: utilisasi CPU, sisa ruang memori, limit thread pool).

2. RED Method (Orientasi pada Layanan / Microservices) #

Sangat cocok untuk memantau performa aplikasi API stateless:

• Rate: Jumlah request per detik yang diterima.
• Errors: Jumlah request yang gagal memicu error.
• Duration: Durasi waktu respon latensi.

3. USE Method (Orientasi pada Infrastruktur / Hardware) #

Sangat cocok untuk memantau kesehatan hardware server, database, atau disk volume:

• Utilization: Persentase kapasitas resource yang sedang aktif digunakan (misal: CPU terpakai 75%).
• Saturation: Jumlah antrean pekerjaan yang menunggu resource tersebut kosong (misal: disk queue length atau I/O wait).
• Errors: Jumlah kegagalan atau error yang dilaporkan oleh hardware tersebut.

Custom Business Metrics (Metrik Bisnis Kustom) #

Metrik teknis (seperti CPU dan RAM) terkadang dapat menipu kita. Ada kalanya server web melaporkan utilisasi CPU yang sangat rendah (10%) dan error rate 0% (sehat), namun ternyata aplikasi kita sedang mengalami bug logis di mana tombol checkout e-commerce tidak bisa diklik sehingga tidak ada satu pun transaksi yang masuk ke database.

Menerapkan Custom Business Metrics adalah satu-satunya cara mendeteksi anomali logis ini secara real-time:

• E-commerce: orders_placed_per_minute (Jika angka ini mendadak drop dari rata-rata 50 order per menit menjadi 0, alarm sistem harus segera berbunyi meskipun utilisasi server web sehat).
• Fintech: payment_gateway_success_ratio (Mendeteksi kegagalan API bank sebelum bank memberikan pengumuman resmi).
• SaaS: active_user_connections_per_hour (Mendeteksi masalah login global).

Instrumentasi Aplikasi Menggunakan OpenTelemetry #

OpenTelemetry (OTel) adalah standar open-source yang didukung oleh CNCF untuk mengumpulkan metrik, log, dan trace secara agnostik (vendor-neutral). Dengan menulis kode instrumen menggunakan OpenTelemetry SDK, kita bebas mengirimkan metrik aplikasi kita ke backend monitoring mana pun (seperti Prometheus, Datadog, Grafana Loki, atau Dynatrace) tanpa perlu mengubah kode aplikasi kembali.

Berikut adalah contoh lengkap instrumentasi metrik menggunakan bahasa Go untuk mencatat request counter dan latensi histogram:

// Contoh instrumentasi metrik HTTP server di Go menggunakan OpenTelemetry SDK (BENAR)
package main

import (
	"context"
	"net/http"
	"time"

	"go.opentelemetry.io/otel"
	"go.opentelemetry.io/otel/attribute"
	"go.opentelemetry.io/otel/metric"
)

var (
	meter          = otel.Meter("http-server-meter")
	requestCounter metric.Int64Counter
	requestLatency metric.Float64Histogram
)

func initMetrics() {
	var err error
	// Inisialisasi Counter
	requestCounter, err = meter.Int64Counter("http_requests_total",
		metric.WithDescription("Total jumlah HTTP requests yang masuk ke server"),
	)
	if err != nil {
		panic(err)
	}

	// Inisialisasi Histogram untuk mengukur durasi latensi
	requestLatency, err = meter.Float64Histogram("http_request_duration_seconds",
		metric.WithDescription("Distribusi durasi HTTP request dalam detik"),
		metric.WithExplicitBucketBoundaries(0.005, 0.01, 0.025, 0.05, 0.1, 0.25, 0.5, 1.0, 2.5, 5.0),
	)
	if err != nil {
		panic(err)
	}
}

func httpHandler(w http.ResponseWriter, r *http.Request) {
	startTime := time.Now()
	ctx := context.Background()

	// Definisikan atribut label untuk korelasi query
	attrs := []attribute.KeyValue{
		attribute.String("method", r.Method),
		attribute.String("path", r.URL.Path),
	}

	// Simulasi pemrosesan request
	w.WriteHeader(http.StatusOK)
	w.Write([]byte("Metrics Recorded!"))

	// 1. Tambah nilai counter (+1)
	requestCounter.Add(ctx, 1, metric.WithAttributes(attrs...))

	// 2. Catat durasi latensi ke histogram
	duration := time.Since(startTime).Seconds()
	requestLatency.Record(ctx, duration, metric.WithAttributes(attrs...))
}

func main() {
	initMetrics()
	http.HandleFunc("/api/data", httpHandler)
	http.ListenAndServe(":8080", nil)
}

Ringkasan #

• Metrics mengukur data numerik deret waktu agregat — Sangat ringan dikonsumsi, murah disimpan untuk retensi jangka panjang, dan sangat cepat untuk di-query.
• Tiga tipe metrik dasar wajib dipahami — Counter untuk jumlah kumulatif yang hanya naik, Gauge untuk nilai instan yang naik-turun, dan Histogram untuk mengelompokkan frekuensi data.
• Jangan gunakan rata-rata (mean) untuk latensi — Rata-rata menyembunyikan kelambatan ekstrem pada ekor distribusi; pantau persentil P95 atau P99 sebagai gantinya.
• Terapkan Google SRE Four Golden Signals — Latency, Traffic, Errors, dan Saturation untuk memetakan kesehatan aplikasi secara universal.
• Gunakan framework RED untuk microservices (Rate, Errors, Duration) dan framework USE untuk infrastruktur (Utilization, Saturation, Errors).
• Rancang Custom Business Metrics — Guna mendeteksi bug logika proses bisnis yang tidak memicu alarm error sistem di tingkat server/infrastruktur.
• Gunakan OpenTelemetry SDK untuk instrumentasi kode yang agnostik agar terhindar dari keterikatan (lock-in) vendor monitoring tertentu.

← Sebelumnya: Logging   Berikutnya: Tracing →