Self-Hosted Observability Directory

Migration playbook

Replace Splunk with OSS log analytics

A practical plan for moving expensive Splunk log search and operational dashboards to open-source log pipelines and search backends.

Vendor Splunk
Timeline 10-14 weeks
Difficulty High

Splunk replacement is more data-platform work than dashboard work. Treat source classification, retention, and query translation as first-class deliverables before moving high-volume ingestion.

Recommended OSS Stack

Vector

High-performance observability data pipeline. Sources, transforms, sinks — written in Rust by Datadog (open source).

MPL-2.0 · Rust · ★ 22000 · Fresh
logsmetrics

Fluent Bit

CNCF graduated lightweight log/metric forwarder. The default in-cluster log shipper for Kubernetes.

Apache-2.0 · C · ★ 8000 · Fresh
logsmetrics

Stack Options

Operational logs with Grafana

Best for: SRE teams that mainly need service logs next to metrics and traces.

Grafana Loki · Grafana · Vector · Fluent Bit

  • Efficient for label-based operational logging, but not a Splunk SPL clone.
  • Query design depends heavily on label discipline and retention tiers.

Search-heavy log lake

Best for: Teams with compliance, audit, and broad text-search workloads.

OpenObserve · Quickwit · Parseable · Vector

  • Better for broad log search, but each backend has its own query model and storage profile.
  • Existing Splunk dashboards and saved searches need manual rewriting.

Migration Phases

  1. Classify Splunk workloads

    2 weeks

    Outcome: Searches, dashboards, indexes, sourcetypes, alerts, and retention policies are grouped by business need.

    • Export saved searches, dashboards, alert rules, and index volume by source.
    • Separate security/compliance use cases from operational observability use cases.
    • Find high-volume low-value sources that should be sampled, dropped, or tiered.

  2. Design ingestion and retention

    2-3 weeks

    Outcome: A log routing plan defines collectors, parsing, redaction, storage tiers, and retention by source.

    • Deploy Vector or Fluent Bit in parallel with current forwarders.
    • Normalize timestamps, service names, severity, environment, and trace IDs.
    • Apply redaction and routing rules before logs reach the new backend.

  3. Port critical searches

    3-5 weeks

    Outcome: The most valuable Splunk searches and dashboards have working equivalents.

    • Rewrite incident-critical SPL queries first and record semantic differences.
    • Rebuild alerts with clear owners, thresholds, and escalation paths.
    • Validate query latency and retention on real production volume.

  4. Shift traffic and archive

    3-4 weeks

    Outcome: New log ingestion defaults to the OSS pipeline and Splunk is reduced to archive or decommissioned.

    • Move source groups in waves, starting with low-risk services.
    • Keep a read-only Splunk archive window for audit and rollback.
    • Publish a query translation guide for common SPL patterns.

Cutover Checklist

  • Log sources have owners and retention classes.
  • PII and secret redaction happens before storage.
  • Top saved searches have documented OSS equivalents.
  • Query latency is acceptable at production ingest volume.
  • Security or compliance use cases are explicitly included or excluded.
  • A rollback path exists for each source migration wave.

Risks To Manage

  • SPL-heavy workflows rarely translate automatically to another query language.
  • Undisciplined labels or indexes can create expensive storage and slow searches.
  • Security teams may depend on Splunk in ways that are invisible to SRE-owned dashboards.

Back to migration playbooks