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
deployment.mdskills/otel-collector/rules/
- title:
- Deployment
- impact:
- HIGH
- tags:
- deployment, kubernetes, docker, agent, gateway
Deployment
The OpenTelemetry Collector can be deployed in a variety of ways. Choose the pattern based on what telemetry you collect and how you process it.
Decision process
Follow these steps in order. Stop at the first match.
1. Is the target environment Kubernetes?
If no — use Docker Compose or a binary for local development, or a system service for bare-metal hosts. The remaining steps apply only to Kubernetes.
2. Is Dash0 the observability backend?
If yes and you do not need custom Collector pipelines (custom processors, connectors, or non-standard receivers) — use the Dash0 Kubernetes Operator. It deploys and manages Collectors automatically, injects instrumentation without per-workload annotations, and synchronises dashboards and alert rules.
If yes but you need full control over the Collector pipeline — continue to step 3. Configure the Collector to export to Dash0 via OTLP (see exporters).
3. Do you need automatic SDK instrumentation injected into application pods?
If yes — use the OpenTelemetry Operator.
It manages Collector instances via the OpenTelemetryCollector CRD and injects language-specific auto-instrumentation via the Instrumentation CRD.
If no — continue to step 4.
4. Is Helm available in the cluster?
If yes — use the Collector Helm chart.
Presets handle RBAC, volumes, and common receivers automatically.
Set mode to daemonset for an agent or deployment for a gateway.
If no — use raw Kubernetes manifests.
Summary
Is the target Kubernetes?
├─ No → Docker Compose / binary
└─ Yes
└─ Is Dash0 the backend?
├─ Yes, standard pipelines → Dash0 Operator
├─ Yes, custom pipelines → continue ↓
└─ No → continue ↓
└─ Need auto-instrumentation?
├─ Yes → OpenTelemetry Operator
└─ No
└─ Helm available?
├─ Yes → Collector Helm chart
└─ No → Raw manifestsDeployment method comparison
| Capability | Dash0 Operator | OTel Operator | Helm chart | Raw manifests |
|---|---|---|---|---|
| Automatic Collector deployment | Yes | Yes (via CRD) | Yes | Manual |
| Auto-instrumentation injection | Yes (automatic) | Yes (per-workload annotation) | No | No |
| Custom Collector pipelines | No | Yes | Yes | Yes |
| Sidecar Collector mode | No | Yes | No | Manual |
| Dashboard and alert sync | Yes | No | No | No |
| Prometheus CRD support (ServiceMonitor) | Yes (opt-in) | Yes | No | No |
| Requires Helm | Yes | No | Yes | No |
| Requires cert-manager | No | Yes | No | No |
Agent vs gateway
For agent vs gateway pattern selection (DaemonSet, Deployment, or both), see raw manifests. The same decision applies when deploying with the Collector Helm chart or the OpenTelemetry Operator. The Dash0 Kubernetes Operator manages this topology automatically.