Munin Logging Specs
As discussed on IRC, a new logging system is needed for Munin.
Stig already did many improvements, mostly in replacing existing logging with the Log::Dispatch module, but now several designs questions needs to be answered. This page is here for this purpose. It will then be exported to the "Munin Guide".
The current code [de43ae291] includes:
- Logging to STDERR
- Logging to Syslog
- Logging to File
The Munin::Common::Logger module can (should) be used from master, node and the munin plugin perl module.
What to log to stderr ? (agreed)
- ssm: by default, I'd like to log everything of severity "critical" to STDERR.
- snide: it all depends on how you launch the components. I think logging to stderr should be only before the logging is properly initialized. Using the --debug flag should send everything to stderr as currently done.
- ssm: yes, we should keep this. See also "5: options"
Logging to file by default, or optional? (agreed)
- ssm: I'd like to not to log to file by default
- snide: I'd prefer to have a seamless upgrade path. That is, per default, do the same thing as before. At least in term of log files & filenames. Content may vary.
- ssm: ok
Logging to syslog
ssm: I'd like to do that per default
- Can you provide a syslog configuration that emulates the old behavior ?
- Would you have a sample for logging configuration in munin.conf ? Ideally it would be the same syntax as the one in munin-node.conf.
ssm: - the syslog configuration that emulates the old behaviour is "don't log to syslog". - sample configuration files
snide: yet, the logging to syslog should only be a matter of uncommenting a sample comment line in the config file :)
How to handle logging when you've got syntax errors in munin.conf, which may configure logging, etc... (agreed)
- snide: as said before, I think it's best to blindely use STDERR until logging is fully configured.
- ssm: A sensible default, and should be easy to configure.
ssm: I'd like to split severity and destination. However: --debug would be an expected alias for "log to screen with minimum-severity debug". I'll keep this. I'd do the same thing with --verbose and --quiet regarding output to screen.
- ssm: Option names and format are not set, what if I want debug logging to syslog, and warnings to file? --log-output syslog:debug,file:warning ?
- snide: sounds quite sane to me.
- I'd like a way of option in the config file to have their command line counterparts.
- Also, what do you think about having multiple additive --log-output ? It would add if the target isn't the same. To disable an output, just add an empty one as : --log-output syslog: or --log-output file:,syslog: to avoid all logging.
- In that respect, --debug would be an alias to --log-output stderr:debug.
- Stays the question, what file would the the file: refer to ?
- ssm: file: would refer to $logdirectory/munin-$component.log by default. munin-update would log to /var/log/munin/munin-update.log
- Configuration files
Configuration of logging. Example:
# Default logging log_output syslog:warning # Override logging for "munin-update", add debugging to default log file update_log_output syslog:warning, file:debug
- Command line arguments
Map directly to the configuration file syntax? log_output maps to --log-output, with the same argument ?
- snide: that's a real plus to me. It enables to have a very sane overriding behavior. Besides, it can also be done for more than just logging.
--limits-log-output would make no sense for munin-limits, but may for munin-cron.
- snide: Every option that are fairly generic should be allow on every munin-*. It enables a generic calling scheme in munin-cron. Otherwise we'll just reproduce the --debug nightmare that happend when munin-graph didn't understood it anymore [e0a1fe5].