elastic / elastic/observability-migration-platform
[Grafana] Detect Prometheus recording-rule series with no target field; flag instead of emitting silently-empty panels
- Dominant language
- Python
- Stars
- 6
- Forks
- 8
- Avg merge
- 2d 22h
- Merged PRs (30d)
- 23
Description
## Problem statement
PromQL dashboards frequently reference **Prometheus recording rules**: precomputed series with colon-separated names (e.g. `node_namespace_pod_container:...:sum_rate5m`, `cluster:namespace:pod_cpu:active:...`). These series are materialized by Prometheus at eval time and do not exist in any non-Prometheus target (OTLP, bulk, etc.).
Today the migrator translates them into ordinary field references and marks the panel `migrated` / `migrated_with_warnings`, so on a non-Prometheus target the panel renders empty with no signal that the underlying series is structurally absent. This is distinct from metric-name mapping (#309): a recording rule has **no single target field to rename to**; its value must be recomputed from base metrics or the panel redesigned.
## Proposed change (general capability)
- Detect recording-rule-style identifiers during classification (colon-separated names are the canonical spelling).
- When the target is not a Prometheus-recording-rule-bearing index, either:
- mark the target/panel `not_feasible` (or a dedicated data-readiness state) with a clear reason, and/or
- flag it in `required_target_contract.json` as recording-rule-derived and absent, and/or
- where the base expression is recoverable, emit a redesign task with the base-metric ES|QL equivalent.
- Surface it in the run summary and manifest reasons so an empty panel is not mistaken for a fixable data gap.
Preserve degrade-gracefully; do not hide the semantic gap.
## Source / target impact
Grafana source → any non-Prometheus target. Broadly affects kube-prometheus-stack / kubernetes-mixin and any dashboard built on recording rules.
## Additional context
Classification in `observability_migration/adapters/source/grafana/rules.py` / `promql.py` / `translate.py`. Related: #309, #271, #311.
Contributor guide
Research direction
Start in observability_migration/adapters/source/grafana/rules.py, promql.py, and translate.py, following how PromQL identifiers are classified and translated. Trace the run summary and manifest reason paths. Done means recording-rule-style identifiers targeting non-Prometheus data are visibly flagged as absent or not feasible rather than producing silently empty panels, while graceful degradation remains intact.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- grafana, prometheus, python
- Domain
- observability-sre
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100