DEV Community

Cover image for Logging! How do you decide on your app log levels and outputs?

Posted on

Logging! How do you decide on your app log levels and outputs?

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 is a nice community with people who share their knowledge I'd love to get an insight into the mechanics you run through deciding:

  1. When should I be logging information?
  2. What information should a log message always contain and what is optional?
  3. 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)

leightondarkins profile image
Leighton Darkins • Edited

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 :)

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
Enter fullscreen mode Exit fullscreen mode

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:

  • 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' }
Enter fullscreen mode Exit fullscreen mode

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' }"
Enter fullscreen mode Exit fullscreen mode

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

theodormanolescu profile image
Theodor Manolescu

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

voins profile image
Alexey Voinov

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.

dmfay profile image
Dian Fay

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)


eldlabs profile image

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.