From Datadog to Grafana

Datadog’s per-host-plus-ingest-plus-per-module pricing is one of the least predictable line items in infrastructure. If you tried plain Prometheus and missed Datadog’s unified experience (metrics, logs, and traces in one UI), the full Grafana stack is the closest open replacement, and it comes in both self-hosted and managed (Grafana Cloud) forms. This guide is about that swap.

The Grafana stack maps cleanly to Datadog’s pillars

Datadog bundles several products; Grafana has a component for each:

• Infrastructure & APM metrics → Mimir (long-term, horizontally scalable, Prometheus-compatible) fed by Prometheus/node_exporter or the OpenTelemetry Collector.
• Dashboards → Grafana (the panel you already know).
• Logs → Loki.
• Traces → Tempo, via OpenTelemetry instrumentation.
• Alerts → Grafana Alerting (with routing, silences, paging).

Because Grafana unifies all of these in one UI with correlation across metrics/logs/traces, it reproduces Datadog’s single-pane feel far better than raw Prometheus + Alertmanager alone, which is why teams who want the Datadog experience (not just metrics) pick it.

Self-host vs Grafana Cloud

This is the key decision:

• Self-host the LGTM stack (Loki, Grafana, Tempo, Mimir) for maximum cost control and data ownership, you run and scale it.
• Grafana Cloud is managed with a usage-based model that is typically far cheaper than Datadog and removes the ops burden, a middle ground if you don’t want to operate the stack but do want off Datadog.

Model both; “cheaper than Datadog” is usually true either way, but the ops/cost balance differs. A useful tiebreaker is honest self-assessment of platform capacity: if you already run Kubernetes and have engineers comfortable operating stateful services, self-hosting the LGTM stack captures the most saving. If you want off Datadog’s pricing without taking on that operational load, Grafana Cloud is the middle ground, still open, still OTel-based, but managed. Either way the figures are illustrative, not vendor quotes, so validate against your real metric and log volume before you commit.

A safe migration flow

1. Inventory Datadog dashboards, monitors, integrations, retention, and paging hooks. Export dashboards and monitors via the Datadog API.
2. Stand up the stack (self-host LGTM or provision Grafana Cloud). Instrument hosts/apps with OpenTelemetry (or node_exporter + Prometheus), OTel is the strategic choice since it’s vendor-neutral and feeds Mimir/Tempo/Loki.
3. Rebuild the essentials first, recreate your most important dashboards in Grafana (many Datadog dashboards have community Grafana equivalents) and translate top monitors into Grafana alert rules.
4. Dual-run, keep Datadog and Grafana side by side; compare coverage and alert fidelity.
5. Cut over paging to Grafana Alerting/OnCall once trusted, then remove Datadog agents.

The real work: instrumentation and alert fidelity

Datadog’s agent auto-discovers a lot; with Grafana you own the OpenTelemetry pipeline and the query language (PromQL/LogQL/TraceQL). Budget time for your on-call team to get fluent, and watch metric cardinality, high-cardinality custom metrics are what made Datadog expensive and will size your Mimir/Loki storage too.

Three query languages, not one

Grafana speaks three query languages where Datadog had one, and each of your signals crosses into a different one:

• Metric monitors → PromQL over Mimir. Rates need an explicit range like rate(...[5m]), and percentile monitors become histogram_quantile() over a histogram you must be exporting.
• Log monitors → LogQL over Loki. Datadog log queries filter richly indexed fields; Loki filters by a few stable labels and then greps within, so a query that leaned on high-cardinality attributes needs rethinking, not translating.
• Trace-based monitors → TraceQL over Tempo, which is newer and less familiar than the Datadog trace UI.

Rebuild the monitors that page humans first and confirm each fires on a real condition. Grafana Alerting handles routing, grouping, and silences, but the alert expressions themselves are yours to author.

What doesn’t port cleanly

The Grafana stack is the closest match, but it is not identical:

• Auto-instrumentation breadth. OneAgent-style “drop it on and everything appears” is not how OTel works; you enable auto-instrumentation per language and add manual spans for bespoke services.
• RUM and Synthetics. Real-user monitoring has thinner OSS coverage; plan uptime checks and front-end monitoring separately.
• Turnkey integrations. Many Datadog integrations are one-click; the OTel and exporter equivalents exist but you assemble and maintain them.

What actually drives the new bill

Whether you self-host or use Grafana Cloud, cardinality and retention drive the bill. The high-cardinality custom metrics that inflated Datadog will size Mimir, and verbose or long-retention logs will size Loki, so treat the move as a chance to prune. Keep labels bounded, set retention deliberately per signal, and let Mimir handle long-term metric storage rather than over-provisioning ingestion. Model self-host infrastructure and engineering time against Grafana Cloud’s usage pricing in the calculator above; “cheaper than Datadog” is usually true either way, but the ops-versus-cost balance is the real decision.

The acceptance bar

Fire test alerts end to end (trigger → Grafana Alerting → pager → ack), do a dashboard parity review on what matters, and run a retention/scale test. Acceptance bar: “we get paged correctly for the incidents we care about, and the dashboards we rely on are reproduced.”

Where this leaves you

Datadog → Grafana is the closest thing to a like-for-like move because the Grafana stack unifies metrics, logs, and traces the way Datadog does. Decide self-host vs Grafana Cloud, instrument via OpenTelemetry, dual-run, and cut paging over last. Model your per-host savings in the calculator above, and treat them as illustrative until you validate against your real metric/log volume.