elastic / elastic/observability-migration-platform
[Datadog] Built-in metric-name coverage is narrow; integration + custom metrics fall through to placeholders (untested)
- Dominant language
- Python
- Stars
- 6
- Forks
- 8
- Avg merge
- 2d 22h
- Merged PRs (30d)
- 23
Description
## Context
Verified via live runs. Under all built-in profiles, only `elastic_agent` maps metric *names*, and only for common `system.*` metrics (~18 entries). Everything else is dot-to-underscore flattened:
- **Integration metrics** (`mysql.*`, `postgresql.*`, `rabbitmq.*`, `kubernetes.*`) -> placeholders.
- **Custom app metrics** (`my.app.orders`) -> placeholders.
Operators can fix this with `--metric-map-file`, but there is no built-in dictionary and no test fixture proving integration/custom metric migration beyond generic parse/translate.
## Ask
1. Expand built-in metric-name coverage for the common Datadog integrations (start with the ones we ship dashboards for: kubernetes, docker, nginx, postgres, mysql, redis, ...).
2. Add matrix cells + fixtures that assert integration and custom metric mapping (not just parsing).
3. Refresh committed fidelity baselines only for the intentional coverage change (per `tests/e2e/test_fidelity_ratchet.py`).
## Acceptance
- New/expanded profile or bundled integration map covering the shipped integration dashboards.
- `tests/core/coverage/` + panel matrices updated so a regression fails CI.
- `docs/sources/datadog.md` coverage table updated.
Related: #306 (default profile). Docs already clarify that `otel` maps tags, not metric names.
Contributor guide
Research direction
Start with the existing fixtures and matrix cells under tests/core/coverage/, then read tests/e2e/test_fidelity_ratchet.py to understand baseline updates. Trace the built-in profile or bundled integration maps used by those tests. Done means integration and custom metric cases fail on regression, intentional fidelity baselines are refreshed, and the coverage table in docs/sources/datadog.md is updated.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- documentation, testing, tooling
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 52/100