PR #264 dashboards: rewrite LogQL from json-extract to OTLP-native structured-metadata filters (#278 follow-up)

[trilamsr]

Problem

PR #278 (Loki backend recipe) review found a cross-PR drift:

• Recipe documents native OTLP path (/otlp/v1/logs with OTLP-log-attribute → structured-metadata mapping)
• PR feat(dashboards): grafana JSON for pattern verdicts #264 dashboard panels use | json pattern_id="attributes_pattern_id" form, which requires JSON-stringified log body (Promtail/Alloy shape, NOT OTLP-native)

Operators following the Loki recipe AND importing the dashboard see empty verdict panels.

Root cause

The dashboard was authored before the Loki recipe shipped. Author assumed Promtail/Alloy as the log-ingestion shape. Native OTLP ingestion via Loki 3.0+'s /otlp/v1/logs endpoint puts the attrs into structured metadata, accessible as direct LogQL filters (no | json extraction needed).

Fix

In PR #264 (dashboard) rebase:

• Rewrite all 6 verdict panel LogQL queries from | json pattern_id="attributes_pattern_id" ... form to direct structured-metadata filter form: {cluster=~"...", pattern_id="14"} | line_format "{{.headline}}".
• Document the Loki-native assumption in the dashboard README — point at PR docs(integrations): loki backend recipe #278's Loki recipe as the install path.
• If supporting Promtail/Alloy is needed as a fallback, add a second dashboard JSON variant or document the LogQL alternative.

Acceptance

• Operator installs Loki via PR docs(integrations): loki backend recipe #278 recipe + imports dashboard JSON → verdict panels populate.
• No need for | json extraction in any panel query.

Related

• PR feat(dashboards): grafana JSON for pattern verdicts #264 already blocked on feat(processor): promote operator-facing scalar attrs onto verdict records (closes #270) #275 (scalar-attr promotion); rebase should fix both in one cycle.