Dynatrace is a strong full-stack APM, but its consumption pricing, DPS, host-hours, and per-capability add-ons, is hard to forecast, and the bill tends to climb as you instrument more of the estate. Teams that want predictable, self-hosted cost and no platform lock-in increasingly move to the open Grafana stack. This is not a like-for-like swap, though: you are trading a single integrated agent and an opinionated AI engine for a composable open-source toolkit you assemble and run yourself. Go in clear-eyed about that trade.
The architectural shift: one agent → OpenTelemetry
Dynatrace’s magic is OneAgent, drop it on a host and it auto-discovers and instruments everything. Grafana has no equivalent single agent; the open-source answer is OpenTelemetry (OTel). You instrument services with OTel SDKs and run OTel Collectors to gather metrics, logs, and traces, then route each signal to its backend:
- Metrics → Prometheus or Grafana Mimir (for long-term, scalable storage)
- Logs → Grafana Loki
- Traces → Grafana Tempo
- Visualisation + alerting → Grafana
The Grafana Alloy collector (or the upstream OTel Collector) is the workhorse that replaces what OneAgent did automatically. Expect to do explicitly what Dynatrace inferred for you, that is the cost of openness, and also the source of the savings.
Two things make this shift smoother than it first looks. First, OTel is vendor-neutral, so the instrumentation you add is not tied to Grafana; if you later change any backend, the SDKs and collectors stay put. Second, auto-instrumentation libraries already cover common frameworks and HTTP/database clients per language, so many services light up without hand-written spans. The effort concentrates on the bespoke services OneAgent used to catch by inspecting the host, so inventory what it was capturing before you remove it.
What you give up: Davis AI
Be honest with stakeholders about this. Dynatrace’s Davis AI does automatic anomaly detection and root-cause analysis out of the box. Grafana alerting is rule-based, you define the conditions. You can layer anomaly detection on top (Grafana ML, or Prometheus-based approaches), but it is not free magic. If your on-call culture leans heavily on Davis auto-RCA, plan for that capability gap rather than discovering it mid-incident.
A staged migration that doesn’t blind you
The cardinal rule: never decommission Dynatrace until the new stack proves itself in parallel.
- Stand up the stack, Grafana + Mimir + Loki + Tempo (self-hosted, or Grafana Cloud if you want managed but open).
- Instrument one service end to end with OTel and confirm metrics, logs, and traces land correctly and correlate.
- Rebuild dashboards for that service in Grafana, port the panels that on-call actually uses, not every Dynatrace screen.
- Recreate alerts as Grafana alerting rules; wire the same notification channels (PagerDuty, Slack, email).
- Dual-run: keep OneAgent and OTel side by side on a representative slice until the Grafana alerts fire correctly for real conditions.
- Roll out in waves by service or team, then remove OneAgent and stop the Dynatrace consumption.
Rebuilding dashboards and alerts
Dynatrace populates its screens automatically from OneAgent’s model; Grafana starts blank, which is a feature if you are disciplined about it. Port the panels on-call actually opens during an incident, not every Dynatrace view, and rebuild them against Mimir, Loki, and Tempo data sources. The query languages differ by signal: metric panels use PromQL, log panels use LogQL, and trace panels use TraceQL, so a single Dynatrace multidimensional analysis view may become two or three panels wired to different backends.
Davis problem alerts have no direct export path. Recreate them as Grafana alerting rules with explicit expressions: a Davis “response time degradation” becomes a PromQL rule over a latency histogram, and a service-availability problem becomes a rule over error-rate or up metrics. Wire the same notification channels you used before (PagerDuty, Slack, email) so the paging path is unchanged even though the detection logic is now yours. Rebuild the alerts that page humans first and validate each against a real condition during the dual-run.
Gotchas worth flagging
- Cardinality and retention drive your cost now. Self-hosting means you own storage sizing, high-cardinality labels in Mimir/Loki can balloon resource use. Set retention and label hygiene deliberately.
- Trace sampling is your decision in OTel, tune head/tail sampling so you keep useful traces without storing everything.
- Instrumentation coverage is the long pole. Auto-instrumentation libraries cover common frameworks; bespoke services need manual spans. Inventory what OneAgent was capturing so you don’t silently lose visibility.
What to do next
Dynatrace → Grafana swaps predictable-quality-but-unpredictable-cost for predictable cost and full control, at the price of running the stack yourself and replacing Davis AI with explicit alerting. Standardise on OpenTelemetry first, dual-run before you cut anything over, and migrate by service in waves. Model the removed DPS/host-hour consumption against the infra and engineering time to run Mimir/Loki/Tempo in the calculator above, the savings are real but they are partly traded for operational ownership. The figures there are illustrative, not a Dynatrace quote, so validate them against your own consumption record and the number of services you actually need to re-instrument before you commit to a date.