From Prometheus + Grafana to Obsfly

• DIY observability has a hidden cost — Prometheus storage, Grafana maintenance, exporter compatibility, alert tuning.
• Postgres / MySQL / Mongo exporters need per-engine domain knowledge to set up correctly.
• No anomaly detection out of the box.
• Query-level telemetry (pg_stat_statements aggregation) doesn't fit Prometheus's metric model.

Fairness signal — useful in renewal conversations.

• Free and open. No vendor lock-in for your metric data.
• Best-in-class for non-DB infrastructure telemetry.

1. Step 1

   Keep Prometheus for non-DB metrics

   Don't replace your full telemetry stack. Obsfly augments it.

2. Step 2

   Install Obsfly for query-level coverage

   Replaces postgres_exporter, mysqld_exporter, mongo_exporter. Query and plan telemetry replaces what Prom can't model.

3. Step 3

   Bridge metrics if needed

   Obsfly exposes a Prometheus-compatible scrape endpoint — point Grafana at it for unified dashboards.

4. Step 4

   Migrate per-engine alerts

   Per-DB Prom alert rules → Obsfly forecast-violation rules covering the same metric.

• Don't disable existing exporters mid-migration; let them coexist.
• Verify that custom exporter metrics you depend on are also surfaced by Obsfly.

Can we keep using Grafana?

Yes. Obsfly's scrape endpoint speaks Prometheus, so Grafana panels work unchanged.

What about long-term storage?

Obsfly retains DB telemetry per-tier. Use Prometheus / VictoriaMetrics / Mimir for long-term non-DB metrics.