elasticsearch sink

Batches `log` events to Elasticsearch via the `_bulk` API endpoint.

The elasticsearch sink is in beta. Please see the current enhancements and bugs for known issues. We kindly ask that you add any missing issues as it will help shape the roadmap of this component.

The elasticsearch sink batches log events to Elasticsearch via the _bulk API endpoint.

Config File

vector.toml (simple)
vector.toml (advanced)
type = "elasticsearch" # must be: "elasticsearch"
inputs = ["my-source-id"]
host = ""
# For a complete list of options see the "advanced" tab above.


The elasticsearch sink batches log up to the batch_size or batch_timeout options. When flushed, Vector will write to Elasticsearch via the _bulk API endpoint. The encoding is dictated by the encoding option. For example:

POST <host>/_bulk HTTP/1.1
Host: <host>
Content-Type: application/x-ndjson
Content-Length: 654
{ "index" : { "_index" : "<index>" } }
{"timestamp": 1557932537, "message": "GET /roi/evolve/embrace/transparent", "host": "Stracke8362", "process_id": 914, "remote_addr": "", "response_code": 504, "bytes": 29763}
{ "index" : { "_index" : "<index>" } }
{"timestamp": 1557933548, "message": "PUT /value-added/b2b", "host": "Wiza2458", "process_id": 775, "remote_addr": "", "response_code": 503, "bytes": 9468}
{ "index" : { "_index" : "<index>" } }
{"timestamp": 1557933742, "message": "DELETE /reinvent/interfaces", "host": "Herman3087", "process_id": 775, "remote_addr": "", "response_code": 503, "bytes": 9700}

How It Works

Buffers & Batches

The elasticsearch sink buffers & batches data as shown in the diagram above. You'll notice that Vector treats these concepts differently, instead of treating them as global concepts, Vector treats them as sink specific concepts. This isolates sinks, ensuring services disruptions are contained and delivery guarantees are honored.

Buffers types

The buffer.type option allows you to control buffer resource usage:




Pros: Fast. Cons: Not persisted across restarts. Possible data loss in the event of a crash. Uses more memory.


Pros: Persisted across restarts, durable. Uses much less memory. Cons: Slower, see below.

Buffer overflow

The buffer.when_full option allows you to control the behavior when the buffer overflows:




Applies back pressure until the buffer makes room. This will help to prevent data loss but will cause data to pile up on the edge.


Drops new data as it's received. This data is lost. This should be used when performance is the highest priority.

Batch flushing

Batches are flushed when 1 of 2 conditions are met:

  1. The batch age meets or exceeds the configured batch_timeout (default: 1 seconds).

  2. The batch size meets or exceeds the configured batch_size (default: 10490000 bytes).

Delivery Guarantee

Due to the nature of this component, it offers a best effort delivery guarantee.

Environment Variables

Environment variables are supported through all of Vector's configuration. Simply add ${MY_ENV_VAR} in your Vector configuration file and the variable will be replaced before being evaluated.

You can learn more in the Environment Variables section.

Health Checks

Health checks ensure that the downstream service is accessible and ready to accept data. This check is performed upon sink initialization.

If the health check fails an error will be logged and Vector will proceed to start. If you'd like to exit immediately upon health check failure, you can pass the --require-healthy flag:

vector --config /etc/vector/vector.toml --require-healthy

And finally, if you'd like to disable health checks entirely for this sink you can set the healthcheck option to false.

Nested Documents

Vector will explode events into nested documents before writing them to Elasticsearch. Vector assumes keys with a . delimit nested fields. You can read more about how Vector handles nested documents in the Data Model document.

Rate Limits

Vector offers a few levers to control the rate and volume of requests to the downstream service. Start with the rate_limit_duration and rate_limit_num options to ensure Vector does not exceed the specified number of requests in the specified window. You can further control the pace at which this window is saturated with the request_in_flight_limit option, which will guarantee no more than the specified number of requests are in-flight at any given time.

Please note, Vector's defaults are carefully chosen and it should be rare that you need to adjust these. If you found a good reason to do so please share it with the Vector team by opening an issie.

Retry Policy

Vector will retry failed requests (status == 429, >= 500, and != 501). Other responses will not be retried. You can control the number of retry attempts and backoff rate with the retry_attempts and retry_backoff_secs options.

Template Syntax

The index options support Vector's template syntax, enabling dynamic values derived from the event's data. This syntax accepts strftime specifiers as well as the {{ field_name }} syntax for accessing event fields. For example:

# ...
index = "vector-%Y-%m-%d"
index = "application-{{ application_id }}-%Y-%m-%d"
# ...

You can read more about the complete syntax in the template syntax section.


To ensure the pipeline does not halt when a service fails to respond Vector will abort requests after 60 seconds. This can be adjsuted with the request_timeout_secs option.

It is highly recommended that you do not lower value below the service's internal timeout, as this could create orphaned requests, pile on retries, and result in deuplicate data downstream.


The best place to start with troubleshooting is to check the Vector logs. This is typically located at /var/log/vector.log, then proceed to follow the Troubleshooting Guide.

If the Troubleshooting Guide does not resolve your issue, please:

  1. If encountered a bug, please file a bug report.

  2. If encountered a missing feature, please file a feature request.

  3. If you need help, join our chat/forum community. You can post a question and search previous questions.