golang-observability

Instrument Go services with structured logging, Prometheus metrics, OpenTelemetry tracing, profiling, and alerting.

Updated May 9, 2026
One-click install
npx skills add https://github.com/LuminaVault/LuminaVaultShared --skill golang-observability-luminavault
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: golang-observability
Source: https://github.com/LuminaVault/LuminaVaultShared/tree/main/.agents/skills/golang-observability
Command: npx skills add https://github.com/LuminaVault/LuminaVaultShared --skill golang-observability-luminavault

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Go services shipped without observability are impossible to diagnose in production. This Skill guides the instrumentation of Go applications with the five core signals — logs, metrics, traces, profiles, and RUM — so every feature is monitorable, alertable, and debuggable before it ships. ## Core Features & Use Cases - Structured Logging with slog: Set up JSON logging for production, migrate from zap/logrus/zerolog using bridge handlers, and correlate logs with traces via the otelslog bridge. - Prometheus Metrics & Alerting: Declare counters, gauges, and histograms with correct naming and bucket choices, avoid high-cardinality label traps, document metrics with PromQL-as-comments, and build multi-window burn-rate SLO alerts plus Go runtime alerts. - OpenTelemetry Tracing & Profiling: Add spans to service methods, DB queries, and external calls, propagate context correctly, control costs with sampling, and enable pprof/Pyroscope profiling via environment toggles. - Use Case: When adding a new HTTP endpoint to a Go service, use this Skill to declare latency histograms and error counters, add spans with proper error recording, emit structured context-aware logs, and wire the PromQL into Grafana dashboards and alert rules. ## Quick Start Ask the agent to add production observability — metrics, tracing, and structured logging — to your Go HTTP service.

Frequently Asked Questions about golang-observability

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I add Prometheus metrics to a Go service?▼

Use the prometheus/client_golang library to declare counters, gauges, and histograms, then expose them via promhttp.Handler() on a /metrics endpoint. Prefer Histograms over Summaries for latency so percentiles can be aggregated across instances with histogram_quantile().

How do I migrate from zap or logrus to slog in Go?▼

Migrate incrementally in three steps: bridge slog output through your existing logger with samber/slog-zap or samber/slog-logrus, gradually replace call sites with slog.Info-style calls, then remove the bridge and old dependency once migration is complete.

Should I use a Histogram or Summary for latency metrics in Prometheus?▼

Use a Histogram in almost all cases. Histograms store bucket counts server-side so percentiles can be aggregated across instances with histogram_quantile(), while Summary quantiles are computed client-side and cannot be aggregated.

Why are high-cardinality labels a problem in Prometheus?▼

Each unique label combination creates a separate time series, so unbounded values like user IDs or full URL paths cause memory explosion and slow queries on the Prometheus server. Use route templates and bounded values, and put high-cardinality data in traces instead.

How do I correlate Go logs with OpenTelemetry traces?▼

Use the otelslog bridge from go.opentelemetry.io/contrib/bridges/otelslog as your slog handler, then always call the *Context variants like slog.InfoContext(ctx, ...). Trace IDs and span IDs are automatically injected into each log record.

When should I not use this observability skill?▼

This skill covers always-on production signals, not temporary deep-dive performance investigation. For one-off benchmarking or targeted performance analysis, use dedicated benchmark and performance skills instead.