Retry and Queueing
A sending queue is a buffer that stores telemetry data temporarily before sending it to the destination. The sending queue ensures that telemetry data is not lost due to network connectivity issues or server outages and helps to minimize the number of network connections required for efficient transmission.
|sending_queue_enabled||Enable to buffer telemetry data temporarily before sending|
|sending_queue_num_consumers||10||The number of consumers that dequeue batches.|
|sending_queue_queue_size||5000||Maximum number of batches kept in memory before dropping.|
In addition to the sending queue, the persistent queue may be enabled. When enabled, telemetry data is persisted to the disk, which provides data resiliency in cases where the collector restarts. The sending queue must be enabled to enable persistent queuing.
|Enable to buffer telemetry data to disk instead of in memory.|
|The path to a directory where telemetry data will be buffered.|
Retry on Failure
Retry on failure settings are used to determine whether the exporter should attempt to resend telemetry data that has failed to be transmitted to the destination endpoint. When this setting is enabled, the exporter will automatically retry failed transmissions at a configurable interval until the data is successfully transmitted. This helps to ensure that telemetry data is not lost due to temporary network connectivity issues or server outages.
|retry_on_failure_enabled||Attempt to resend telemetry data that has failed to be transmitted to the destination.|
|retry_on_failure_initial_interval||5||Time (in seconds) to wait after the first failure before retrying.|
|retry_on_failure_max_interval||30||The upper bound (in seconds) on backoff.|
|retry_on_failure_max_elapsed_time||300||The maximum amount of time (in seconds) spent trying to send a batch, used to avoid a never-ending retry loop.|