[ZBXNEXT-136] improved debugging/logging controls Created: 2009 Nov 20  Updated: 2017 Sep 01  Resolved: 2014 Aug 29

Status: Closed
Project: ZABBIX FEATURE REQUESTS
Component/s: Agent (G), Proxy (P), Server (S)
Affects Version/s: None
Fix Version/s: 2.3.4

Type: Change Request Priority: Major
Reporter: richlv Assignee: Unassigned
Resolution: Fixed Votes: 27
Labels: logging
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
is duplicated by ZBX-3488 Logging of Discovery workers under ve... Closed
is duplicated by ZBX-3604 Slow log in zabbix server log is clut... Closed

 Description   

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

 Comments   
Comment by João Figueiredo [ 2009 Nov 25 ]

I think this would be a major improvement for maintenance purposes and easily detect what needs fixing.

Comment by J. Fischer [ 2010 Apr 30 ]

Indeed this would be a huge step forward. Debugging rather large ZABBIX installations is virtually impossible with the current logging subsystem - as stated above, there is either too little or far too much information in the logs to be truly useful.

I'd also propose an optional split into multiple log files, as per definition above "per channel". This could be accomplished by setting the LogFile configuration item to a directory instead of a file, for example:

LogFile=/var/log/zabbix/server/

would have logs written to /var/log/zabbix/server/zabbix.log, /var/log/zabbix/server/ipmi.log, etc etc

If the value given to LogFile is a file, all information would be logged to this single file - so no behaviour change implied.

Comment by Sylvain Niles [ 2011 Feb 02 ]

If there was a Discovery channel and appropriate logging levels that would resolve this issue:
https://support.zabbix.com/browse/ZBX-3488

I'll go ahead and mark it duplicate to this improvement.

Comment by nelsonab [ 2011 Feb 02 ]

One idea would be to allow increasing debugging on a per thread basis.

Each thread should have it's own unique global variable for the current debug level. When each thread is spawned they inherit copies of the global variables of the parent. Upon the spawning of each thread the global variable should then be adjusted for each thread by the use of a local adjustment config option. The adjustment will be added to the global debug variable to in effect create a specific debug value for that thread.

For instance, if the global config for debug is 1 but the poller has an adjustment of 3, the effective debug level for all poller threads would be 4, but the rest of Zabbix would be 1. This would work for all function calls made by the poller thread due to each thread having a different variable scope. The other advantage is you would be able to use multiple adjustments, for instance, 1 for active 2 for cache, and 3 for poller yielding a global debug of 1, but 2 for the active and 4 for the poller threads.

Comment by Cal Sawyer [ 2013 Aug 06 ]

Nearly 4 years and no improvement ... please bump this up in priority, Alexei? You know it's the right thing to do.

Comment by richlv [ 2013 Aug 06 ]

this should go on irc/forums, but... get for the people to vote on this (and runtime debuglevel switching, too )

Comment by Chris Christensen [ 2013 Sep 25 ]

See: ZBXNEXT-416 for an implementation of signaling to cycle debug level on the server w/out a restart.

Comment by Alexander Vladishev [ 2014 May 21 ]

Related issues: ZBXNEXT-101, ZBXNEXT-2280

Comment by Igors Homjakovs (Inactive) [ 2014 Aug 29 ]

Fixed in ZBXNEXT-101.

Comment by richlv [ 2017 Sep 01 ]

wine debug channel url in the description broken now, see https://wiki.winehq.org/Debug_Channels instead

Generated at Wed Jul 16 10:32:46 EEST 2025 using Jira 9.12.4#9120004-sha1:625303b708afdb767e17cb2838290c41888e9ff0.