Monday, August 6, 2012

This log was made for rolling, rolling, rolling....

So I promised a blog post about monitoring and alerting in IT systems, so here it is. As with most liberal arts snobs I have a 'personal philosophy' about how to do things the best way. This philosophy is broken down in to three different components, based upon two critera; timeliness and context. Timliness in terms of how quickly an event needs to be acted upon, and the context in which the event is applicable. Therefore, a holy trinity of monitoring allows IT professionals to get the best information possible for any given situation. After all... the more you know.....

First off is the most immediate in timeliness, that of immediate alerting. When a system is about to come crashing down, seconds are of the essence. It's in this context that immediate alarming and alerting allows 1st level responders to get in to a system at the first sign of trouble. With any luck, they can repair and cirvumvent any problems before the problem is noticed by the client. This type of alerting involves alarms about what's going on in the system right now, at this moment. Often it involves monitoring of hardware and networks, and databases. There are lots of different tools that exist in the application sphere to accomplish this type of monitoring, and many also include hooks to ticketing systems and gateways to send texts and pages to appropriate support personnel. This is the type of system that you would see an operator sitting in front of, watching for any sign of trouble.

The second type of alerting and monitoring is what I call mid-term monitoring. This is the type of alerting that helps in a system health context, but is not immediate. When considering this type of alerting questions such as, "How did my system do over the past 3 days?" and "Have there been any spikes at odd times over the past week?" The context is still system health, but the perspective is much broader. The best mid-term monitoring solutions encompass more than just mid-term monitoring, but also integrate log interrogation. These tools help not only keep an eye on system performance over a period of time, but allow for debugging of system logs in ways that are fast and effecient. One of the best examples of a tool in this field is called Splunk, probably the finest log monitoring and indexing software out there right now.

The final level of monitoring is far less immediate, and it revolves around capacity management. In capacity management, we are most concerned with how our resources are being utilized over a long period of time. Statistics need time to gather and be aggregated to be useful for capacity management. A single spike on a single day may signal trouble to the first two levels of monitoring and alerting, but for capacity management you want to see that spike continue before you are concerned. Where as the immediate monitoring moves at the speed of a hare, capacity management is slow and careful like a tortiose.

Combined, these three types of monitoring allow systems to be as visilble as possible to the IT staff maintaining them. Coming up with a good strategy for dealing with each of these levels is key to building a successful enterprise IT system.

Happy logging!