ZBXNEXT-246 has a proof of concept patch for server side logging

other issues related to sender output :

ZBXNEXT-506
ZBX-1827

Hi everybody,

Maybe adding an additional DebugLevel value will help to resolve this request.

Currently 3x version has 5 levels: critical, error, warn, debug, ext-debug

I propose to add yet one, so it will be:
critical, error, warn, notice, debug, ext-debug

any installation does not require any changes in config. But anybody who need this functionality should change DebugLevel only.

Additional level will be more convenient.
In case of using warning level in some installations logs will be spammed with usefulness info.
In case of debug - it will be very difficult to find useful lines from huge debug info.

of course, this level can be used not only for failed items.
also somebody with this feature can monitor zabbix logs for new trapped items.

the best would probably be returning the list of host/item/value (and maybe also time, if supplied ?) entries that failed - although one concern would be very large values

why all of that - let's say if one is sending 200 timestamped values for the same item on the same host and 30 fail - how would the sender know which ones failed to either fix some issue or retry ?

Motivation

Allow me to motivate why the requested feature would be most valuable in some situations.

We run zabbix_sender 4.2 as part of a process pipeline, that is, it runs continuously, receives item metrics on STDIN and there is a considerable throughput:

zabbix_sender -z zabbix.example.com -p 10051 -r -i -

The "real-time" (-r) switch requests to "Send values one by one as soon as they are received ... when reading from standard input."
However, if I understand zabbix_sender correctly, there is another hard-coded rule that allows zabbix_sender to collect up to 250 items that arrive within 0.2 seconds and transmit them in one transaction (see zabbix_sender(1) and the zabbix sender online documentation).

That said, this is a typical summary output we witness:

Response from zabbix.example.com: "processed: 249; failed: 1; ...

Currently there is no way to have zabbix_sender reveal this one failed item.
Well, not exactly: we could introduce something like sleep 0.25 between each metric but this would throttle throughput substantially; or IMO even worse: we could execute a new zabbix_sender process for each item.

Petition

It would be great to hear an opinion from one of the Zabbix developers / contributors regarding these questions:

• Are we using zabbix_sender not as intended?
• Why has this issue not been regarded relevant, yet?
• Is it a question of effort or rather a question of design? From the outside it looks as if this is one additional line of code that outputs the failed item (ideally depending on the verbosity level).

Thank you in advance.