We've had a site license for HP OpenView for a couple years, and have been experimenting with it to see whether or not it fits our needs. Obviously since we've decided to start this project we've decided that HP OpenView isn't right for us. Management has asked us to document our reasons for that decision, so they can refer back to those reasons at a later date. So here are our reasons for not using HP OpenView. All information here is based on our experience with OpenView, and may be based on flawed understanding, or personal opinions.
Openview monitors all devices that it discovers in its probes. Individual clients may filter events they are viewing, but the system monitors any devices it finds. There probably is a way to add devices that aren't probed, but it wasn't appparent.
Relying on discovery can be good for network devices and topology, but seems suboptimal to us for for servers and service monitoring. Especially since we already have existing data on what machines perform what services which we'd like to be able to inject into the monitoring system to tell it what to monitor. We also already have a system (NetMon) doing network device and topology discovery, for our own nefarious purposes, and we would prefer to just inject that data into the system, to reduce the polling load on the network devices.
The openview web client is very dense, and is essentially an administrative client. it can do "anything" to the system (and the devices, assuming openview has the snmp RW strings) and it requires several clicks to get from the "home page" to something that is useful for monitoring. We don't remember if the monitoring pages auto-refresh. We've heard about a java client, but it wasn't what we got access to, and we think that even it doesn't prevent users from reconfiguring devices.
The system seemed to drain the life out of the machine it was run on. The system was slow, used lots of memory, and wasn't even really doing much more then monitoring network devices. Distributed Monitoring might solves this problem, but we feel that we can do far more with another system with less CPU power required.
The understanding we have of OpenView, and the experiences that we've heard of from other organizations, leads us to believe that using OpenView as our primary monitoring tool would required dedicating a full time employee to maintaining and monitoring the system. We simply don't have the resources to commit that much ongoing effort to the system.
Although we never got our hands on the OpenView SDK, the information we were able to gather about it leads us to believe that it has a steep learning curve for developing new monitoring plugins for the system. This conflicts with our desire to not need to dedicate a person to maintaining and developing the system full-time. With an open-source system like MON, any staff member can develop tools for monitoring services in their preferred development environment, and with little prior knowledge of how MON works.