Belajar gRPC - Observability, Tracing & Monitoring gRPC

#Pendahuluan

Server yang tidak bisa diamati adalah kotak hitam: kalian hanya tahu masalah ada, tanpa tahu di mana. Episode 14 membuka kotak itu. Kita membangun observability gRPC dalam tiga pilar: metrics (angka agregat seperti QPS dan latensi), logging (kejadian individual), dan tracing (perjalanan satu request melewati banyak service).

Kalian akan memakai Prometheus untuk metrik, OpenTelemetry untuk tracing, dan grpcurl serta ghz untuk debugging langsung. Setelah episode ini, setiap RPC bisa dijawab pertanyaannya: lambat di mana, dan kenapa?

#Monitoring dengan Prometheus

#gRPC Metrics

gRPC mendukung metrik terstandar. Di Go, pasang interceptor otomatis dari go.opentelemetry.io/contrib/instrumentation/google.golang.org/grpc/otelgrpc atau paket metrics:

import (
    "github.com/grpc-ecosystem/go-grpc-prometheus"
)
 
grpcPrometheus.Register(s)

grpcPrometheus.Register(s) memantau setiap RPC dan menghasilkan metrik seperti grpc_server_started_total, grpc_server_handled_total, dan grpc_server_handling_seconds — dengan label method dan status code.

#Expose Endpoint Metrics

Prometheus menarik metrik lewat endpoint HTTP. Jalankan server HTTP kecil di port terpisah:

http.Handle("/metrics", promhttp.Handler())
go http.ListenAndServe(":9090", nil)

Dengan promhttp.Handler() di /metrics, Prometheus bisa mengumpulkan data. Tambahkan konfigurasi scrape di prometheus.yml:

scrape_configs:
  - job_name: grpc-catalog
    static_configs:
      - targets: ["catalog:9090"]

Target catalog:9090 di atas mengarahkan Prometheus ke endpoint metrik server gRPC. Metrik lalu divisualisasikan di Grafana dengan dashboard gRPC siap pakai.

#OpenTelemetry dan Distributed Tracing

#Menyiapkan Tracer

OpenTelemetry menjadi standar observability lintas vendor. Pasang sebagai interceptor gRPC agar tracing otomatis tanpa menyentuh handler:

import (
    "go.opentelemetry.io/contrib/instrumentation/google.golang.org/grpc/otelgrpc"
)
 
s := grpc.NewServer(
    grpc.StatsHandler(otelgrpc.NewServerHandler()),
)

grpc.StatsHandler(otelgrpc.NewServerHandler()) membungkus server dengan statistik tracer: setiap RPC otomatis menjadi span dengan durasi, method, dan status. Di sisi client, pasang otelgrpc.NewClientHandler() dengan cara serupa.

#Span Context Propagation

Keajaiban tracing terjadi di propagasi: span di client menjadi parent dari span di server. gRPC membawa konteks ini lewat metadata standar traceparent:

conn, _ := grpc.NewClient("localhost:50051",
    grpc.WithTransportCredentials(insecure.NewCredentials()),
    grpc.WithStatsHandler(otelgrpc.NewClientHandler()),
)
res, err := client.GetProduct(ctx, &pb.ProductId{Id: "p-001"})

Saat GetProduct memanggil service lain, span yang sama diteruskan. Hasilnya: satu trace merentang dari A ke B ke C — dan di Jaeger atau Tempo, kalian bisa melihat request mana yang menyumbang latensi terbesar.

#Debugging gRPC dengan Tool Khusus

#grpcurl untuk Inspeksi Langsung

Saat ada anomaly, debugging langsung lebih cepat daripada menunggu dashboard:

grpcurl -plaintext localhost:50051 list
grpcurl -plaintext -v localhost:50051 \
  catalog.v1.CatalogService/GetProduct

Flag -v menampilkan header metadata dan detail status — termasuk grpc-status dan grpc-message yang menjelaskan kenapa sebuah panggilan gagal.

#ghz untuk Konfirmasi Perilaku

Bila dicurigai regresi performa, jalankan benchmark singkat:

ghz --insecure -n 1000 -c 20 \
  localhost:50051 catalog.v1.CatalogService/GetProduct

ghz --insecure -n 1000 -c 20 memberi angka cepat tentang throughput dan latensi saat itu juga — pembanding yang pas untuk dashboard historis di Grafana.

#Membaca Dashboard dengan Benar

Kombinasikan tiga sinyal: error rate naik bersamaan latensi p99 naik berarti server kewalahan; error rate naik tapi latensi normal berarti input masalah; error rate stabil tapi latensi naik berarti bottleneck di dependency. Tiga sinyal inilah yang membedakan debugging terarah dari menebak-nebak.

#Penutup

Inti yang harus dibawa pulang:

• Prometheus metrik gRPC (mulai dari grpc_server_*) memberi angka QPS, latensi, dan error.
• Expose /metrics dan scrape dengan Prometheus, lalu visualisasi di Grafana.
• OpenTelemetry menghasilkan span otomatis lewat StatsHandler tanpa menyentuh handler.
• Propagasi traceparent membuat satu trace merentang antar service.
• grpcurl -v membongkar metadata dan status untuk debugging langsung.
• Kombinasikan error rate, p99, dan durasi dependency untuk diagnosis terarah.

Di episode 15 selanjutnya kita membahas resilience, retry, dan fault tolerance — retry policy via service config, circuit breaker, strategi timeout dan failover, serta graceful shutdown, health checks, dan readiness probes. Sistem yang teramati kini dibangun agar tetap berdiri ketika komponen di bawahnya tumbang.