IMHO most logging frameworks support broken or poor selection of messages.
The feature i am referring too is named loggers where different loggers have different levels. The problem with this is of course one logger may record ERROR messages but the real details in other loggers are at DEBUG which may be filtered because they also are set to something higher.
Im suggesting the solution is support for ideas of capturing all log messages within a transaction if an ERROR message is hit.
In the above example my suggestion would be all 3 messages would be logged because 3 happens. In a transaction without "3" 1 and 2 would not be logged.
The twist I’m exploring is to keep debug logs buffered during normal execution and only release the relevant context when an error occurs. So you get the diagnostic value of DEBUG without continuously storing all the noise.
I built a small Go library to experiment with this approach, but I’m particularly interested in where the model breaks down in real-world systems.
IMHO most logging frameworks support broken or poor selection of messages.
The feature i am referring too is named loggers where different loggers have different levels. The problem with this is of course one logger may record ERROR messages but the real details in other loggers are at DEBUG which may be filtered because they also are set to something higher.
Im suggesting the solution is support for ideas of capturing all log messages within a transaction if an ERROR message is hit.
- new transaction - log DEBUG message 1 - log DEBUG message 2 - log ERROR message 3 - end transaction
In the above example my suggestion would be all 3 messages would be logged because 3 happens. In a transaction without "3" 1 and 2 would not be logged.
Exactly. That's essentially the idea.
The twist I’m exploring is to keep debug logs buffered during normal execution and only release the relevant context when an error occurs. So you get the diagnostic value of DEBUG without continuously storing all the noise.
I built a small Go library to experiment with this approach, but I’m particularly interested in where the model breaks down in real-world systems.
Im not quite sure but it appears the code has the logic that forces logging of a transaction, via trip methods.
I think this could be improved by moving this logic to properties files and using named loggers or named transactions to enable/disable.
[flagged]
Im amazed how after all these years logging and how it works is basically unchanged after 25 years.
Names, logger, different levels...
And thats all.
[flagged]