Menü
Verify Datadog telemetry is flowing correctly using MCP tools
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
Create a Datadog demo project — scaffold infrastructure, build domain-specific microservices, and generate demo scenarios. Use when the user asks to create a demo, scaffold a project, set up a Datadog environment, or build a sample application.
Build, deploy, smoke test, and validate a demo project before presenting it. Use after scaffolding or modifying services to ensure everything works end-to-end.
Look up current Datadog documentation via the official LLM-optimized index at docs.datadoghq.com/llms.txt. Use this skill whenever you need accurate, up-to-date Datadog configuration steps, feature details, API references, integration setup, or troubleshooting guidance — even if you think you already know the answer. Datadog docs change frequently and your training data is likely stale. Trigger on any Datadog-related question: agent install, log pipelines, APM setup, DBM, monitors, dashboards, SLOs, integrations, RBAC, cloud cost, synthetics, LLM observability, etc. Also trigger when another dd- prefixed skill needs to reference official documentation.
Generate Terraform for Datadog dashboards tailored to a project's services and active features, enriched with real telemetry data from the Datadog MCP server.
Generate Terraform for Datadog monitors tailored to a project's services and active features, using real telemetry baselines when available.
Configure the Locust traffic generator with domain-specific scenarios that exercise all services, demo golden paths, and trigger failure modes for Datadog visibility.
| name | dd-check-telemetry |
| description | Verify Datadog telemetry is flowing correctly using MCP tools |
| tools | ["file_read"] |
Confirm that a running demo stack is sending telemetry to Datadog. Uses the Datadog MCP server — no fallback.
Read .d-scribe.json for the instrumentation field. When OTel mode is in use, service identity is emitted via OpenTelemetry resource attributes instead of Datadog tracer tags:
| Concept | datadog / ddot | otel |
|---|---|---|
| Service name | service:<name> | service.name:<name> |
| Environment | env:<env> | deployment.environment:<env> |
| Version | version:<v> | service.version:<v> |
When querying the Datadog API for APM spans or LLM Obs traces, use the appropriate tag key for the project's mode. The Datadog intake normalizes both, but pipelines that filter on service: will miss OTel-emitted spans unless they also filter on service.name:.
docker compose up -d).env populated with valid DD_API_KEY and DD_SITEAttempt to list services using the Datadog MCP tools. If MCP tools are not available, stop and inform the user:
Datadog MCP server is required for telemetry verification.
Setup: https://github.com/DataDog/datadog-mcp-server
Do not proceed without MCP — partial checks would give false confidence.
Extract from project files:
docker-compose.yml → list of application service names (exclude datadog-agent, traffic, postgresql, redis, keycloak).env → DD_ENV value (used to scope all queries)AGENTS.md → active features (check for mentions of "Database Monitoring", "RUM", "Profiling")For each application service, query the Datadog service catalog via MCP.
Report: service found with correct env tag, or FAIL with diagnostic hint.
For each service, search recent logs (last 15 minutes) via MCP. Build the query filter based on .d-scribe.json instrumentation:
service:<svc> env:<dd_env>service.name:<svc> deployment.environment:<dd_env>Verify:
dd.trace_id (trace-log correlation is working)Report: log count + correlation status, or FAIL with diagnostic hint.
Search recent traces/spans via MCP. Build the query filter based on .d-scribe.json instrumentation:
service:<svc>service.name:<svc>Verify:
Report: trace count + multi-service trace found, or FAIL with diagnostic hint.
Perform cross-signal verification:
Report each check as PASS or FAIL with diagnostic hint.
Present a structured checklist grouping all results:
Service Registration
[PASS] api-gateway (env: my-demo-260331)
[PASS] user-service
...
Logs
[PASS] api-gateway — 142 logs, trace correlation OK
...
Traces
[PASS] Distributed trace found: api-gateway → user-service → project-service
Correlation
[PASS] Log-to-trace roundtrip
[PASS] Trace-to-log roundtrip
...
For each FAIL, include the diagnostic hint from references/diagnostic-hints.md.
End with a summary: "X/Y checks passed. [All clear / N issues to fix]"