How to Move from Elasticsearch to Loki Without Losing Incident Queries

Start with a query inventory

Ask responders for the searches they use during an incident: errors for one service after deployment, a failing request's path, or a sudden increase in a particular exception. Record the filters, time window, required fields and what decision the result supports.

Separate these searches from long-term audit or business-analysis requirements. Different retention, search and access needs may justify different storage paths. Moving incident logs does not automatically replace every use of the original Elasticsearch system.

Design stream identity deliberately

Loki's label documentation (opens in a new tab) explains its label-based stream model and the importance of cardinality. Choose a small set of bounded attributes that narrow incident searches, such as service and environment, according to the deployment's actual volume and topology.

Avoid promoting request identifiers, user identifiers or unpredictable error messages into stream labels. Keep relevant details in structured log content or a supported metadata mechanism, with access and retention appropriate to the data.

A label choice that works in a tiny pilot may become expensive during a deployment with thousands of changing instances. Include churn in the volume test.

Recreate the investigation in LogQL

LogQL log-query documentation (opens in a new tab) describes stream selectors, filters and parsers. Translate one investigation at a time and inspect raw matching records before adding aggregates.

For an illustrative JSON log format, this query selects a service stream and parses its level field:

{service_name="checkout", environment="production"}
  | json
  | level="error"

The labels and field names must match your collector output. Test malformed JSON, absent fields and records with different schemas. A query that silently excludes parse failures can make the migration appear cleaner than the source data actually is.

Compare the same retained dataset

Use a fixed UTC window and a known set of log records available in both systems. Compare counts, representative records, time ordering and the ability to follow a known request. Include a rare error signature so a dominant common error does not hide missing coverage.

Record differences caused by ingestion delay, multiline parsing, timestamp selection or retention. Do not claim strict parity when the two systems received different input. The comparison should identify what changed and whether that change affects response.

Measure query time and resource usage under representative volume. A search that works on a ten-minute sample may not remain practical across a broad incident window.

Migrate links and access before switching defaults

Update alert links and runbooks with the new query context, including service and time window. Verify that responders can access their authorized logs and cannot cross tenant boundaries through a shared query interface.

Run a recorded incident exercise using only the candidate logs. Keep the old source available for an agreed fallback period and track unresolved investigations individually. Retire it only after the required queries, retention and permissions have an accepted replacement; a dashboard showing incoming log volume is not sufficient evidence.