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.
In general
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 :)
When?
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:
Controller GET Entity
Service doABunchOfStuffToGetAnEntity
SomeDB getSomeDetails
SomeOtherDB getSomeOtherDetails
Which gives anyone who looks at the logs a good idea of what's going on inside your app.
What?
At a minimum, my logs include:
The time (UTC)
The log level
A Correlation ID (if available, to tie related logs together)
The name of the entity in which they occured (AccountController for example)
The content of the message
A string representation of an object, or collection of fields, I might care about (optional). Or in the case of an error, the stacktrace (not optional).
So something like:
2017-01-01T00:00:00.000Z DEBUG 123456 AccountController GET Account { id: 'someid' }
How?
Following the examples I've given above, and in my typical development life, I really only use:
INFO: For logs like those I described above.
ERROR: For logging when errors have been thrown.
DEBUG: For when I'm experimenting in development, or for finer grained logging that I'd like to push to production to examine something, in detail, in the wild.
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".
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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.
In general
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 :)
When?
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.
What?
At a minimum, my logs include:
So something like:
or in JSON for extra parseability
How?
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".