Elasticsearch

The Elasticsearch service lets your agent talk to a mock Elasticsearch 8.x cluster during simulations, using the same APIs and query languages it uses in production. Your agent connects with elasticsearch-py, any Elastic SDK, or plain HTTP — nothing about the client code needs to change.

Requirements

Most apps need two steps:

1. Enable the Elasticsearch service in veris.yaml →

2. Upload a log dataset via the Console →

If your agent only calls cluster / index management endpoints, the dataset is optional — but any call to _search, _query, or _count needs data to return anything meaningful. The upload format is log-oriented (see the note above) — CSV rows or NDJSON events with a time field.

Enable the service

Add the service to veris.yaml:

services:
  - name: elastic

That gives your simulation a mock Elasticsearch endpoint. Requests to *.elastic-cloud.com are routed to the mock service automatically via DNS interception.

Provide your log data

Upload a log file via the Datasets section on your Environment page in the Console. Select the elastic service, choose CSV or NDJSON as the format, and upload your file.

One dataset per service per environment. The data is loaded into a queryable store that compiles Query DSL into SQL at request time, so schema is inferred from your upload — you don’t need to declare index mappings.

To replace an existing dataset, delete the current one from the Datasets section first, then upload the new file. Attempting to upload a second dataset for the same service returns a 409 conflict.

Query languages

The service supports both of Elasticsearch’s query surfaces.

Query DSL

Standard JSON queries via POST /_search or POST /{index}/_search. These are compiled deterministically (no LLM in the hot path) into SQL against the uploaded dataset.

{
  "query": {
    "bool": {
      "must": [
        {"term": {"status": "error"}},
        {"range": {"@timestamp": {"gte": "2025-01-01T00:00:00Z"}}}
      ]
    }
  }
}

Supported query clauses:

Supported aggregations:

Dotted field names (http.response.status_code) are resolved against the flattened column schema automatically.

If the deterministic compiler fails on a query it doesn’t recognize, the request falls through to an LLM-backed translator as a top-level safety net. Within a compiled query, however, unknown sub-clauses (e.g. prefix, fuzzy, span_*) are logged and silently dropped rather than LLM-translated — a query that mixes supported and unsupported clauses will match more broadly than intended. Stick to the clauses in the table above.

ES|QL

Text-based pipe queries via POST /_query:

{
  "query": "FROM logs-* | WHERE status == \"error\" | STATS count = COUNT(*) BY host"
}

ES|QL is translated via LLM rather than deterministic compilation, so expect a little more latency than Query DSL for equivalent queries.

Endpoints

Beyond search, the mock implements the endpoints most SDKs need during startup, ingest, and teardown:

The cluster reports itself as Elasticsearch 8.15.0 with a single data/ingest/master node, which is enough to satisfy most client libraries’ handshakes.

Connect your app

Point your Elasticsearch client at the mock the same way you’d point it at Elastic Cloud. For example, with elasticsearch-py:

services:
  - name: elastic
 
agent:
  environment:
    ELASTICSEARCH_URL: https://my-cluster.es.us-east-1.elastic-cloud.com

The hostname doesn’t matter — DNS interception routes any *.elastic-cloud.com request to the mock service. Use whatever URL your production code already expects.

Troubleshooting

Searches return zero hits. Check that a dataset is uploaded for the elastic service on this environment and that the fields your query references actually exist in the uploaded file. The service infers schema from the upload, so a typo’d field name silently matches nothing.

ES|QL queries are slow or flaky. ES|QL uses an LLM translator. For hot-path queries, prefer Query DSL, which compiles deterministically.

Unsupported Query DSL clause. Top-level unsupported shapes fall back to the LLM translator, but unknown sub-clauses inside an otherwise supported query are dropped silently — the query still runs, just without that filter. If you’re getting more hits than you expect, check that every clause you’re using is in the supported table above.

Date-math expressions match nothing. range filters using now-1h / now-1d style expressions are not translated to real timestamps — they’re treated as literal strings and compared lexicographically against your time column, which effectively matches nothing. Use absolute ISO-8601 timestamps instead.

Related docs

• Services
• Log Management Services
• veris.yaml Reference