I've recently started work on a new application and I instantly jumped into setting up Winston to enable the glorious fire hosing of log messages to console as well as syslog. Whilst I was happily working away through my code, setting various log calls some at error level, some debug and a few info messages thrown in it hit me...
These log messages are of benefit to ME, but are they of any use to another developer or infact any human that isn't me?!
I instantly dived to google thinking "Someone would have written this down.."
However, the opinions out there are very split. Since Dev.to is a nice community with people who share their knowledge I'd love to get an insight into the mechanics you run through deciding:
- When should I be logging information?
- What information should a log message always contain and what is optional?
- How do you decide what level this log should be set to there's many info, trace, debug, error, warn and even "verbose".
I have to say, sometimes I openly throw in log messages purely for my own benefit, simply because sometimes I don't believe my program is even working if I don't see the stack of lines running through my terminal assuring me that everything is well in the world.
Opinions please :)
Top comments (5)
First, I can only agree with you when you say opinions are "split" (to put it lightly) on logging strategies. So here come mine... take them with a truckload of salt.
If you're building an application with the intent of putting it into production for other folks to use, coarse grained logging is one of the simplest things you can do to make your life easier.
Plus, it's fun to watch all those console lines whizz by on your dev machine :)
Whenever something new happens, and especially when an error occurs.
That's super broad, I know, and I'm definitely not saying log information after every line of code. But at least once per method (that does something meaningful) is a good starting point. In practice, I typically place a log message on the first line of every method that I think does something meaningful, and a log message every time I throw an error.
By way of an example let's say I have a Controller that uses a Service that uses a bunch of DB classes. I'd want to log, at least once, when something new happens in all of them.
Let's say we call the GET method on the Controller; Log it!
That then calls the .doABunchOfStuffToGetAnEntity() method on the Service; Log it!
That makes a bunch of calls to various DB classes to retrieve a bunch of data; Log all of them!
That results in log output like:
Which gives anyone who looks at the logs a good idea of what's going on inside your app.
At a minimum, my logs include:
So something like:
or in JSON for extra parseability
Following the examples I've given above, and in my typical development life, I really only use:
Having said that, I really think use of levels come down to personal preference. I've encountered as many folks who've been very dogmatic log levels as I have folks who's mantra is "I don't care, just f$%^ing log it".
Consider your application a human.
Depends how much info do you want to get from it.
6 months baby -> App with no logs and no error handling either works or doesn't, baby is ok or crying.
1.5 years -> app with small error handling and 1-5 word logged like error save or error buy, baby has a vocabulary of 50 words
2.5 years - app has some error handling and logs that express an action like could not save order, baby can make simple sentences like i fell down
5 years - app logs that express intention with some context and can provide info about what's wrong with it, for baby while eating some candy i got sick and my stomach hurts
18 years - app handles errors correctly and logs with full relevant context and can provide info for most of the problems, human drank allot of beer now is drunk and he knows he needs to sleep it off or eat something
I find generalised logging useless. Unless you have your specific tasks, you want to solve with logging, it will just create a lot of digital noise and clutter up your code. So, define your tasks, find the best tool to solve it (maybe it will be logging), implement the solution.
The answers to 1 and 2 are pretty contextual. The best I can give for 1 is "when you think you might need it", which is less than helpful. 3 though:
I am not sure if there is any silver bullet for your questions but, I will give you my view on it :)
Consider what is most important from your perspective and what value you want from your logs, don't log blindly and everything. You will probably just get a huge pile of information that will make your life harder. So try to set up an strategy and adjust it if/when needed.
Try to explain what you tried to do, and pass information about failure.
Error - Use whenever application run it to unexpected error. Info - Use when service starts or ends (terminates normally). Debug - As it says during debugging. Should only consist of one or two lines of information.