Timeline for Logging Architecture Solution
Current License: CC BY-SA 4.0
7 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Aug 7, 2018 at 20:06 | comment | added | bikeman868 | A much better system than severity level would be tagging. This would allow the developer to tag the log message with what they actually know about it, and the log consumer could search and filter using expressions based on tags. For example the developer knows the machine, application, module, class, method. They also know if this was an exception trap, if it is recoverable or not, whether the operation can be retried, was this a timeout, error response, no response etc. These tags are much more meaningful than error, warning, info or debug. | |
| Aug 6, 2018 at 13:39 | comment | added | Facundo La Rocca | @MartinMaat Thanks for your answer. One of the problems we actually have is that some of our systems receive millions of requests per minute (The ingestor for example), and sometimes errors in these systems are not shown until 2 days later. Even though, as you have mentioned, most of the time logs are useless, in some cases is rather difficult to reproduce cases. I take your advice, probably we don't need to use the same logging mechanism everywhere, but in the core. | |
| Aug 5, 2018 at 22:19 | comment | added | Kwebble | A developer can determine the severity of a situation. But defining the actions to take when a specific situation occurs is something else. Instead of building a completely new central logging system I would look at logstash first, like @ewan commented. | |
| Aug 5, 2018 at 19:05 | comment | added | bikeman868 | This is kind of a big subject to discuss in comments, but anyway, think about these two aspects: as a consultant brought in to sort out messes I have seen so many systems where the logging is completely useless mostly because these severity levels were abused by the developers (for good reasons); the severity should be defined by the consumer of the logs not the originator of the log messages, ie alert me if this type of error happens in this module and it is not part of the module's single responsibility to know these rules. | |
| Aug 5, 2018 at 11:27 | comment | added | Martin Maat | Hmmm... How is that? An unhandled exception is fatal. An unexpected exception is an error. An expected exception is a warning. Anything that helps tracking regular activity is info. Small steps within an activity may be signaled with debug messages. In each case I know perfectly well what the severity level should be. And I know which ones I would be interested in in a particular debugging scenario. | |
| Aug 5, 2018 at 8:38 | comment | added | bikeman868 | I know that most popular logging libraries require the developer to choose a severity level when logging messages, but this is an anti-pattern because there is no way that most classes that log issues can know how severe this issue is to the system as a whole. | |
| Aug 5, 2018 at 6:57 | history | answered | Martin Maat | CC BY-SA 4.0 |