Re: [Openinteract-dev] what to log and when

[Chris W. <ch...@cw...>]

Salve J Nilsen said:
>>  - If we set the threshold to 'FATAL' we don't store anything -- nothing
>> is logged with a 'FATAL' level.
>
> This doesn't necessary have to be a bad thing... Are there any
> situations that should be fatal to OI2? e.g. missing critical
> dependencies, inability to contact critical databases, badly broken
> (truncated?) primary config files, inability to access local files at
> all (broken filesystem.)

These were all I could think of, although at least the dependencies should
get caught at server startup vs runtime.

> At this level, I hope never to get any output to the log files. :)
>
>>  - If we set the threshold to 'ERROR' we store a ton of messages, too
>> many to be useful.
>
> Do _all_ these messages deserve an "ERROR" status, or are some of them
> only informational? The ones that actually _are_ errors, should of
> course be fixed. :)

That's the problem -- while all of them are errors, some aren't ones you'd
actually care about. For instance, when you lookup an action with an
incorrect name OI2 will log an error. Yes, it is an error, but is it one
we need to log? Probably not, since the caller is in a better position to
evaluate whether it's actually an error.

There are lots of these, unfortunately. It'll just take some time to go
through them but it's worth the time.

>  >   FATAL
>
> Fatalities (death). Situations where the system/application cannot
> continue safely and must abort. Manual intervention is necessary to get
> things running again. (Hopefully, this is something you'll never need to
> see. :)

Right -- database crash, cannot load vital components (e.g., packages), etc.

>  >   ERROR
>
> Actual errors that need to be looked into. The application should be
> able to continue running despite having these errors, but should
> probably tell the user why the expected data can't be delivered.

So would this include not being able to store data in the database because
of bad data? Or failing to execute a query because of a typo in the
fieldname?

>>   WARN
>
> For situations that at some point later may lead to errors. E.g. missing
> directories, use of default values in system-dependent configuration
> (e.g. when using a default IP address of 127.0.0.1, when it should have
> been defined explicitly in some config file.)

I'd probably add security violations to this.

>  >   INFO
>
> High/Coarse-level status messages. I try to use this to tell when
> important subsystems are used, and what data they recieve/pass along.

Good guidelines. Not a lot of data is in these but more like a guide as to
what path the application is taking.

>  >   DEBUG
>
> Detailed status messages, debugging, and all the rest. Personally I'd
> like several debug levels, but existing logging frameworks like
> syslog(1) and log4* seem to disagree with me. :)

Yeah, everything else goes here :-)

Thanks!

Chris

-- 
Chris Winters (ch...@cw...)
Building enterprise-capable snack solutions since 1988.