diff --git a/processor/queuedprocessor/README.md b/processor/queuedprocessor/README.md index f300c8582c8..9d50c03d04c 100644 --- a/processor/queuedprocessor/README.md +++ b/processor/queuedprocessor/README.md @@ -1,47 +1,3 @@ # Queued Retry Processor -Supported pipeline types: metrics, traces - -The queued retry processor uses a bounded queue to relay batches from the receiver -or previous processor to the next processor. Received data is enqueued immediately -if the queue is not full. At the same time, the processor has one or more workers -which consume the data in the queue by sending them to the next processor or exporter. -If relaying the data to the next processor or exporter in the pipeline fails, the -processor retries after some backoff delay depending on the configuration. - -Some important things to keep in mind with the queued_retry processor: -- Given that if the queue is full the data will be dropped, it is important to size -the queue appropriately. -- Since the queue is based on batches and batch sizes are environment specific, it may -not be easy to understand how much memory a queue will consume. -- Finally, the queue size is dependent on the deployment model of the collector. The -agent deployment model typically has a smaller queue than the collector deployment -model. - -It is highly recommended to configure the queued_retry processor on every collector -as it minimizes the likelihood of data being dropped due to delays in processing or -issues exporting the data. This processor should be the last processor defined in -the pipeline because issues that require retry are typically due to exporting. - -Please refer to [config.go](./config.go) for the config spec. - -The following configuration options can be modified: -- `backoff_delay` (default = 5s): Time interval to wait before retrying -- `num_workers` (default = 10): Number of workers that dequeue batches -- `queue_size` (default = 5000): Maximum number of batches kept in memory before data -is dropped -- `retry_on_failure` (default = true): Whether to retry on failure or give up and drop - -Examples: - -```yaml -processors: - queued_retry/example: - backoff_delay: 5s - num_workers: 2 - queue_size: 10 - retry_on_failure: true -``` - -Refer to [config.yaml](./testdata/config.yaml) for detailed -examples on using the processor. +QueuedRetry processor is deprecated. Use exporter queued retry config. diff --git a/processor/queuedprocessor/factory.go b/processor/queuedprocessor/factory.go index abd40ff5b84..a60ca6553f3 100644 --- a/processor/queuedprocessor/factory.go +++ b/processor/queuedprocessor/factory.go @@ -57,6 +57,7 @@ func createTraceProcessor( cfg configmodels.Processor, nextConsumer consumer.TraceConsumer, ) (component.TraceProcessor, error) { + params.Logger.Warn("QueuedRetry processor is deprecated. Use exporter's queued retry config.") return newQueuedTracesProcessor(params, nextConsumer, cfg.(*Config)), nil } @@ -66,5 +67,6 @@ func createMetricsProcessor( cfg configmodels.Processor, nextConsumer consumer.MetricsConsumer, ) (component.MetricsProcessor, error) { + params.Logger.Warn("QueuedRetry processor is deprecated. Use exporter's queued retry config.") return newQueuedMetricsProcessor(params, nextConsumer, cfg.(*Config)), nil }