go-observability
À propos
Cette compétence Claude aide les développeurs à implémenter une observabilité complète dans les services Go en utilisant la journalisation structurée (slog), le traçage distribué (OpenTelemetry) et les métriques (Prometheus). Utilisez-la lorsque vous devez ajouter de l'instrumentation, de la journalisation, du traçage ou des métriques à votre base de code. Elle se concentre spécifiquement sur les modèles d'observabilité, et non sur le profilage des performances ou la gestion des erreurs, qui sont couverts par d'autres compétences.
Installation rapide
Claude Code
Recommandénpx 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-observabilityCopiez et collez cette commande dans Claude Code pour installer cette compétence
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
Dépôt GitHub
Questions fréquentes
Qu’est-ce que le Skill go-observability ?
go-observability est un Skill Claude créé par eduardo-sl. Un Skill regroupe des instructions et des ressources que Claude charge à la demande pour effectuer des tâches liées à go-observability sans consigne supplémentaire.
Comment installer go-observability ?
Utilisez les commandes d’installation de cette page : ajoutez go-observability à Claude Code comme plugin ou clonez son dépôt dans votre dossier skills, puis redémarrez Claude pour charger le Skill.
À quelle catégorie appartient go-observability ?
go-observability appartient à la catégorie Design.
go-observability est-il gratuit ?
Oui. go-observability est référencé sur AIMCP et son installation est gratuite.
Compétences associées
Utilisez la compétence executing-plans lorsque vous disposez d'un plan de mise en œuvre complet à exécuter par lots contrôlés avec des points de contrôle de revue. Elle charge et examine le plan de manière critique, puis exécute les tâches par petits lots (3 tâches par défaut) tout en rapportant la progression entre chaque lot pour une revue par l'architecte. Cela garantit une mise en œuvre systématique avec des points de contrôle de qualité intégrés.
Cette compétence délègue un sous-agent réviseur de code pour analyser les modifications apportées au code par rapport aux exigences avant de poursuivre. Elle doit être utilisée après avoir terminé des tâches, implémenté des fonctionnalités majeures, ou avant une fusion vers la branche principale. La revue aide à détecter précocement les problèmes en comparant l'implémentation actuelle avec le plan initial.
Cette compétence fournit un guide complet permettant aux développeurs de connecter des serveurs MCP à Claude Code via les transports HTTP, stdio ou SSE. Elle couvre l'installation, la configuration, l'authentification et la sécurité pour intégrer des services externes tels que GitHub, Notion et des API personnalisées. Utilisez-la lors de la configuration d'intégrations MCP, de la configuration d'outils externes ou du travail avec le Protocole de Contexte de Modèle de Claude.
Cette compétence aide les développeurs à choisir entre les interfaces Web et CLI de Claude Code en fonction de l'analyse des tâches, puis permet une téléportation transparente des sessions entre ces environnements. Elle optimise le flux de travail en gérant l'état et le contexte de la session lors du passage entre le web, la CLI ou le mobile. Utilisez-la pour des projets complexes nécessitant différents outils à diverses étapes.
