[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #20540 [Metrics]: define log-levels for all java metrics-products
#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:1 iwakeh]:
> A summary of what is in place or known already:
>
> * java projects should use slf4j (our default implementation is logback,
but that is less important)
Yep.
> * errors are possibly mailed by logging frameworks (in their default
settings). So error level should be important (an 'action item') for
operation.
> * info-level should give an indication that all things are running as
expected.
Agreed about those two, but we'll have to decide when to use the other
three levels in slf4j. Here's a suggestion:
- trace: I suggest disregarding this level, because the slf4j developers
themselves only added it to "bow to popular demand". It seems we can
easily get away by just using debug instead.
- debug: Let's use this for detailed messages to debug a problem, under
the assumption that these logs are typically disabled in production and
only enabled when debugging a problem.
- info: It seems useful to log whenever a process or major step starts or
ends, but under the assumption that these logs will only be written to
files and not mailed out to operators. It might be a good requirement to
write info-level logs in a way that operators can understand them without
having to read any code. 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.
- 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.
- error: We should use error for problems that we cannot recover from.
Otherwise they're similar to warnings.
> * maybe, log statistics to separate log files (as in Onionoo).
Are there log domains of some sort? It seems that we should leave the
decision of log files to the operator, but could say that these log
messages go into a "statistics" log domain that the operator may log to
the same or a different file. By the way, we'd probably want to log these
messages on info level.
> * what else?
Maybe one thing:
* Log levels used by metrics-lib, where a problem with parsing a
descriptor can have different consequences depending on the application.
In other words, if we log a warning or even error, we should give the
application the opportunity to tone down that warning, or ignore it,
because it doesn't care as much. What we could do is use a log domain
"parsing", or we could let applications define logging by logger name and
tone down `org.torproject.descriptor.*` loggers.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/20540#comment:3>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs