elastic / elastic/observability-migration-platform

[Datadog] Built-in metric-name coverage is narrow; integration + custom metrics fall through to placeholders (untested)

Open
#307 0 comments 0 reactions 0 assignees View on GitHub
capabilities program:datadog quality source:datadog
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.