[syslog-ng] log statistics level

[Evan Rempel]

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.