golang-observability

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

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

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Go services shipped without observability are black boxes in production — you cannot diagnose latency spikes, error bursts, or resource leaks without logs, metrics, traces, and profiles wired together. This Skill guides the instrumentation of Go services across all five observability signals so every feature is monitorable before it ships. ## Core Features & Use Cases - Structured logging with slog: JSON handlers for production, context-aware log variants for trace correlation, and incremental migration from zap, logrus, or zerolog using bridge handlers. - Prometheus metrics and alerting: correct use of Counters, Gauges, and Histograms, naming conventions, low-cardinality label discipline, PromQL-as-comments convention, multi-window burn-rate SLO alerts, and Go runtime alerts for goroutine leaks and GC pressure. - OpenTelemetry tracing and profiling: span placement on service methods, DB queries, and external calls, context propagation, exemplars linking metrics to traces, and pprof/Pyroscope profiling toggled via environment variables. - Use Case: When adding a new HTTP endpoint to a Go service, use this Skill to declare latency and error metrics with PromQL comments, add spans with error recording, emit structured context-aware logs, and wire the corresponding Grafana dashboard and alert rules. ## Quick Start Ask the agent to add production observability instrumentation to your Go service, covering slog logging, Prometheus metrics, and OpenTelemetry tracing for a specific handler or package.

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 with promauto, 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 the 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 combined across replicas.

Why are high-cardinality labels dangerous 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 label 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 ID and span ID are automatically injected into each log record.

When should I not use this observability skill?▼

Do not use it for temporary deep-dive performance investigations of a specific bottleneck. That scenario belongs to dedicated benchmarking and performance-analysis skills, whereas this Skill covers always-on production signals.