About
This Claude Skill helps developers implement comprehensive observability in Go services using structured logging (slog), distributed tracing (OpenTelemetry), and metrics (Prometheus). Use it when you need to add instrumentation, logging, tracing, or metrics to your codebase. It specifically focuses on observability patterns, not performance profiling or error handling which are covered by other skills.
Quick Install
Claude Code
Recommendednpx skills add eduardo-sl/go-agent-skills -a claude-code/plugin add https://github.com/eduardo-sl/go-agent-skillsgit clone https://github.com/eduardo-sl/go-agent-skills.git ~/.claude/skills/go-observabilityCopy and paste this command in Claude Code to install this skill
Documentation
Go Observability
Observability is not optional for production services. Every service must produce
structured logs, expose metrics, and propagate trace context. Use the stdlib
log/slog for logging and OpenTelemetry for tracing and metrics.
1. Structured Logging with slog
Use log/slog (Go 1.21+) as the standard logging package:
// ✅ Good — structured, leveled logging
logger := slog.New(slog.NewJSONHandler(os.Stdout, &slog.HandlerOptions{
Level: slog.LevelInfo,
}))
logger.Info("user created",
slog.String("user_id", user.ID),
slog.String("email", user.Email),
slog.Duration("latency", elapsed),
)
// ❌ Bad — unstructured printf-style logging
log.Printf("user %s created with email %s in %v", user.ID, user.Email, elapsed)
Pass logger via context or dependency injection:
// ✅ Good — logger as dependency
type UserService struct {
logger *slog.Logger
store UserStore
}
func NewUserService(logger *slog.Logger, store UserStore) *UserService {
return &UserService{
logger: logger.With(slog.String("component", "user_service")),
store: store,
}
}
// ❌ Bad — global logger
var logger = slog.Default()
Create child loggers with scoped attributes:
func (s *UserService) CreateUser(ctx context.Context, req CreateUserReq) error {
log := s.logger.With(
slog.String("method", "CreateUser"),
slog.String("request_id", middleware.RequestID(ctx)),
)
log.Info("creating user", slog.String("email", req.Email))
if err := s.store.Insert(ctx, req); err != nil {
log.Error("failed to create user", slog.Any("error", err))
return fmt.Errorf("create user: %w", err)
}
log.Info("user created successfully")
return nil
}
Log levels — use them consistently:
| Level | Use for |
|---|---|
Debug | Verbose diagnostic info, disabled in production |
Info | Normal operations: request received, job completed |
Warn | Recoverable issues: retry succeeded, deprecated usage |
Error | Failures requiring attention: DB down, external call failed |
NEVER log at Error level for expected conditions (e.g., user not found → Info or Warn).
Sensitive data — NEVER log:
- Passwords, tokens, API keys
- Full credit card numbers, SSNs
- Raw request bodies containing PII
// ✅ Good — redacted
logger.Info("auth attempt", slog.String("user", email), slog.Bool("success", ok))
// ❌ Bad — leaks credentials
logger.Info("auth attempt", slog.String("password", password))
2. Distributed Tracing with OpenTelemetry
Initialize the tracer provider:
func initTracer(ctx context.Context, serviceName string) (*trace.TracerProvider, error) {
exporter, err := otlptrace.New(ctx, otlptracehttp.NewClient())
if err != nil {
return nil, fmt.Errorf("create exporter: %w", err)
}
tp := trace.NewTracerProvider(
trace.WithBatcher(exporter),
trace.WithResource(resource.NewWithAttributes(
semconv.SchemaURL,
semconv.ServiceNameKey.String(serviceName),
)),
)
otel.SetTracerProvider(tp)
otel.SetTextMapPropagator(propagation.TraceContext{})
return tp, nil
}
Create spans for significant operations:
func (s *UserService) GetUser(ctx context.Context, id string) (*User, error) {
ctx, span := otel.Tracer("user-service").Start(ctx, "GetUser")
defer span.End()
span.SetAttributes(attribute.String("user.id", id))
user, err := s.store.FindByID(ctx, id)
if err != nil {
span.RecordError(err)
span.SetStatus(codes.Error, err.Error())
return nil, fmt.Errorf("get user %s: %w", id, err)
}
return user, nil
}
Span naming conventions:
// ✅ Good — operation name, not function name
ctx, span := tracer.Start(ctx, "GetUser")
ctx, span := tracer.Start(ctx, "db.query")
ctx, span := tracer.Start(ctx, "http.request")
// ❌ Bad — too verbose or too generic
ctx, span := tracer.Start(ctx, "github.com/myorg/myapp/internal/user.(*Service).GetUser")
ctx, span := tracer.Start(ctx, "doStuff")
Always propagate context through the call chain:
// ✅ Good — context flows through
func (h *Handler) GetUser(w http.ResponseWriter, r *http.Request) {
ctx := r.Context() // carries trace context from middleware
user, err := h.service.GetUser(ctx, id)
// ...
}
// ❌ Bad — trace context lost
func (h *Handler) GetUser(w http.ResponseWriter, r *http.Request) {
user, err := h.service.GetUser(context.Background(), id) // breaks trace chain
// ...
}
3. Metrics with OpenTelemetry / Prometheus
Define metrics at package level:
var (
requestDuration = promauto.NewHistogramVec(
prometheus.HistogramOpts{
Name: "http_request_duration_seconds",
Help: "Duration of HTTP requests in seconds.",
Buckets: prometheus.DefBuckets,
},
[]string{"method", "path", "status"},
)
requestsTotal = promauto.NewCounterVec(
prometheus.CounterOpts{
Name: "http_requests_total",
Help: "Total number of HTTP requests.",
},
[]string{"method", "path", "status"},
)
)
Metric naming conventions:
<namespace>_<subsystem>_<name>_<unit>
http_request_duration_seconds ✅ (unit in name)
http_requests_total ✅ (counter with _total suffix)
db_connections_active ✅ (gauge, no suffix needed)
user_signups ❌ (missing _total for counter)
requestLatency ❌ (camelCase, no unit)
Instrument HTTP middleware:
func MetricsMiddleware(next http.Handler) http.Handler {
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
start := time.Now()
ww := &responseWriter{ResponseWriter: w, statusCode: http.StatusOK}
next.ServeHTTP(ww, r)
duration := time.Since(start).Seconds()
status := strconv.Itoa(ww.statusCode)
requestDuration.WithLabelValues(r.Method, r.URL.Path, status).Observe(duration)
requestsTotal.WithLabelValues(r.Method, r.URL.Path, status).Inc()
})
}
Use histograms for latencies, counters for totals, gauges for current state:
| Type | Use for | Example |
|---|---|---|
| Counter | Monotonically increasing values | Requests total, errors total |
| Gauge | Values that go up and down | Active connections, queue depth |
| Histogram | Distribution of values | Request latency, response size |
Keep cardinality low — avoid high-cardinality labels:
// ✅ Good — bounded label values
requestsTotal.WithLabelValues(r.Method, routePattern, status)
// ❌ Bad — unbounded cardinality (user IDs, request IDs)
requestsTotal.WithLabelValues(r.Method, r.URL.Path, userID)
4. Connecting Logs, Traces, and Metrics
Inject trace ID into log entries:
func LogWithTrace(ctx context.Context, logger *slog.Logger) *slog.Logger {
spanCtx := trace.SpanContextFromContext(ctx)
if !spanCtx.IsValid() {
return logger
}
return logger.With(
slog.String("trace_id", spanCtx.TraceID().String()),
slog.String("span_id", spanCtx.SpanID().String()),
)
}
// Usage in handlers/services:
func (s *Service) Process(ctx context.Context) error {
log := LogWithTrace(ctx, s.logger)
log.Info("processing started") // log includes trace_id and span_id
// ...
}
5. Graceful Shutdown of Telemetry
func main() {
ctx := context.Background()
tp, err := initTracer(ctx, "my-service")
if err != nil {
log.Fatalf("init tracer: %v", err)
}
// Ensure all spans are flushed on shutdown
defer func() {
shutdownCtx, cancel := context.WithTimeout(context.Background(), 5*time.Second)
defer cancel()
if err := tp.Shutdown(shutdownCtx); err != nil {
log.Printf("tracer shutdown: %v", err)
}
}()
// ... start server
}
Verification Checklist
- All logging uses
log/slogwith structured key-value pairs, notfmt.Printforlog.Printf - Logger is injected as a dependency, not used as a global
- No sensitive data (passwords, tokens, PII) in log output
- Trace context is propagated through all function calls via
context.Context - Spans are created for significant operations (DB calls, HTTP requests, business logic)
- Spans record errors with
span.RecordError(err)and set error status - Metrics follow naming conventions:
_seconds,_total,_bytes - No high-cardinality labels (user IDs, request IDs) in metrics
- Telemetry providers are shut down gracefully on service exit
- Trace IDs are included in log entries for correlation
GitHub Repository
Frequently asked questions
What is the go-observability skill?
go-observability is a Claude Skill by eduardo-sl. Skills package instructions and resources that Claude loads on demand, so Claude can perform go-observability-related tasks without extra prompting.
How do I install go-observability?
Use the install commands on this page: add go-observability to Claude Code as a plugin, or clone its repository into your skills directory, then restart Claude so it picks up the skill.
What category does go-observability belong to?
go-observability is in the Design category, tagged api and design.
Is go-observability free to use?
Yes. go-observability is listed on AIMCP and free to install.
Related Skills
Use the executing-plans skill when you have a complete implementation plan to execute in controlled batches with review checkpoints. It loads and critically reviews the plan, then executes tasks in small batches (default 3 tasks) while reporting progress between each batch for architect review. This ensures systematic implementation with built-in quality control checkpoints.
This skill dispatches a code-reviewer subagent to analyze code changes against requirements before proceeding. It should be used after completing tasks, implementing major features, or before merging to main. The review helps catch issues early by comparing the current implementation with the original plan.
This skill provides a comprehensive guide for developers to connect MCP servers to Claude Code using HTTP, stdio, or SSE transports. It covers installation, configuration, authentication, and security for integrating external services like GitHub, Notion, and custom APIs. Use it when setting up MCP integrations, configuring external tools, or working with Claude's Model Context Protocol.
This skill helps developers choose between Claude Code Web and CLI interfaces based on task analysis, then enables seamless session teleportation between these environments. It optimizes workflow by managing session state and context when switching between web, CLI, or mobile. Use it for complex projects requiring different tools at various stages.
