Monitoring dan Observability untuk Sistem Go di Production

Tanpa Observability, Kamu Buta di Production

Saya pernah mengalami mimpi buruk di production: sistem lambat, tapi tidak ada yang tahu kenapa. Tidak ada metrics, tidak ada structured logs, tidak ada tracing. Saya harus SSH ke server, tail -f log files, dan "menebak" apa yang terjadi. Pengalaman itu mengajarkan saya: observability bukan optional — ini survival skill.

The Three Pillars

Observability berdiri di tiga pilar utama, dan ketiganya saling melengkapi:

1. Metrics: Angka-angka kuantitatif — request rate, latency, error rate, CPU/memory usage. Menggunakan Prometheus.

2. Logs: Cerita detail dari setiap request atau event. Structured logging dengan JSON format.

3. Traces: Journey dari satu request melintasi multiple services. Distributed tracing dengan OpenTelemetry.

Implementasi di Go: Structured Logging

package middleware

import (
    "log/slog"
    "net/http"
    "time"
)

func LoggingMiddleware(next http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        start := time.Now()
        wrapped := &statusWriter{ResponseWriter: w, status: 200}
        next.ServeHTTP(wrapped, r)
        slog.Info("HTTP Request",
            "method", r.Method,
            "path", r.URL.Path,
            "status", wrapped.status,
            "duration_ms", time.Since(start).Milliseconds(),
        )
    })
}

Prometheus Metrics di Go

package metrics

import (
    "github.com/prometheus/client_golang/prometheus"
    "github.com/prometheus/client_golang/prometheus/promauto"
)

var (
    httpRequestsTotal = promauto.NewCounterVec(
        prometheus.CounterOpts{
            Name: "http_requests_total",
            Help: "Total number of HTTP requests",
        },
        []string{"method", "path", "status"},
    )

    httpRequestDuration = promauto.NewHistogramVec(
        prometheus.HistogramOpts{
            Name:    "http_request_duration_seconds",
            Help:    "HTTP request duration in seconds",
            Buckets: prometheus.DefBuckets,
        },
        []string{"method", "path"},
    )
)

Alerting Rules yang Berguna

Dari pengalaman saya, ini alerting rules yang paling sering menyelamatkan sistem di production:

• High error rate: Error rate > 5% selama 5 menit ke PagerDuty alert
• High latency: P99 latency > 2 detik selama 10 menit ke Slack notification
• Disk usage: Disk > 80% ke Email ke tim DevOps
• Service down: Health check gagal 3x berturut-turut ke Emergency alert

Grafana Dashboard

Saya biasanya setup dashboard dengan 4 panels utama: RED metrics (Rate, Errors, Duration) dari setiap service, infrastructure metrics (CPU, Memory, Disk, Network), business metrics (orders/minute, active users), dan dependency health (database connections, cache hit rate).

Kesimpulan

Observability itu investasi awal yang menghemat waktu debugging berjam-jam di production. Mulai dari structured logging — ini yang paling mudah — lalu tambah metrics dan tracing secara bertahap.

Cost Management untuk Observability

Observability bisa mahal kalau tidak di-manage dengan baik. Metrics storage, log storage, dan trace storage bisa menghabiskan budget besar di scale tinggi. Beberapa strategi yang saya gunakan: sampling untuk traces (tidak perlu trace semua request), log level management (info di production, debug hanya saat debugging), dan retention policy yang tepat (metrics 30 hari, logs 7 hari, traces 3 hari).

Dengan pendekatan ini, saya bisa menjaga biaya observability tetap reasonable sambil tetap mendapatkan visibility yang cukup untuk debugging dan monitoring production systems.