Open Stack

----- Original Message -----
> On 28/10/12 13:30 -0400, Eoghan Glynn wrote:
> >
> >> Isn't this the same topic as the one on Monday that Annie setup?
> >>
> >> https://lists.launchpad.net/openstack/msg17802.html
> >>
> >> Lets not redo the same logic in two places.
> >
> >I'm not sure this is exactly the same thing. I was proposing an
> >extension to the ceilometer infrastructure to make it possible to
> >to publish the output of ceilo listeners/pollsters via different
> >conduits (other than via the message bus to the ceilo collector).
> >
> >The idea would be to re-use the information already harvested by
> >ceilo, where these data are of interest to multiple sinks.
> >
> >So for example, I just proposed a patch to the ceilo libvirt
> >pollster to estimate the guest CPU utilization %. The idea would
> >be to share this same measurement with both the metering and
> >metrics pipelines, instead of repeating it, seeing as it's of
> >interest to both.
> >
> >Whereas IIUC the Monday meeting is more concerned with the source
> >side, i.e producing more fine-grained instrumention/timings/
> >telemetry of a form that we don't currently produce in ceilo.
> 
> Not really it makes sense for everyone generating these events
> to do it in a consistent way.

Well, it certainly makes sense for all events be to transported/routed
in a consistent way so that they can easily be consumed by a variety
of sinks. (And I was just seeking to address the ceilo aspect of this).

But seems to me, we're inevitably going to have a wide variety of
generation mechanisms. For example the ceilo libvirt pollsters
running as periodic tasks are quiet different from say monkey
patching in the RPC dispatch code to produce lifecycle events,
which itself different again from say in-code decorators to profile
critical paths. I think we'll just have to live with this variety
where it makes sense to take different approaches to harvesting
different data.
 
> If we add metering events to projects (nova/glance/etc..) why should
> this be different code to that is in the agent?

No reason at all. (The "agent" here being the ceilo agent, or?)

It may well make sense for the services to emit "existence" style
notifications as metering events directly.

Its less clear to me that the logic in the ceilo pollsters should
also be built into the services. For a start, ceilo needs to have
fairly direct control on the cadence of those polling cycles.

> See:
> http://wiki.openstack.org/InstrumentationMetricsMonitoring?action=AttachFile&do=view&target=InstrumentationMonitoringSketch.png

In that diagram, do you see the existing ceilo logic being subsumed
under the metric driver / handlers?

Cheers,
Eoghan