From dash0-agent-skills
Guides OpenTelemetry instrumentation setup for traces, metrics, logs including spans, resources, SDKs for Node.js, Python, Java, Go, .NET, Ruby, PHP, Next.js, browser, and Kubernetes best practices.
npx claudepluginhub dash0hq/claude-marketplace --plugin dash0-agent-skillsThis skill uses the workspace's default tool permissions.
Expert guidance for implementing high-quality, cost-efficient OpenTelemetry telemetry.
README.mdrules/logs.mdrules/metrics.mdrules/platforms/k8s.mdrules/resolve-values.mdrules/resources.mdrules/sdks/browser.mdrules/sdks/dotnet.mdrules/sdks/go.mdrules/sdks/java.mdrules/sdks/nextjs.mdrules/sdks/nodejs.mdrules/sdks/php.mdrules/sdks/python.mdrules/sdks/ruby.mdrules/sdks/scala.mdrules/sensitive-data.mdrules/spans.mdrules/telemetry.mdrules/validation.mdInstruments services with OpenTelemetry for RED metrics, structured logs, distributed tracing, and health checks. Outputs code and config for Node.js, Python, Go, Rust, Ruby services.
Provides OpenTelemetry conventions for span naming, semantic attributes, status setting, in-memory trace testing, and instrumentation boundaries. Use when setting up tracing or writing trace tests.
Instruments apps with OpenTelemetry SDKs in Go, Java, Python, Node.js, .NET; configures OTLP endpoints to Grafana Cloud, Alloy collectors, Kubernetes Operator, sampling, and migrations.
Share bugs, ideas, or general feedback.
Expert guidance for implementing high-quality, cost-efficient OpenTelemetry telemetry.
| Use Case / Rule | Description |
|---|---|
| telemetry | Entrypoint — signal types, correlation, and navigation |
| resolve-values | Resolving configuration values from the codebase |
| resources | Resource attributes — service identity and environment |
| k8s | Kubernetes deployment — downward API, pod spec |
| spans | Spans — naming, kind, status, and hygiene |
| logs | Logs — structured logging, severity, trace correlation |
| metrics | Metrics — instrument types, naming, units, cardinality |
| sensitive-data | Sensitive data — PII prevention, sanitization, redaction |
| validation | Telemetry validation — post-deployment verification checklist |
| nodejs | Node.js instrumentation setup |
| go | Go instrumentation setup |
| python | Python instrumentation setup |
| java | Java instrumentation setup |
| scala | Scala instrumentation setup |
| dotnet | .NET instrumentation setup |
| ruby | Ruby instrumentation setup |
| php | PHP instrumentation setup |
| browser | Browser instrumentation setup |
| nextjs | Next.js full-stack instrumentation (App Router) |
Follow these steps when instrumenting an application from scratch:
The snippet below shows a complete span with attributes and status for Node.js — see nodejs for full setup including SDK initialisation, exporter configuration, and auto-instrumentation:
const { trace, SpanStatusCode } = require('@opentelemetry/api');
const tracer = trace.getTracer('my-service', '1.0.0');
tracer.startActiveSpan('operation-name', async (span) => {
try {
span.setAttribute('user.id', userId);
span.setAttribute('order.id', orderId);
const result = await processOrder(orderId);
span.setAttribute('order.status', result.status);
span.setStatus({ code: SpanStatusCode.OK });
return result;
} catch (err) {
span.setStatus({ code: SpanStatusCode.ERROR, message: err.message });
span.recordException(err);
throw err;
} finally {
span.end();
}
});
Every telemetry item should serve one of three purposes:
If it doesn't serve one of these purposes, don't emit it.
Use the AlwaysOn sampler (the default) in every SDK.
Do not configure SDK-side samplers — they make irreversible decisions before the outcome of a request is known.
Defer all sampling to the Collector, where policies can be changed centrally without redeploying applications.
SDK (AlwaysOn) → Collector (sampling) → Backend (retention)
↓ ↓ ↓
All spans Head or tail Storage policies
exported sampling applied