The Prometheus exporter emits metrics under names that don't match Harper's native metric names. This divergence has been a recurring source of pain (dashboards built against one source don't work against the other), and currently blocks rollout of the native Grafana datasource plugin to customers who already have Prometheus-exporter-backed dashboards. The platform team has been working around it with an Alloy sidecar — not a scalable solution.
Goal
Make the Prometheus exporter emit Harper-native metric names by default. Offer a configurable name-mangling step to produce Prometheus-style names for users who need legacy dashboard compatibility — an opt-in shim, not the default.
Why not match prom-style at the source
Renaming Harper-native metrics to Prometheus conventions has caused more headaches than it has solved. Once Harper-native names are the source of truth, all consumers (native Grafana datasource, Prometheus exporter, dashboards, exporters yet to be built) share a single vocabulary.
Scope
- Default behavior: Prometheus exporter outputs metric names matching Harper-native names (with whatever sanitization Prometheus itself requires, e.g.
- → _, but otherwise verbatim).
- Opt-in compatibility: A configuration option (e.g.
nameStyle: 'legacy-prom' or a mapping table) that re-applies the current prom-style names so existing customer dashboards keep working unchanged.
- Migration guidance: Document the new default, the available mapping, and how to migrate a dashboard.
Acceptance criteria
- New exporter installs produce Harper-native metric names by default.
- Existing customers can opt into legacy naming with a single config change and keep their dashboards working.
- Documentation calls out the change and the migration path.
Where this lives
Primary home: HarperFast/prometheus-exporter (this issue) — the name-mangling shim and config option live here.
Out of scope
- Killing the Alloy sidecar — downstream platform concern once dashboards work natively.
- Changes to the native Grafana datasource — it already speaks Harper-native names, so no changes expected once the exporter aligns.
Tracked in Jira: CORE-3044
🤖 Filed by Claude on behalf of Kris.
The Prometheus exporter emits metrics under names that don't match Harper's native metric names. This divergence has been a recurring source of pain (dashboards built against one source don't work against the other), and currently blocks rollout of the native Grafana datasource plugin to customers who already have Prometheus-exporter-backed dashboards. The platform team has been working around it with an Alloy sidecar — not a scalable solution.
Goal
Make the Prometheus exporter emit Harper-native metric names by default. Offer a configurable name-mangling step to produce Prometheus-style names for users who need legacy dashboard compatibility — an opt-in shim, not the default.
Why not match prom-style at the source
Renaming Harper-native metrics to Prometheus conventions has caused more headaches than it has solved. Once Harper-native names are the source of truth, all consumers (native Grafana datasource, Prometheus exporter, dashboards, exporters yet to be built) share a single vocabulary.
Scope
-→_, but otherwise verbatim).nameStyle: 'legacy-prom'or a mapping table) that re-applies the current prom-style names so existing customer dashboards keep working unchanged.Acceptance criteria
Where this lives
Primary home:
HarperFast/prometheus-exporter(this issue) — the name-mangling shim and config option live here.Out of scope
Tracked in Jira: CORE-3044
🤖 Filed by Claude on behalf of Kris.