AMQP

The AMQP sink sends log events from Kron TP to an AMQP 0.9.1 compatible message broker, such as RabbitMQ. It is currently marked as beta and provides at-least-once delivery semantics. End-to-end acknowledgements are not supported for this sink, so upstream components cannot wait for broker delivery confirmation as part of an acknowledgement chain.

This sink is stateless and supports dynamic egress, meaning message routing can vary per event when templates are used for parameters such as exchange or routing key.

Kron TP connects to the AMQP broker using the provided connection string, opens one or more AMQP channels, and publishes each log event as a message. Messages are encoded according to the configured encoding rules and then published to a target exchange. If a routing key is provided, it is used to select queue bindings on the exchange.

Because delivery is at-least-once, duplicates can occur during retries. Because end-to-end acknowledgements are not supported, there is no mechanism for Kron TP to confirm “delivered to broker” back to sources in the acknowledgements chain.

connection_string This is mandatory and defines how Kron TP connects to the broker. It includes credentials, host, port, virtual host, and optional parameters such as connection timeout. The connection string is also where you select TLS by using an amqps scheme instead of amqp.

exchange This is mandatory and defines the exchange where messages are published. This value supports templating, allowing you to dynamically select the exchange per event. That is useful when you partition traffic by tenant, namespace, application, or log type, but it also increases operational complexity and should be used carefully.



encoding Encoding is required and determines how log events become bytes before publish. The most common production choice is JSON or text, but the sink supports a wide set of formats including CEF, GELF, Avro, Protobuf, and raw message passthrough.

routing_key An optional routing key used during publish. When present, it must match your exchange type and queue bindings. This value supports templating, enabling per-event routing decisions such as routing by application name, log level, Kubernetes namespace, customer ID, or any other event field.

Operationally, use templated routing keys only when you have a clear binding strategy on the broker side and monitoring to detect misroutes. A typo or unexpected field value can silently route messages to nowhere if no queue is bound.

max_channels Controls the maximum number of AMQP channels Kron TP may keep active. Channels are created as needed. More channels can improve throughput and reduce head-of-line blocking, but too many channels increase broker-side resource usage and can make troubleshooting harder.

properties Optional AMQP message properties applied to each message. These properties are set at publish time and can influence consumer behavior, message lifecycle, and prioritization.

properties.content_type Sets the message content type metadata. Commonly used values are “application/json” or “text/plain”. This does not change the payload; it signals how consumers should interpret it.

properties.content_encoding Sets the content encoding metadata. Use it when your consumers expect a specific encoding marker. This is especially relevant if you apply compression or special serialization conventions at the application level.

properties.expiration_ms Sets a per-message TTL in milliseconds. When used, messages may be dropped by the broker after the expiration window. This is useful for volatile telemetry where late data is worthless, but dangerous for audit/compliance logs.

properties.priority Sets message priority. It can be fixed or templated per event, and must fit within broker constraints. Message priority only has effect if the target queues are configured to support priorities, and it may increase broker overhead.

The sink supports memory or disk buffering.

Memory buffering provides higher performance but loses buffered data on crash or restart.

Disk buffering persists buffered data and survives restarts but requires sufficient disk capacity and meets minimum size requirements. Disk buffering is recommended when you cannot tolerate losing in-flight logs during agent restarts or node failures.

when_full behavior controls whether Kron TP blocks upstream components (preserving data but applying backpressure) or drops new events (preserving system responsiveness but losing data under pressure). For security or compliance logs, blocking is usually the safer default.

Although the sink includes an acknowledgements configuration section, this sink is documented as not supporting acknowledgements. In practice, do not rely on end-to-end acknowledgements behavior for delivery correctness with this sink. If you need strong end-to-end acknowledgement semantics, you typically need a sink that explicitly supports them, or you need an architecture where the broker publish is confirmed and integrated into your ingestion guarantees.

TLS configuration is used when connecting over amqps or when you need to customize certificate validation behavior.

ca_file is used when the broker certificate is signed by a private CA or when your environment injects TLS interception certificates.

crt_file and key_file are used for client certificate authentication when the broker requires mutual TLS.

verify_certificate and verify_hostname should remain enabled for production. Disabling them removes key protections against impersonation and man-in-the-middle attacks.

server_name can be set when the broker is behind a TLS endpoint that requires SNI to route correctly.

Single point of failure versus broker durability AMQP is often used as a durability layer, but delivery guarantees depend on the broker configuration. If your consumers require persistent messages, you must ensure the broker exchange/queues and consumers are configured accordingly; otherwise, data may be lost despite Kron TP retrying.

Dynamic exchange/routing_key risks Templated exchange or routing key values make routing flexible, but increase the chance of silent drops if bindings don’t exist. Treat this like a contract between producers and broker topology.

At-least-once duplicates If the broker or network is unstable, retries can result in duplicates. Downstream consumers should be idempotent where possible, or you should include stable identifiers in events to enable deduplication.

Credential handling Because the connection string embeds user/password, avoid storing it in plaintext config repos. Use secret injection mechanisms.