The meaning of the preprocessing statistics named queued count and queued size is easy to misinterpret as the current preprocessing queue length and size.

In practice, these values are cumulative counters. They start at zero when the preprocessing manager process starts, increase as values are received, and are not reduced when the values are processed. A large queued count therefore does not by itself indicate a preprocessing backlog.

The actual current backlog is exposed separately, for example as pending tasks in diaginfo=preprocessing and as queue / zabbix[preprocessing_queue] in preprocessing statistics.

The Zabbix 7.0 internal items page describes zabbix[preprocessing] as follows:

queued - the number and size of queued values that require preprocessing (counter)

direct - the number and size of queued values that do not require preprocessing (counter)

queue - the count of values enqueued in the preprocessing queue (same as zabbix[preprocessing_queue])

Reference:
https://www.zabbix.com/documentation/7.0/en/manual/config/items/itemtypes/internal#preprocessing

The word "counter" is present, but the page does not state the counter interval/reset condition or explicitly warn that queued.count and queued.size are not the current queue length/size. The zabbix_proxy and zabbix_server manpages mention diaginfo=preprocessing, but do not document the meaning of its output fields.

The same ambiguous wording is currently present in the 7.4 and 8.0/devel internal-items documentation.

Example of the ambiguity

A healthy proxy can report no pending tasks together with a very large cumulative queued count:

Cached items:263959 pending tasks:0 finished tasks:0 task sequences:0 queued count:43955203 queued size:14132434325 direct count:363796 direct size:113986821 history size:32993874

This was interpreted as a preprocessing queue of more than 43 million tasks, even though pending tasks:0 showed that there was no current backlog.

The same interpretation has already appeared in public issue ZBX-27811, where the reported queued count was confirmed to be a cumulative metric.

Source behavior

In the Zabbix 7.0 source:

• counter_queued_num, counter_queued_sz, counter_direct_num, and counter_direct_sz are initialized to zero when the preprocessing manager starts;
• these counters are incremented for each preprocessing request;
• the counters are returned unchanged by the preprocessing diagnostics/statistics handlers;
• the current preprocessing queue value is obtained separately from manager->queue.pending_num.

Please update the supported and development documentation to state explicitly that:

1. queued.count / queued count is the cumulative number of values received for preprocessing since the preprocessing manager process started; it is not the current queue length.
2. queued.size / queued size is the cumulative size of those values since the preprocessing manager process started; it is not the current queue size.
3. direct.count and direct.size are cumulative counters for values handled directly without preprocessing and have the same reset scope.
4. queue, zabbix[preprocessing_queue], and pending tasks represent the current pending preprocessing workload.
5. The cumulative counters reset when the preprocessing manager process restarts.