3 ms·
The best advice is hidden in one of the links in the article: Always include some sort of session identifier, as to identify all the log messages that belongs t
by xorcist 6y ago
The best advice is hidden in one of the links in the article: Always include some sort of session identifier, as to identify all the log messages that belongs to a session or transaction.
The articles speaks briefly on log severity levels, which is key to manageable logs. Make sure to specify what levels the application uses, preferably in some design document if one is being used.
For example, high severity error messages, should be only situations that should not normally occur or problems internal to the organization. For example, end user invalid credentials is not a high severity error, but invalid credentials towards the backing data store is.
Personally I tend to keep log severity thresholds local to the session, because that's the kind of filters I normally want to write.
- agumonkey 6y agoit's as if we should do logging modeling. There's structure to map logging to the code (sub)processes and also a need to relate traces to lifecycle.
- wsargent 6y agoThis is what Honeycomb and Charity Majors talk about when they get into observability. They talk about events rather than logs, and discuss how to construct a meaningful event from a series of data points [1]. Having a good dictionary of logging fields is something that is coming together more [2] although some companies will prevalidate log messages to ensure they meet the given conditions, like Palentir's Witchcraft [3] [1] https://www.honeycomb.io/blog/event-foo-a-series-of-unfortunate-incredible-events/ https://www.honeycomb.io/blog/event-foo-a-series-of-unfortun... [2] https://github.com/vektra/logging-fields https://github.com/vektra/logging-fields [3] https://github.com/palantir/safe-logging https://github.com/palantir/safe-logging
- agumonkey 6y agothanks, very interesting