Avoiding the common pitfalls when implementing a monitoring solution

Far too many installations have turned out not to be fit for purpose, after people have rushed to implement them without considering how they will operate. Consequently we know the common pitfalls companies fall into when building monitoring systems. So if you’d like to get your implementation right first time, put down the DVDs, step away from the keyboard, and read on...

The Classic Errors:
There are a number of issues that we see catching out many monitoring projects. By being mindful of these, you can keep your project on the straight and narrow.

Blanket Coverage:
Many customers start off a monitoring project with two main drivers. First, that to drive the ROI from their new tool, it has to be rolled out everywhere at once and, second, worrying that every application and operating system is monitored for every eventuality. They are concerned that something will go wrong and will not be picked up by the new tool, so they deploy to monitor everything everywhere.

Too Many Events:
This invariably leads to too many events, a significant proportion of which result in no useful response. In fact they are worse than having no monitoring at all, as an Operator has to spend time acknowledging or closing them without looking at the cause.

Siloed Rollout Plans:
It’s all too easy to fall into the trap of rolling out monitoring based around technology silos. People often think along the lines of “we’ll do UNIX servers first, then Windows”, which seem like a reasonable approach. But when you step back and think about it, how many of your business applications run exclusively on one interpreter type? So you can inadvertently create a scenario where none of the applications are monitored properly until the whole project is finished.

Incomprehensible Messages:
Imagine a scenario when at 3am an operator at your company receives a complicated event alert. An operator without specific training will have no idea what to do with this event, and will invariably resort to calling out team after team trying to establish if the event is important or not. This can be extremely costly as the man hours spent investigating an event like this mount up.

Unclear resolution processes:
Even if the event is understandable, what do you with it? More importantly, how do you ensure that the resolution action for a particular event is consistent irrespective of who sees it on the console? Unless everyone knows what to do and reacts appropriately, it is highly likely that time and money will be wasted.


Inability to Prioritise events:
When faced with a series of on-screen alerts. It is often impossible to prioritise the alerts and know which is most important to your business. The only reasonable thing an operator can do is start at the top and work his way down. Not the best approach if the first event is
“CPU 100% busy”, but the second alert warns “Internet Banking Down”.

Avoiding the pitfalls:
So what is the solution, how can you structure a solution (and project) to avoid the problems? The essence of an effective monitoring implementation is to determine the events to be monitored, their relative priority, and how they will be resolved before you go anywhere near installing your first agent. Do this in the context of the Business Applications and their KPIs (Key Performance Indicators), rather than focussing on technology silos and you will be well on the way to Monitoring Nirvana.

About the author:
Simon Barnes is a Director and co-founder of Orb Data. Simon is well respected in the Tivoli community for his technical capabilities, having worked with Tivoli products for in excess of 12 years.

www.orb-data.com