golang-observability

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

1|Updated May 25, 2020
One-click install
npx skills add https://github.com/titaneric/dotfiles --skill golang-observability-titaneric
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: golang-observability
Source: https://github.com/titaneric/dotfiles/tree/main/dot_agents/skills/golang-observability
Command: npx skills add https://github.com/titaneric/dotfiles --skill golang-observability-titaneric

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 AI coding agents to instrument Go applications with the five production signals — structured logs, Prometheus metrics, OpenTelemetry traces, pprof/Pyroscope profiles, and RUM events — so every feature is monitorable before it ships. ## Core Features & Use Cases - Structured logging with slog: JSON handlers for production, context-aware log calls for trace correlation, and incremental migration from zap/logrus/zerolog via bridge handlers. - Metrics and alerting: Prometheus metric declarations with PromQL-as-comments conventions, histogram-based percentile tracking, multi-window burn-rate SLO alerts, and Go runtime alert rules. - Tracing and profiling: OpenTelemetry span instrumentation, otelslog log-trace correlation, exemplars linking metrics to traces, and environment-toggled pprof/Pyroscope continuous profiling. - Use Case: When adding a new HTTP endpoint to a Go microservice, use this Skill to declare latency histograms and error counters, add spans around DB queries, emit structured logs with trace IDs, and wire the PromQL into Grafana dashboards and alert rules. ## Quick Start Ask the agent to add production observability — metrics, structured logging, and tracing — to your Go service's HTTP handlers and database calls.

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 your existing logger using 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.

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 every log record.

Why should I avoid user IDs as Prometheus metric labels?

User IDs are high-cardinality values, and each unique label combination creates a separate time series, causing memory explosion on the Prometheus server. Use bounded labels like route templates and status buckets, and put high-cardinality data in traces instead.

Should I use rate() or irate() in Prometheus alert rules?

Use rate() for alerts because irate() reacts to a single scrape interval and causes false positives from transient spikes. Combine rate() with a for: duration (2-5 minutes for critical, 10-30 minutes for warnings) so alerts only fire on sustained conditions.

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 CPU/memory optimization work, use dedicated benchmark and performance analysis skills instead.