Opentelemetry
Skill ComeOnOliver/skillshub/skills/TerminalSkills/skills/opentelemetry
🧠The right skill, one API call. AI agent skills registry with token-efficient skill resolution. 5,000+ skills from 500+ top repos.
npx -y skills add ComeOnOliver/skillshub --skill opentelemetryAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
SKILL.md
3.3 KB, as published. Nobody here has run it
OpenTelemetry
Overview
OpenTelemetry (OTel) is the unified observability standard for instrumenting applications with traces, metrics, and logs. It supports auto-instrumentation across Node.js, Python, Java, and Go, and exports telemetry to backends like Jaeger, Grafana, Datadog, and Honeycomb through a flexible Collector pipeline.
Instructions
- When adding tracing, create spans with meaningful names, set span kinds (
CLIENT,SERVER,PRODUCER,CONSUMER), add business-relevant attributes, and use W3C Trace Context for propagation. - When adding metrics, choose the right instrument type: Counter for monotonic values, Histogram for distributions like latency, UpDownCounter for fluctuating values, and Gauge for point-in-time readings.
- When setting up auto-instrumentation, use the language-specific packages (
@opentelemetry/auto-instrumentations-node,opentelemetry-instrumentationfor Python, etc.) to capture HTTP, database, and messaging spans without code changes. - When configuring the OTel Collector, define pipelines with receivers (OTLP, Prometheus), processors (batch, memory_limiter, tail_sampling), and exporters (OTLP, Jaeger, Datadog) in the collector config.
- When deploying Collectors, choose sidecar mode for per-pod collection, agent mode for per-node, or gateway mode for centralized processing.
- When setting resource attributes, always include
service.name,service.version, anddeployment.environment, and use cloud/container resource detectors for infrastructure metadata. - When naming attributes, follow OTel semantic conventions (
http.request.method,db.system,messaging.system) instead of inventing custom names.
Examples
Example 1: Add distributed tracing to a Node.js microservice
User request: "Instrument my Express API with OpenTelemetry tracing"
Actions:
- Install
@opentelemetry/auto-instrumentations-nodeand OTLP exporter - Configure SDK with service name, version, and
BatchSpanProcessor - Set up OTLP exporter pointing to the Collector endpoint
- Add custom spans with business attributes for key operations
Output: An auto-instrumented Express API sending traces to the OTel Collector with correlated spans across services.
Example 2: Set up an OTel Collector pipeline
User request: "Configure an OTel Collector to receive traces and export to Grafana Tempo"
Actions:
- Define OTLP gRPC receiver in the Collector config
- Add batch processor and memory_limiter for production safety
- Configure Tempo exporter with endpoint and authentication
- Wire the traces pipeline: receiver -> processor -> exporter
Output: A Collector config file routing traces from applications to Grafana Tempo with batching and memory protection.
Guidelines
- Always set
service.nameandservice.versionas resource attributes. - Use semantic conventions for attribute names; never invent custom names when a standard exists.
- Configure
BatchSpanProcessorin production, notSimpleSpanProcessor, to avoid blocking the application. - Set
memory_limiterprocessor on the Collector to prevent OOM crashes. - Sample in production:
TraceIdRatioBased(0.1)captures 10% of traces, sufficient for most services. - Add custom attributes to spans for business context (
user.tier,feature.flag,order.total). - Never log sensitive data in span attributes (PII, secrets, tokens).