Wednesday, 24 August 2011

Zenoss - introduction

This is a first post about Zenoss - the Open Source IT Management System.
I need to introduce it first, because I'm sure that there will be far more than one article about that. I worked with Zenoss very close for almost 2 years and I have some interesting things to share, which I didn't put to the Zenoss community forums.

First of all - why Zenoss?
Some time ago I was not satisfied of the existing monitoring system. It was Nagios, and generally – it was very good for the main thing we want from it – the monitoring. But I wanted something more. I wanted an easy way to collect and view the performance data (we used cacti before), I wanted to have auto-discovery, to have the agent-less solution, to make it easy to configure for others (actually, I failed with that :)), to have the alerts escalation and something else. And I wanted this all ready just from the box and, of course, for free :).

I have tested several solutions before I stopped with Zenoss. I will not write a list of competitors and all their 'pluses' and 'minuses'. I will describe with what I had success with Zenoss and where I failed.

Core. Generally, with quite some effort, but it's possible to get any kind of data, analyze it in any possible way and proceed with any kind of reaction. And out from that I have all the other "pluses".

Performance data. I can take a value from any kind of the datapoint and put it to the RRD. Most popular for me are SNMP and COMMAND. Also, there are some types of datasources from ZenPacks (e.g. MYSQL or VMWare), or you can write your own. COMMAND datasourse uses any executable with any parameters and parse it's output for the variables. It is very flexible as for me, so I can provide monitoring for any kind of the device that has any kind of data available from network. How many time I've wrote a word "any"? :)

Reports. ... any ... any ... all ... any. I feel no need to describe it in details, you can find it in the documentation. Really useful thing for me is the dynamic Graph reports.

Support. Of course, there is no guarantied support for the Core (free) version. But there is quite useful documentation, great videos and quite responsive community on forums.

... At that moment I have realized, that it will take too long for me to describe all "pluses", so I just list some of them:
  • Very advanced and flexible Event Management
  • Flexible Monitoring Templates management (and templates itself is a big plus also)
  • Customizable Dashboard
  • Big set of ZenPacks
  • Distributed Collectors
  • SNMP traps, syslog, Windows eventlog receivers
  • Processes, IP-services and Windows-services monitoring "from the box"
  • Nice Interface (from version 3.*)
  • Agent-less
  • Easy to deploy
  • etc. (many other standard things like backups management, event DB maintenance etc.)

And now some disadvantages:
  • Interface (version 2.*). Although it was significantly changed in version 3.0, this needs to be described, because it was one of my biggest problems with this project. When I was investigating Zenoss, I get used to the interface and it seemed OK to me. And it was described as one of the advantages, because I was able to see what I need to see from Zenoss, forgetting that the information that Zenoss provides is different from what people used to see from Nagios. In fact Nagios provides information about the state of the monitored devices&components, but in Zenoss, the source for the state is an event. I have understood it very quickly, but I didn't describe it properly to a team and it was confusing to them, because instead of the state "OK" they should look for some events in the completely different Interface.
  • Performance. Well, Zenoss is quite greedy for the resources. The "bottle neck" for me is a MySQL DB performance on SELECT operations. It produces extra high I/O when getting some data from the Events History.
  • Complexity. Zenoss became not just a Monitoring System, as I planned from the very beginning, but it is a real IT Management System now with all those features and procedures developed and configured. And it requires a bit more than a superficial knowledge of the interface. I never wrote a code with an OOP language before. But to make Zenoss do what I want I had no other chose but to learn some Python.
There were few other disadvantages, but they became to a "must/good to have" list, and then most of them were solved.
Actually, next posts for Zenoss subject will describe how I solve some of those tasks.

Stay tuned! ;)

No comments:

Post a Comment