Bryan Henderson wrote:
You can find the results in tomorrow's snapshot, however I'd appreciate if you could check my judgement and see if I did something wrong.
In main.c, there are four messages generated at NOTICE level that I think are really INFO:
syslog-ng starting up SIGHUP received, reloading configuration Termination requested via signal, terminating syslog-ng shutting down
The reason these aren't worthy of notice is that the system administrator already knows about these events; he ordered them.
That's why I need to notice them, in case I didn't order them. If I were to break into a box, one of the first things I would do is compromise the logging mechanism :-)
Something worthy of notice is something that happens independently.
While almost all the error reports are issued at ERROR level, I found these that seem to be the same kind of errors, but have the lower NOTICE level:
cfg_lex.c: unknown parse flag cfg_grammar.c: The value specified for time_sleep is too large.
And here's one that's CRITICAL:
macros.c: Internal error, unknown macro referenced
Isn't this just another error? If a result of this is that Syslog fails completely, it would be worth an ALERT, but then the message should mention that Syslog failed completely. CRITICAL is just for when an entire major system is in imminent danger of collapse and needs immediate attention. I think a system could continue useful work for quite a while without Syslog service.
Again I would think that the logging system is more important than other applications. System logging needs to be a guaranteed thing, afte all, isn't that why were using syslog-ng in the first place :-)
In afsocket.c, "Number of allowed concurrent connections exceeded" is an ERROR. If this is what I think it is, it's not a case of Syslog being broken, but nonetheless something that might need attention, so I would call it WARNING or NOTICE.
I would say this should be an alert because something isn't working until a human interceeds. I don't want mere notices that one of 500 hosts can't log to my central server. I want that fixed ASAP.
And in affile.c, "Destination file is too old, removing" is to me business as usual, not something someone is likely to want to respond to, so I would make it INFO.
Any time data is overwritten/removed/lost I want to know about it. Perhaps a warning so that if I need to I can retrieve the log file from backup and place it into the log archive stream. INFO is something that should only be looked at during an incident followup. This could be trouble shooting, internal audit, legislated laws or sopeona. WARNING is something that I should know about, but isn't reporting that something is broken. I guess it is fairly obvious that many people would like diffrent logging levels for different types of events. The safest approach is to use the description from the syslog RFC documentation. I did not take any care to fit my descriptions of the logging levels to the RFC document. Evan.