Re: [MirageOS-devel] Logs

[Thomas Leonard <talex5@xxxxxxxxx>]

On 16 October 2015 at 11:11, Anil Madhavapeddy <anil@xxxxxxxxxx> wrote:
>
>> On 16 Oct 2015, at 10:55, Daniel BÃnzli <daniel.buenzli@xxxxxxxxxxxx> wrote:
>>
>> Hello,
>>
>> The topic was mentioned again on the mirage call. I also need such a library 
>> in many different contexts and I keep on rewriting the bits of a basic 
>> logger in too many of my projects.
>>
>> I do have a Log module in bos [1] which represents the very basics I'd like, 
>> but I would like to fork it and expand it a bit to make it more useful in 
>> different contexts and independent of bos â as it doesn't depend on it and 
>> I'd like for example to be able to use the same interface in js to log to 
>> the browser console (see e.g. [2]). Here's roughly what I have in mind:
>>
>> * Format based.
>> * Simple fixed levels [3].
>> * Interaction with result type [4].
>> * Notion of logging source and per source log level control. Sources should 
>> be listable (for ui purposes).
>> * Decoupling of log generation (logging function calls) and reporting (log 
>> output/rendering).
>> * A few reporting profiles as optional subpackages, for a cli, for js, etc.

Sounds perfect :-)

I think the key here (as you mentioned) is splitting the collection
library from the reporting. The collection part needs to have minimal
dependencies so anyone writing an OCaml library will be happy to use
it. This is the hard part, because you have to get everyone to agree
;-) Fancy outputting methods are then up to the final application
author (but there should be a default handler that writes warnings to
the console, so they're not silently ignored if logging hasn't been
configured).

> I really like this library except for the notion of log levels.  One issue 
> with that is that I never quite know what levels to put in (is it Info or 
> Debug or a Warning),

This seems reasonable:

http://stackoverflow.com/questions/7839565/logging-levels-logback-rule-of-thumb-to-assign-log-levels

Roughly:

Log.error -> a human should be alerted (by default) that this has happened
Log.warning -> if it's not working, check these messages first
Log.info -> a human should see this by default if they look at the logs
Log.debug -> this should not be shown by default

A program that naturally produces logs (e.g. a web server) would write
>= info messages to its log by default. If it can send alerts then it
should alert about errors. If it reports metrics, it should report
counts of warnings and errors. An admin should try to keep warning and
error counts low.

A console application would write >= warning to the console by default
and suppress the rest. Each --verbose flag reduces the threshold by
one level.

"info" is for things that aren't problems, just normal operation.
Anything that you want to see in a post-mortem needs to be at info
level at least.

> and also that the lower level debug levels are almost always more useful if 
> they're lazy, so that the arguments are not expensively evaluated.

> Do you think it's worth having an ultra simple level-free signature that is 
> just
>
> val msg : ('a, Format.formatter, unit, unit) Pervasives.format4 -> 'a
>
> that could be passed around libraries as an argument, with the level stuff 
> added by a higher level logger/monitor?
>
> -anil


-- 
Dr Thomas Leonard        http://roscidus.com/blog/
GPG: DA98 25AE CAD0 8975 7CDA  BD8E 0713 3F96 CA74 D8BA

_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel