Steps to reproduce:
- Imagine you are a loadable module developer.
- Imagine your module does some complex logic. You want to log a few messages to make decisions made by your module visible and help your users to troubleshoot problems. Obviously, you don't want to log these messages every time code of your module is executed.
- (Ab)use zabbix_log().
Pros Cons No need to implement module-specific logging mechanism. Zabbix does not encourage use of internal Zabbix functions in modules. Zabbix synchronizes writes from different processes. Potential API and ABI compatibility issues. Log messages have the same format as Zabbix messages (e.g. time stamp, etc.). Module is aware of logging level configured for Zabbix .
- Write to stdout and stderr (Zabbix redirects them to the log file).
Pros Cons Simple as printf(). Need to synchronize writing from different processes. Legal. No API or ABI concerns. Need to implement module's own logging level configuration. No way to control logging level in runtime (or too difficult to implement it). No time stamps (or need to implement them).
- Module's own log file.
Pros&Cons are similar to previous option with even more burden for module developer. Life is simply too short to go this way. And the end user will have two log files to look at and correlate, which isn't good.
When module provides optional zbx_module_set_log_level() function, Zabbix should tell the module on startup which DebugLevel was set in the configuration file. Whenever user changes logging level using runtime control options, Zabbix will notify module about that. This will allow modules to implement runtime control of logging level even if module uses simplistic printf()-like logging.
In addition to that Zabbix should set a callback which will be used by the module to put messages into Zabbix log file. This callback should take care of time stamps and log file mutex. Callback should be provided to the module if the latter provides optional zbx_module_set_log_callback() function.