elastic / elastic/observability-migration-platform

[Grafana] Detect Prometheus recording-rule series with no target field; flag instead of emitting silently-empty panels

Open
#310 1 comment 0 reactions 0 assignees View on GitHub
asset:dashboards quality source:grafana workstream:translator
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

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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.