Kafka

NAME	RUNTIME	TYPE	VERSION
kafka_franz	wombat	source	latest

A Kafka input using the https://github.com/twmb/franz-go[Franz Kafka client library^].

When a consumer group is specified this input consumes one or more topics where partitions will automatically balance across any other connected clients with the same consumer group. When a consumer group is not specified topics can either be consumed in their entirety or with explicit partitions.

The following metadata fields are added to each message:

- kafka_key
- kafka_topic
- kafka_partition
- kafka_offset
- kafka_timestamp_ms
- kafka_timestamp_unix
- kafka_tombstone_message
- All record headers

Configuration

Name	Type	Optional	Secret	Description
seed_brokers	[]string	no	no	A list of broker addresses to connect to in order to establish connections. If an item of the list contains commas it will be expanded into multiple addresses.
client_id	string	yes	no	An identifier for the client connection. The value defaults to `"benthos"`.
tls	tls	no	no	Custom TLS settings can be used to override system defaults.
sasl	[]string	no	no	Specify one or more methods of SASL authentication. SASL is tried in order; if the broker supports the first mechanism, all connections will use that mechanism. If the first mechanism fails, the client will pick the first supported mechanism. If the broker does not support any client mechanisms, connections will fail.
metadata_max_age	string	yes	no	The maximum age of metadata before it is refreshed. The value defaults to `"5m"`.
topics	[]string	no	no	A list of topics to consume from. Multiple comma separated topics can be listed in a single element. When a `consumer_group` is specified partitions are automatically distributed across consumers of a topic, otherwise all partitions are consumed.

				Alternatively, it's possible to specify explicit partitions to consume from with a colon after the topic name, e.g. `foo:0` would consume the partition 0 of the topic foo. This syntax supports ranges, e.g. `foo:0-10` would consume partitions 0 through to 10 inclusive.

				Finally, it's also possible to specify an explicit offset to consume from by adding another colon after the partition, e.g. `foo:0:10` would consume the partition 0 of the topic foo starting from the offset 10. If the offset is not present (or remains unspecified) then the field `start_from_oldest` determines which offset to start from.
regexp_topics	bool	yes	no	Whether listed topics should be interpreted as regular expression patterns for matching multiple topics. When topics are specified with explicit partitions this field must remain set to `false`. The value defaults to `false`.
rack_id	string	yes	no	A rack specifies where the client is physically located and changes fetch requests to consume from the closest replica as opposed to the leader replica. The value defaults to `""`.
start_from_oldest	bool	yes	no	Determines whether to consume from the oldest available offset, otherwise messages are consumed from the latest offset. The setting is applied when creating a new consumer group or the saved offset no longer exists. The value defaults to `true`.
fetch_max_bytes	string	yes	no	Sets the maximum amount of bytes a broker will try to send during a fetch. Note that brokers may not obey this limit if it has records larger than this limit. This is the equivalent to the Java fetch.max.bytes setting. The value defaults to `"50MiB"`.
fetch_max_wait	string	yes	no	Sets the maximum amount of time a broker will wait for a fetch response to hit the minimum number of required bytes. This is the equivalent to the Java fetch.max.wait.ms setting. The value defaults to `"5s"`.
fetch_min_bytes	string	yes	no	Sets the minimum amount of bytes a broker will try to send during a fetch. This is the equivalent to the Java fetch.min.bytes setting. The value defaults to `"1B"`.
fetch_max_partition_bytes	string	yes	no	Sets the maximum amount of bytes that will be consumed for a single partition in a fetch request. Note that if a single batch is larger than this number, that batch will still be returned so the client can make progress. This is the equivalent to the Java fetch.max.partition.bytes setting. The value defaults to `"1MiB"`.
consumer_group	string	no	no	An optional consumer group to consume as. When specified the partitions of specified topics are automatically distributed across consumers sharing a consumer group, and partition offsets are automatically committed and resumed under this name. Consumer groups are not supported when specifying explicit partitions to consume from in the `topics` field.
checkpoint_limit	int	yes	no	Determines how many messages of the same partition can be processed in parallel before applying back pressure. When a message of a given offset is delivered to the output the offset is only allowed to be committed when all messages of prior offsets have also been delivered, this ensures at-least-once delivery guarantees. However, this mechanism also increases the likelihood of duplicates in the event of crashes or server faults, reducing the checkpoint limit will mitigate this. The value defaults to `1024`.
commit_period	string	yes	no	The period of time between each commit of the current partition offsets. Offsets are always committed during shutdown. The value defaults to `"5s"`.
multi_header	bool	yes	no	Decode headers into lists to allow handling of multiple values with the same key. The value defaults to `false`.
batching	batching	no	no	Allows you to configure a batching policy that applies to individual topic partitions in order to batch messages together before flushing them for processing. Batching can be beneficial for performance as well as useful for windowed processing, and doing so this way preserves the ordering of topic partitions.
auto_replay_nacks	bool	yes	no	Whether messages that are rejected (nacked) at the output level should be automatically replayed indefinitely, eventually resulting in back pressure if the cause of the rejections is persistent. If set to `false` these messages will instead be deleted. Disabling auto replays can greatly improve memory efficiency of high throughput streams as the original shape of the data can be discarded immediately upon consumption and mutation. The value defaults to `true`.

TLS Configuration

Name	Type	Optional	Secret	Description
enabled	bool	yes	no	Whether custom TLS settings are enabled. The value defaults to `false`.
skip_cert_verify	bool	yes	no	Whether to skip server side certificate verification. The value defaults to `false`.
enable_renegotiation	bool	yes	no	Whether to allow the remote server to repeatedly request renegotiation.
				Enable this option if you're seeing the error message `local error: tls: no renegotiation`. The value defaults to `false`.
root_cas	string	yes	yes	An optional root certificate authority to use.
				This is a string, representing a certificate chain from the parent trusted root certificate,
				to possible intermediate signing certificates, to the host certificate. The value defaults to `""`.
client_certs	[]client_certs	yes	no	A list of client certificates to use. . The value defaults to `[]`.

Batching

Name	Type	Optional	Secret	Description
count	int	yes	no	A number of messages at which the batch should be flushed. If `0` disables count based batching. The value defaults to `0`.
byte_size	int	yes	no	An amount of bytes at which the batch should be flushed. If `0` disables size based batching. The value defaults to `0`.
period	string	yes	no	A period in which an incomplete batch should be flushed regardless of its size. The value defaults to `""`.
check	string	yes	no	A Bloblang query that should return a boolean value indicating whether a message should end a batch. The value defaults to `""`.