[tor-bugs] #20540 [Metrics]: define log-levels for all java metrics-products

[Tor Bug Tracker & Wiki]

#20540: define log-levels for all java metrics-products
-------------------------+-----------------------------------
 Reporter:  iwakeh       |          Owner:
     Type:  enhancement  |         Status:  needs_information
 Priority:  Medium       |      Milestone:
Component:  Metrics      |        Version:
 Severity:  Normal       |     Resolution:
 Keywords:               |  Actual Points:
Parent ID:               |         Points:
 Reviewer:               |        Sponsor:
-------------------------+-----------------------------------

Comment (by karsten):

 Replying to [comment:4 iwakeh]:
 > Replying to [comment:3 karsten]:
 > > One example where info might be too high is where metrics-lib informs
 us which `DescriptorCollector` implementation it's serving us, because
 that's something the operator wouldn't normally care about.
 >
 > The logging statement you refer to can be useful to the operator once
 there are other metrics-lib implementations available and the operator
 choses to use metrics-lib-ng instead of the regular implementation.  Or,
 in case we provide other parsing implementations, too.
 >
 > (In order to make it really code independent metrics-lib would need to
 supply an identifier, but when different implementations are used the full
 class-name can just be stated in the documentation to that implementation
 and operators wouldn't need to know that this is a java class name.)

 Okay.  I'm not certain where this message fits in best.  On the one hand I
 wouldn't expect an operator to select an implementation that is not the
 default.  But on the other hand I can see us asking an operator for their
 info-level logs whenever something's wrong, and then we might want to see
 which exact implementation was used.  I'd say let's defer this until we
 have more such cases to speculate about.

 > >  - warn: We could use warn to inform the operator of a problem that we
 were able to recover from but that they should be aware of.  The warning
 should be written in a way that the operator understands, and it should be
 something that the operator can do something against.  Stated differently,
 we should expect to be contacted by operators who are unclear what to do
 about a given warning.  And if they cannot do anything against it, maybe
 it should be an info message rather than a warning.  We might want to
 recommend that operators include warnings in any automated notifications
 they receive from their service instance.
 >
 > Agreed. Even require that the 'cure' is added to the warning, e.g.
 "provide more disk space" etc.  Requiring this will give a good
 distinction between warnings and info messages.

 I like this!

 > >  - error: We should use error for problems that we cannot recover
 from.  Otherwise they're similar to warnings.
 >
 > Maybe, define errors for the unusual (errors would be logged in some
 places where we do not really expect anything) and ask operators to post
 these (ml or trac)?

 You mean assign a unique error number?  Sure, sounds like a fine idea!
 Should we also do that for warnings, so that operators can give us the
 warning number whenever they're unsure how to handle an issue?

 > Maybe, for metrics-lib we should not log too much but rather throw
 exceptions.  That would be the right way to make the application to deal
 with problems.
 > But this is "error handling" rather than logging.

 Well, it touches both areas.  If we say we rather throw an exception than
 log a warning or an error, that's something we can work with.  I didn't
 look at the code yet to see whether that would work.  It might!

 Agreed with the rest that I didn't quote above.  Let's turn this thread
 into a guide somewhere as soon as we agree on the remaining things.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/20540#comment:5>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online