go-observability
Acerca de
Esta Skill de Claude ayuda a los desarrolladores a implementar observabilidad integral en servicios Go utilizando registro estructurado (slog), trazas distribuidas (OpenTelemetry) y métricas (Prometheus). Úsala cuando necesites agregar instrumentación, registro, trazas o métricas a tu base de código. Se enfoca específicamente en patrones de observabilidad, no en perfilado de rendimiento o manejo de errores, los cuales están cubiertos por otras skills.
Instalación rápida
Claude Code
Recomendadonpx 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-observabilityCopia y pega este comando en Claude Code para instalar esta habilidad
Documentación
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
Repositorio GitHub
Preguntas frecuentes
¿Qué es el Skill go-observability?
go-observability es un Skill de Claude creado por eduardo-sl. Los Skills agrupan instrucciones y recursos que Claude carga cuando los necesita para realizar tareas relacionadas con go-observability sin indicaciones adicionales.
¿Cómo instalo go-observability?
Usa los comandos de instalación de esta página: añade go-observability a Claude Code como plugin o clona su repositorio en tu directorio de skills y reinicia Claude para cargarlo.
¿A qué categoría pertenece go-observability?
go-observability pertenece a la categoría Diseño.
¿Se puede usar go-observability gratis?
Sí. go-observability aparece en AIMCP y se puede instalar gratis.
Habilidades relacionadas
Utilice la habilidad executing-plans cuando tenga un plan de implementación completo para ejecutar en lotes controlados con puntos de revisión. Esta habilidad carga y revisa críticamente el plan, luego ejecuta tareas en pequeños lotes (por defecto 3 tareas) mientras reporta el progreso entre cada lote para la revisión del arquitecto. Esto asegura una implementación sistemática con puntos de control de calidad integrados.
Esta habilidad despacha un subagente revisor de código para analizar los cambios en el código frente a los requisitos antes de proceder. Debe usarse después de completar tareas, implementar funciones principales o antes de fusionar con la rama principal. La revisión ayuda a detectar problemas de forma temprana al comparar la implementación actual con el plan original.
Esta habilidad proporciona una guía integral para que los desarrolladores conecten servidores MCP a Claude Code mediante transportes HTTP, stdio o SSE. Cubre la instalación, configuración, autenticación y seguridad para integrar servicios externos como GitHub, Notion y APIs personalizadas. Úsala al configurar integraciones MCP, al configurar herramientas externas o al trabajar con el Protocolo de Contexto del Modelo de Claude.
Esta habilidad ayuda a los desarrolladores a elegir entre las interfaces web y CLI de Claude Code mediante el análisis de tareas, y luego permite la teletransportación fluida de sesiones entre estos entornos. Optimiza el flujo de trabajo gestionando el estado y el contexto de la sesión al cambiar entre web, CLI o móvil. Úsala para proyectos complejos que requieren diferentes herramientas en varias etapas.
