#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 iwakeh): Replying to [comment:3 karsten]: > Replying to [comment:1 iwakeh]: > ... 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. Agreed. > - 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. Agreed. > - 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. Fine. > 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.) > - 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. > - 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)? > > > * 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. Yes, you can call it domains. There should be domains for certain log lines (like statistics) that can be easily directed to different log-line consumers (other files, databases, servers, etc.). > > > * 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. 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. -- Ticket URL: <https://trac.torproject.org/projects/tor/ticket/20540#comment:4> Tor Bug Tracker & Wiki <https://trac.torproject.org/> The Tor Project: anonymity online _______________________________________________ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs