Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

The Role of Logs

DZone's Guide to

The Role of Logs

You likely know a lot about logs. Here's an overview of logging, and the part logs play in debugging, and general performance maintenance.

Free Resource

xMatters delivers integration-driven collaboration that relays data between systems, while engaging the right people to proactively resolve issues. Read the Monitoring in a Connected Enterprise whitepaper and learn about 3 tools for resolving incidents quickly.

You are probably familiar with logging, and log levels. In particular, the following scheme is very popular.

I have been using this scheme for pretty much every software project I had in over a decade. And it works. Which is good.

But I found that these are actually not really fulfill our requirements. In particular, we found that a component that logged something as a warning or error would often cause an eagle-eyed admin to generate a support ticket while it was just a valid part of the software behavior. The other side of that is that when we need to use the logs to find a problem, we never use fine-grained logs, we just need it all.

This leads me to believe that we only actually need two and a half levels.

  • Informative – we are reporting something so one of our support engineers or a team member can take a look and understand what the software is doing.
  • Operational – something deserves attention from the customer’s operations team.

There isn’t really anything in between those. Either this is something that we fully expect an operation team at the customer to look at, or this is something that the development and/or support engineers need to see.

But I mentioned two and a half, what is that half? Well, above operational, there is another half a level, which I like to call Pay Attention Now. This isn’t actually a log level, it is a way to attract someone’s attention to the log, or to some sort of operational alert. This is an SMS sent, or an email, etc.

But beyond the “something needs attention now”, there is nothing else that is needed. The production logs are either for routine operations monitoring (in which case they should be relatively succinct and written with an eye to a reader who isn’t familiar with the internal working of RavenDB) or “what is going on here” mode, which is typically done by a team member who needs the most information possible.

3 Steps to Monitoring in a Connected Enterprise. Check out xMatters.

Topics:
log level ,loggging ,performance

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}