dash0/agent-skills
Expert guidance for configuring and deploying the OpenTelemetry Collector. Use when setting up a Collector pipeline, configuring receivers, exporters, or processors, deploying a Collector to Kubernetes or Docker, or forwarding telemetry to Dash0. Triggers on requests involving collector, pipeline, OTLP receiver, exporter, or Dash0 collector setup.
100
100%
Does it follow best practices?
Impact
Pending
No eval scenarios have been run
Advisory
Suggest reviewing before use
telemetry.mdskills/otel-instrumentation/rules/
- title:
- Telemetry overview
- impact:
- CRITICAL
- tags:
- telemetry, overview
Telemetry overview
This is the entrypoint for the OpenTelemetry instrumentation skill. Start here, then follow the links below to the relevant rule files.
Before you instrument
Resolve configuration values first.
Every instrumentation setup requires project-specific values (service.name, service.version, deployment.environment.name, OTLP endpoint, auth token).
Use the ordered lookup strategies in that file to infer them from the codebase before writing any instrumentation code.
Resource attributes identify what produces telemetry. They are attached to every signal automatically and must be set correctly before any other instrumentation work.
Signals
Telemetry consists of three core signal types: Metrics, Traces, and Logs. Each serves a distinct purpose in understanding system behavior.
Symptom-to-cause workflow: Metrics surface problems → Traces pinpoint location → Logs explain causation.
Correlation is essential. Link signals through shared context (trace IDs, span IDs) so you can navigate from an alert to the exact log line that explains the failure.
Platforms
| Platform | Reference |
|---|---|
| Kubernetes | Kubernetes deployment |