Hey y'all, I've had a little thorn in my claw on this topic for a while and thought I'd ask the larger group.
I applaud the efforts of the people working on the alarming additions to Ceilometer, but I've got concerns that we're packaging things the wrong way. I fear we're making another Zenoss/Nagios with Ceilometer. It's trying to do too much. The current trend in the monitoring work (#monitoringlove) is to build your own stack from a series of components. These components take in inputs, process them and spit out outputs. Collectors/Transformers/Publishers. This is the model CM is built on. Making an all-singing-all-dancing monolithic monitoring package is the old way of building these tools. People want to use best-of-breed components for their monitoring stack. I'd like to be able to use reimann.io for my stream manager, diamond for my collector, logstash for my parser, etc. Alarming should just be another consumer. CM should do one thing well. Collect data from openstack, store and process them, and make them available to other systems via the API or publishers. That's all. It should understand these events better than any other product out there. It should be able to produce meaningful metrics/meters from these events. Alarming should be yet another consumer of the data CM produces. Done right, the If-This-Then-That nature of the alarming tool could be re-used by the orchestration team or perhaps even scheduling. Intertwining it with CM is making the whole thing too complex and rigid (imho). CM should be focused on extending our publishers and input plug-ins. I'd like to propose that alarming becomes its own project outside of Ceilometer. Or, at the very least, its own package, external of the Ceilometer code base. Perhaps it still lives under the CM moniker, but packaging-wise, I think it should live as a separate code base. Please, change my view. :) -S Side note: I might even argue that the statistical features of CM are going a little too far. My only counter-argument is that statistics are the only way to prevent us from sending large amounts of data over the wire for post-processing. But that's a separate discussion. _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
