> > > It would be better if all OpenStack core components agreed on unified > interfaces / messages for metering that would be easy to harvest without > installing agents on nodes. This is also true for many services outside of > the OpenStack eco-system. However, much in the same way munin and nagios > plugins are developped outside of the project for which they provide > graphing and monitoring (for instance we recently published swift munin > plugins in the repository where ops usually look for them : > https://github.com/munin-monitoring/contrib/tree/master/plugins/swift and > there is no glance plugin or up-to-date nova plugins yet ), metering agents > will be developed separately, most of the time. >
This is Conway's Law manifest. The people developing nagios plugins are often in an operators role running software they didn't necessarily write (neither what they have deployed as a service nor the monitoring framework). People make it work, but it's rarely the best solution. Regardless of the monitoring solution, having application level metrics exposed by the application and implemented by people who understand the application has always led to a qualitatively better solution in my experience. As I wrote in a previous mail, once we manage to provide an implementation > that proves useful, we will be in a position to approach the core OpenStack > components. I don't follow this statement. > Integrating the metering agents as part of the core component, much in the > same way it's currently done in nova. What specifically is done? If metering is not integrated in the beginning it will likely never be. > That will reduce the overall complexity of deploying OpenStack with > metering (which must not be mandatory). I'm confused what you are using 'that' to refer to in this sentence. The integrated solution or the standalone service? We have a framework that's operation is entirely dependent on generating most of the events that need to be metered. What could be less complex than exposing that in a sensible way? Sadly, I think too many believe deploying OpenStack without monitoring must not be mandatory. I personally hope we can get to the point where fault tolerance is a first class concern for OpenStack services, and in my opinion getting there is somewhat dependent on solving this same problem in a sensible way. > However, there is very little chance that all components developed around > OpenStack are convinced and there will always be a need for a metering that > is external to the component. If that is true, then it is a sad state of affairs. I would hope people have a more holistic understanding of what OpenStack could and should become. > Therefore, even if metering eventually manages to become a first class > concern for the core OpenStack components, the proposed architecture of the > metering project ( per node agents when necessary and a collector > harvesting them into a storage ) will keep being used for other components. > I agree there is potentially interesting engineering work to be done on the transport and collection of metrics. I have an aversion to thinking the starting point for that should be defining a schema and deciding on a db. Do you think I'm wrong ? We're at a very early stage and now is the time to > question everything :-) > I don't think your motives are wrong. I could also be 'wrong'. I think the answer to that depends on what we think OpenStack should be in the end and what is good enough to get there.
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
