clickhouse sink

Batches `log` events to Clickhouse via the `HTTP` Interface.

The clickhouse 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 clickhouse sink batches log events to Clickhouse via the HTTP Interface.

Config File

vector.toml (example)
vector.toml (schema)
vector.toml (specification)
[sinks.my_sink_id]
# REQUIRED - General
type = "clickhouse" # must be: "clickhouse"
inputs = ["my-source-id"]
host = "http://localhost:8123"
table = "mytable"
# OPTIONAL - General
database = "mydatabase" # no default
healthcheck = true # default
# OPTIONAL - Batching
batch_size = 1049000 # default, bytes
batch_timeout = 1 # default, seconds
# OPTIONAL - Requests
compression = "gzip" # no default, must be: "gzip" (if supplied)
rate_limit_duration = 1 # default, seconds
rate_limit_num = 5 # default
request_in_flight_limit = 5 # default
request_timeout_secs = 30 # default, seconds
retry_attempts = 9223372036854775807 # default
retry_backoff_secs = 9223372036854775807 # default, seconds

Options

Key

Type

Description

REQUIRED - General

type

string

The component type required must be: "clickhouse"

inputs

[string]

A list of upstream source or transform IDs. See Config Composition for more info. required example: ["my-source-id"]

host

string

The host url of the Clickhouse server. required example: "http://localhost:8123"

table

string

The table that data will be inserted into. required example: "mytable"

OPTIONAL - General

database

string

The database that contains the stable that data will be inserted into. no default example: "mydatabase"

healthcheck

bool

Enables/disables the sink healthcheck upon start. See Health Checks for more info. default: true

OPTIONAL - Batching

batch_size

int

The maximum size of a batch before it is flushed. default: 1049000 unit: bytes

batch_timeout

int

The maximum age of a batch before it is flushed. default: 1 unit: seconds

OPTIONAL - Requests

compression

string

The compression type to use before writing data. See Compression for more info. no default must be: "gzip"

rate_limit_duration

int

The window used for the request_rate_limit_num option See Rate Limits for more info. default: 1 unit: seconds

rate_limit_num

int

The maximum number of requests allowed within the rate_limit_duration window. See Rate Limits for more info. default: 5

request_in_flight_limit

int

The maximum number of in-flight requests allowed at any given time. See Rate Limits for more info. default: 5

request_timeout_secs

int

The maximum time a request can take before being aborted. See Timeouts for more info. default: 30 unit: seconds

retry_attempts

int

The maximum number of retries to make for failed requests. See Retry Policy for more info. default: 9223372036854775807

retry_backoff_secs

int

The amount of time to wait before attempting a failed request again. See Retry Policy for more info. default: 9223372036854775807 unit: seconds

How It Works

Compression

The clickhouse sink compresses payloads before flushing. This helps to reduce the payload size, ultimately reducing bandwidth and cost. This is controlled via the compression option. Each compression type is described in more detail below:

Compression

Description

gzip

The payload will be compressed in Gzip format before being sent.

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.

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.

Timeouts

To ensure the pipeline does not halt when a service fails to respond Vector will abort requests after 30 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.

Troubleshooting

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.

Resources