go-observability

Use the Prometheus client_golang library to declare Counters for events, Gauges for current state, and Histograms for latency distributions, then expose them via promhttp.Handler on a /metrics endpoint. Keep label cardinality bounded and document each metric with PromQL queries and alert rules as comments above the declaration.

Migrate incrementally using bridge handlers like samber/slog-zap or samber/slog-logrus that route slog output through your existing logger. Replace call sites with slog.Info-style calls one by one, then remove the bridge and old dependency once migration is complete.

Prefer Histogram in almost all cases because its bucket counts are stored server-side and can be aggregated across instances using histogram_quantile(). Summary computes quantiles client-side that cannot be aggregated, making it suitable only for single-instance diagnostics.

Every unique label combination creates a separate time series, so unbounded values like user IDs or full URLs cause memory explosion and slow queries on the Prometheus server. Use route templates, status code buckets, and keep label values under roughly 100 unique values.

Yes, enable pprof via an environment variable toggle so it can be switched on without redeploying, but always protect the endpoints with authentication and network isolation. Exposed pprof endpoints leak sensitive runtime information and can be abused for denial of service.

Check user consent before firing any server-side analytics events, use an immutable user_id rather than email as the identity key, and implement data export and deletion endpoints that propagate to your analytics platform and CDP. Self-hosting tools like PostHog simplifies cross-border data transfer compliance.