eliot

eliot copied to clipboard

Use cases:

1. Don't generate/write all logs all the time, since it's expensive.
2. Give readers ability to distinguish meaning of different messages.

Log levels are common way of doing this.

Previously I had two misgivings:

• Just log everything! In practice, this turned out to be a problem, first use case is real one. So this misgiving isn't valid.
• What would semantics mean if you had INFO action as child of DEBUG action, and the parent DEBUG was dropped?

Second misgiving is probably invalid too, I think. Two options:

1. A rule that a message/action cannot have a logging level that is more important than its parent (in output, anyway).
2. Don't enforce anything, but semantically if parent is DEBUG all children are DEBUG. An ERROR might never get logged... but if it impacted higher-level caller error would percolate up, and if it didn't percolate up that's a local error which was presumably handled somehow.

In short: introducing log levels is probably useful.

Perhaps with better levels? http://labs.ig.com/logging-level-wrong-abstraction

To what end? "Would work" for what?

Rewrote description.

or rather than levels, add some kind of marker and configure which markers are logged?

Not an expert here, just trying to think of my situation where I've been using the Python standard logging module + find it frustrating sometimes that I want to look at some specific INFO messages but not others

eliot looks interesting to me, but I wouldn't convert to it until there's some method of filtering log records.

There's a bunch of ways you can filter already: it's structured data after all. So you can filter by action_type, for example and only look at the specific actions you care about. E.g. if you're using eliot-tree there's filtering of top-level tasks using JMES queries (http://jmespath.org/).

You already have the option of adding a logging_level field of your own choosing (I recommend this methodology, even if not these particular levels): https://labs.ig.com/logging-level-wrong-abstraction

So "I want to mark messages and I want to filter messages" is already there. But since that's not obvious this suggests the need for some documentation on how to do this.

The main use case as I see for this particular issue is the first one: disabling debug/expensive log messages in production.