very often zabbix is blamed for what essentially are problems outside of zabbix. in absolute majority of such cases zabbix has provided insufficient error reporting that would allow pinpointing the problem.

this is a proposal for logging/debugging system changes. it is based on two main concepts.

1. debugging can be tuned on component level. this is being done by wine, for example, where the feature is called "channels". debugging can be controlled per channel, thus it can be enabled only for winealsa or wsocks32. a list of available channels in wine for inspiration : https://wiki.winehq.org/Debug_Channels

such a feature allows not to be swamped by irrelevant output and diagnose problems more efficiently.
possible channels in zabbix : db, alerter, poller, ipmi, snmp, trapper, nodesync etc

2. more loglevels. current of 4 is too little, especially given that at 3 one rarely gets useful info, but at 4 there's way too much info.
loglevel can be set per channel.

coupled these features can allow specifying things like log level 2 for everything but loglevel 5 for ipmi, when debugging ipmi related problem.

debug output would not be tied to single channel, instead they could be controlled by multiple.
for example ipmi related queries would depend on two channels - db and ipmi. if db would be set to 6, they would be logged together with all db queries, but even if db would be set to 2, ipmi queries would be logged if ipmi channel level would be > 5. (made up levels, not to be taken too seriously).

edit : runtime logging controls at ZBXNEXT-416