Problem

The output of diaginfo=preprocessing uses the labels "queued count" and "queued size" for cumulative throughput counters:

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

These labels are frequently interpreted as the current preprocessing queue length and size. In the example above, "pending tasks:0" means that there is no current pending backlog, while "queued count:43955203" is the cumulative number of values received for preprocessing during the preprocessing manager lifetime.

The same misunderstanding occurred independently in ZBX-27811 and in the support case that resulted in documentation task ZBX-28052. It can cause unnecessary incident investigation, configuration changes and restarts even when preprocessing is operating normally.

Current behavior

The following values are cumulative since the preprocessing manager process started:

• queued count
• queued size
• direct count
• direct size

They are initialized to zero when the preprocessing manager starts and only increase as requests are received. They are not reduced when processing completes.

The current pending workload is reported separately through "pending tasks" and through the preprocessing queue internal metric.

The cumulative counters were introduced by ZBXNEXT-9877 as preprocessing throughput statistics. The source behavior is correct, but the human-readable diaginfo labels do not communicate the cumulative scope.

Source verification

The behavior and the same labels were verified in:

• tag 7.0.22, commit ba52e2ee4ff8768c8450819a772886d79dcde0b4
• release/7.0, commit bd497e098fc8f218d19dd4c99af73d2a2061ea99
• release/7.4, commit e8cfec06082df0d480abd03b78ba924794ae56d8
• master, commit ca357ba68c332d76b249d65df7a8546b03551bba

Relevant source locations:

• src/libs/zbxpreproc/pp_diag.c - emits "queued count", "queued size", "direct count" and "direct size"
• src/libs/zbxpreproc/pp_manager.c - initializes and increments the cumulative counters
• src/libs/zbxpreproc/pp_manager.c - obtains the current pending queue separately from manager->queue.pending_num

Expected result

The diaginfo=preprocessing output should make it self-evident that queued/direct count and size are cumulative counters and not the current queue length or size.

A compatibility-safe implementation could retain the existing field labels and add an explicit line such as:

Counter scope: queued/direct count and size are cumulative since preprocessing manager start

Alternatively, if changing diagnostic labels is acceptable, they could be made explicit, for example:

queued cumulative count:43955203 queued cumulative size:14132434325 direct cumulative count:363796 direct cumulative size:113986821

The exact wording is implementation-specific. The required outcome is that an operator can correctly distinguish cumulative throughput counters from current queue state without consulting external documentation.

Acceptance criteria

1. With pending tasks equal to zero and cumulative queued count greater than zero, the output clearly communicates that there is no current pending backlog.
2. The reset scope of queued/direct count and size is explicit: preprocessing manager process lifetime.
3. The behavior is consistent for Zabbix server and Zabbix proxy.
4. Current pending queue semantics remain separate and unchanged.
5. Backward compatibility for tools that parse diaginfo output is considered.
6. This request does not rename or otherwise change the zabbix[preprocessing] JSON fields; any public metric contract change is out of scope.