What problem does it solve?
Correct OpenTelemetry (OTel) setup and instrumentation for Go services is hard because distributed tracing requires precise SDK initialization, context propagation, and signal-specific best practices to avoid missing data, broken correlations, or invalid span/metric semantics.
Core Features & Use Cases
- Traces, metrics, and logs setup: Initialize TracerProvider, MeterProvider, and LoggerProvider in a Go codebase with correct resource attributes and propagation configuration.
- Span and attribute correctness: Apply Go-specific span naming, span kind decisions, HTTP status to span status mapping, and context hygiene to prevent orphan spans and misleading topology.
- Messaging propagation across Kafka/SQS/RabbitMQ: Implement the producer/consumer model using span Links for consumer spans to preserve accurate workflow boundaries.
- Cross-signal audit support: Use a checklist-driven audit flow (via Tsuga CLI guidance) to verify presence, correlation, naming quality, and cardinality issues across traces/metrics/logs.
- Safety for sensitive data: Follow strict rules for not emitting credentials/PII into spans, logs, and metrics.
Quick Start
Use the otel-go skill when you need help adding or fixing OTel SDK setup or instrumentation in a confirmed Go service, and ask it to propose the minimal change plan before you apply any code updates.