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.

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' }

or in JSON for extra parseability

{
    "date": "2017-01-01T00:00:00.000Z"
    "level": "DEBUG"
    "correlation_id": "123456"
    "name": "AccountController"
    "message": "GET Account"
    "details": "{ 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".

I am not sure if there is any silver bullet for your questions but, I will give you my view on it :)

1. 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.

2. Try to explain what you tried to do, and pass information about failure.

3. 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.

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:

• trace is for following something through the code line by agonizing line
• debug is for stuff you'll want to know when you're trying to analyze application behavior
• info is for 'good to know' status messaging
• warn is for a problem you'll start caring about if it starts happening a lot
• error is for a problem you'll care about no matter what
• the occasionally-available fatal is for when something has literally caught fire
• I've never seen a "verbose" log level; it's usually a flag that enables higher-level messaging (debug and up)

Or:

John Barnette

@jbarnette

Revised log levels proposal: "fyi," "wtf," and "omg."

14:53 PM - 08 Dec 2011

3625727

Consider your application a human.
Depends how much info do you want to get from it.
Example:
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