Read on Twitter
Logging can sometimes be a pretty difficult topic.
You either log too much or not enough, and whenever an issue arises, even gigabytes of log data won't help.
But you can structure your approach to logging, to maximize your benefits.
You either log too much or not enough, and whenever an issue arises, even gigabytes of log data won't help.
But you can structure your approach to logging, to maximize your benefits.
1) How much logging is enough?
The simplest answer is: It is never enough.
There will always be situations where every log message can be of help, but you should make a structured approach to logging, to maximize your profits.
The simplest answer is: It is never enough.
There will always be situations where every log message can be of help, but you should make a structured approach to logging, to maximize your profits.
2) Starting with a structured approach
Whether you log to stdout and have a log collector in place, or log to a file, the most important thing is, that your logs are _somewhere_ , ready to be analyzed on demand.
The next thing is using log levels and creating formatted msgs.
Whether you log to stdout and have a log collector in place, or log to a file, the most important thing is, that your logs are _somewhere_ , ready to be analyzed on demand.
The next thing is using log levels and creating formatted msgs.
3.1) Using log levels
Log levels help you to categorize messages into severities.
Usual log levels are:
- fatal
- error
- warn
- info
- debug
- trace
They're usually also methods on the logger you can call:
logger.fatal("logmessage")
logger.trace(...)
Log levels help you to categorize messages into severities.
Usual log levels are:
- fatal
- error
- warn
- info
- debug
- trace
They're usually also methods on the logger you can call:
logger.fatal("logmessage")
logger.trace(...)
3.2) Using log levels
The least messages should occur with log level fatal, the most messages should occur with log level trace.
The further you travel down the list, the more log messages there should be for each category.
And those levels should be visible in each message.
The least messages should occur with log level fatal, the most messages should occur with log level trace.
The further you travel down the list, the more log messages there should be for each category.
And those levels should be visible in each message.
4.1) Formatted messages
"This is a log message"
is a log message, but there is a lot of information missing.
"2020-08-04 11:00:00 INFO This is a log message"
is a better message.
It offers a timestamp, the log level, and then the actual log message.
"This is a log message"
is a log message, but there is a lot of information missing.
"2020-08-04 11:00:00 INFO This is a log message"
is a better message.
It offers a timestamp, the log level, and then the actual log message.
4.2) Formatted messages
You won't have to create such patterns yourself. Most frameworks already provide log levels and message formats, like the text above, or even json messages.
Make sure to use them, because they provide a nearly invaluable service to you and your team.
You won't have to create such patterns yourself. Most frameworks already provide log levels and message formats, like the text above, or even json messages.
Make sure to use them, because they provide a nearly invaluable service to you and your team.
5.1) What to log
Start with the most important things.
Calculated some result? -> INFO it
Recoverable exception thrown? -> ERROR it
Non-Recoverable exception thrown (service about to go down)? -> FATAL!
The best approach is to operate the service yourself.
Start with the most important things.
Calculated some result? -> INFO it
Recoverable exception thrown? -> ERROR it
Non-Recoverable exception thrown (service about to go down)? -> FATAL!
The best approach is to operate the service yourself.
5.2) What to log
Try to think like someone that didn't write all that code.
Can you reason about why something happened only by reading the logs?
If so, you're on a good way, if not, you have work left to do.
Maybe work together with your OPs team, to improve their experience
Try to think like someone that didn't write all that code.
Can you reason about why something happened only by reading the logs?
If so, you're on a good way, if not, you have work left to do.
Maybe work together with your OPs team, to improve their experience
5.3) What to log
Use levels like TRACE and DEBUG to your advantage.
TRACE the whole execution path, DEBUG important intermediate results which might later help you reproducing errors or strange behavior.
You can still later filter all those messages out by setting the log lvl.
Use levels like TRACE and DEBUG to your advantage.
TRACE the whole execution path, DEBUG important intermediate results which might later help you reproducing errors or strange behavior.
You can still later filter all those messages out by setting the log lvl.
6) Regularly reevaluate your logging
Things change, especially in software systems.
It's a good idea to revisit your logging approach from time to time.
Maybe you need to log more, or to log less, maybe your messages aren't the best to help on certain occasions.
Things change, especially in software systems.
It's a good idea to revisit your logging approach from time to time.
Maybe you need to log more, or to log less, maybe your messages aren't the best to help on certain occasions.
7) Adapt
Good software engineering already includes regular refactorings.
Use those refactorings to also include everything related to logging.
By constantly improving it, you constantly make operating your service easier, and searches for errors more comfortable.
Good software engineering already includes regular refactorings.
Use those refactorings to also include everything related to logging.
By constantly improving it, you constantly make operating your service easier, and searches for errors more comfortable.
