From Splunk to Grafana

Splunk is powerful, and its ingest-based licensing (priced largely per GB per day) makes high log volume expensive and retention a budgeting problem. The common open-source replacement is Grafana for visualization paired with Loki for logs, extended with Mimir for metrics and Tempo for traces. The catch is that Loki is architecturally different from Splunk, so this is a re-platform with a real mindset shift, not a like-for-like swap.

Why teams leave Splunk

It’s rarely the product, it’s the cost curve of ingest. Every additional GB per day and every extra retention day raises the bill, and premium apps add more. Teams with the engineering capacity to run their own stack can cut spend dramatically, trading a managed platform for operational ownership.

The core architectural difference

This is the part to internalize before anything else. Splunk indexes your data heavily and lets you search across it flexibly. Loki indexes only labels and stores the raw log lines as compressed chunks in object storage (S3/GCS), then filters them grep-style at query time. The result is far cheaper storage at volume, but the query patterns differ, and a Splunk habit becomes an anti-pattern: high-cardinality labels (user IDs, request IDs) wreck Loki performance. You filter by a few stable labels (app, environment, host) and then search within, rather than indexing every field.

The mapping

• Splunk indexers → Loki (chunks in object storage).
• SPL searches → LogQL, a different language and model.
• Dashboards → Grafana.
• Splunk alerts → Grafana alerting.
• Universal/Heavy Forwarders → Grafana Alloy, Promtail, or the OpenTelemetry Collector.
• Metrics (if you used Splunk for them) → Prometheus/Mimir; traces → Tempo.
• Apps / Technology Add-ons → manual reimplementation.

Translating SPL searches to LogQL

This is where most of the migration effort actually lands, because it is a redesign, not a find-and-replace. A useful way to think about it: in SPL you search first and narrow later; in LogQL you select labels first and search within.

• Stream selection replaces the base search. Start every LogQL query by matching a small set of stable labels ({app="checkout", env="prod"}), then apply line filters (|= "error") and parsers (| json, | logfmt) to pull fields out at query time.
• stats and timechart become metric queries. Aggregations like counts and rates over time map to LogQL’s count_over_time, rate, and sum by (...), often after unwrap for numeric fields.
• eval and rex field extraction happen at query time via parser expressions rather than being baked into indexed fields.
• Cardinality is the trap. Any SPL search that keyed on a high-cardinality field is the one most likely to perform badly if you naively lift it into a label. Reshape it to filter within a stream instead.

Rebuild the highest-value saved searches first and confirm each returns what the Splunk original did before you retire it.

The premium-app gap (be honest about this)

Loki and Grafana replace logging and dashboards well. They do not drop-in replace Splunk’s premium solutions, Enterprise Security (SIEM) and ITSI. If those are why you run Splunk, scope a separate path: an open SIEM such as Wazuh or the Elastic stack, or a dedicated security product. Pretending Grafana covers ES is how migrations stall.

A safe migration flow

1. Inventory dashboards, saved searches, alerts, sourcetypes, retention, and downstream hooks (ticketing/paging).
2. Deploy the stack: Loki with object storage, Grafana, and Alloy/OTel collectors. Point a subset of sources at it first.
3. Rebuild the essentials: translate your highest-value searches into LogQL and recreate the dashboards and alerts that page humans, not everything on day one.
4. Dual-ingest. Send logs to both Splunk and Loki during validation, and compare coverage, alert fidelity, and false-positive rates.
5. Cut over forwarders to the new collectors once you trust the alerts, then retire the indexers after the retention window closes.

Where the cost goes now

Splunk’s spend was driven by GB per day ingested and by retention; Loki changes the shape of both. Because it indexes only labels and stores compressed chunks in object storage, storage at volume gets much cheaper, but the cost moves to object storage, query compute, and the engineering time to run the stack. The dials that matter are label cardinality (keep labels to a few stable dimensions so stream counts stay bounded), retention (set it per stream deliberately, long retention at high volume is exactly what made Splunk expensive), and how much you parse at query time versus index. Treat the cutover as a chance to drop sourcetypes and verbose logs nobody queries, rather than lifting every Splunk index over unchanged.

Before you switch anything off

Set retention and object-storage sizing deliberately, long retention at volume is exactly what made Splunk expensive, and it sizes your Loki storage too. Fire test alerts end to end (trigger → Grafana alerting → pager → ack), do a dashboard parity review on the data that matters, and load-test query performance with realistic label cardinality before switching anything off.

So, is it worth it?

Splunk → Grafana/Loki is primarily a cost and ownership decision. Logs and dashboards migrate well; the work is learning LogQL, enforcing label-cardinality discipline, and accepting that Splunk’s SIEM/ITSI tiers need a separate plan. Dual-ingest, prove alert fidelity, then cut over forwarders last. Model your per-host and ingest savings in the calculator above, and validate them against a real quote, self-hosting trades license cost for engineering time and storage.