Friday, December 02, 2005

monitoring and reporting interview

Q: Is there a monitoring and reporting tool package that can do "everything"?

A: Depending on the application. Well, speaking on past experience, I haven't seen a tool that has just out of the box done all the monitoring and reporting you will ever need. Uptime, performance or disk space alerts probably, but once you get down to the application you need to support, you're on your own and will need to build your own interface to the package or alert system.

Q: What about mature software packages by big vendors that have complicated specifications and requirements.

A: Some of these are great tools that work in specialised enviornments. Each tool will work on a case by case basis. Policy is currently an organisations best friend in controlling this enviornment. It can dictate what computer hardware and software are used. However in real life, its very difficult to maintain a certain standard as everyone works differently and you will obviously get the renegade department or people who will do something else and making them comply to standards is not a method of increasing productivity.

When you find a monitoring system that sounds too good to be true, it probably isn't true. Always implement a proof of concept and determine the measures of success first.

Q: What are the measures of sucess of system monitoring and reporting?

A: 100% of system managers will say if the business need is met. Thats just an easy answer because its vague and easy to get away with. After all, who is going to challenge "business need"? A chalenge of determining a success of a system is normally in determining the metrics and thresholds. Since monitoring and reporting are already metrics, success factors are already determined. How easy is that?

I'd work through this process with the example of recording a track, as there is always more than one method. Laying the drums is normally the most basic and un-inspirational. Using an appagiator kicks of some imagination, but gets monotonous. These are the easiest methods. drum == server metrics, apagiator == third party tools. You get a solution but is it what you need?

Q: What makes the best "track" or solution?

A: I feel that the best track normally comes from the inspired player. It doesn't happen often and thats probably why there aren't that many best tracks around. How this equates to system and reporting is that the designer already knows what he or she wants. An apple hitting the head, or falling in the bathroom (kids do not do this at home). After knowing what you want, just go out and get or build the thing that you need.

Sounds way to tough, but dig deep and find that the answer is always simple. That determines the best solution for you. Do not fret if its not like what other packages are like. As long as it works for you and your organisation.

About the interviewee; pipsqueak has been designing monitoring, reporting and alert systems in various projects accross different servers both with and without cash from management.

No comments:

dead pi

Well, I guess it has to happen at some point. the home automation raspberry pi has died. Much to do with the stupid Strontium mini SD card. ...