The Role of Logs
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.
Join the DZone community and get the full member experience.Join For Free
RavenDB vs MongoDB: Which is Better? This White Paper compares the two leading NoSQL Document Databases on 9 features to find out which is the best solution for your next project.
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.
Published at DZone with permission of Oren Eini, CEO RavenDB , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.