Nice, I'll try to take a look this evening!<br><br><div class="gmail_quote">On Tue, Nov 20, 2012 at 7:16 AM, Jiang, Yunhong <span dir="ltr"><<a href="mailto:yunhong.jiang@intel.com" target="_blank">yunhong.jiang@intel.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I create a draft patch on <a href="https://review.openstack.org/#/c/16522/" target="_blank">https://review.openstack.org/#/c/16522/</a> .<br>

<br>
Can anyone (Julien, Doug, Eoghan, or anyone else) have a look on it? It still an initial patch, and if the method is acceptable for you, I will continue the effort to make it a final one.<br>
<br>
Thanks<br>
--jyh<br>
<div class="HOEnZb"><div class="h5"><br>
> -----Original Message-----<br>
> From: Eoghan Glynn [mailto:<a href="mailto:eglynn@redhat.com">eglynn@redhat.com</a>]<br>
> Sent: Friday, October 26, 2012 9:34 PM<br>
> To: OpenStack Development Mailing List<br>
> Subject: [openstack-dev] [ceilometer] alternative publication conduits<br>
><br>
><br>
> Hi Ceilo Folks,<br>
><br>
> TL;DR: just wanted to get feedback on some initial ideas on how<br>
> we might accommodate different conduits of publication from the<br>
> ceilo pollsters and notification handlers.<br>
><br>
> Currently, we're obviously hard-coded to always publish via the<br>
> message bus, so the idea is to support alternative/additional<br>
> publication routes, according to the following outline:<br>
><br>
>  - a ceilo notification handler or pollster can be associated<br>
>    via config with a chain of zero or more Publishers<br>
><br>
>  - each Publisher knows now to emit their representation over some<br>
>    conduit (AMQP notification, CW PutMetricData call, statsd UDP<br>
>    packet, or whatever)<br>
><br>
>  - a ceilometer notification handler or pollster provides a<br>
>    Transformer corresponding to each of its Publishers, which<br>
>    knows how to transform domain-specific raw data into the<br>
>    relevant representation<br>
><br>
>  - the batching of transformer output is up to the Publisher<br>
><br>
>  - each Publisher has an independent frequency, so not all<br>
>    Publishers are called to publish every measurement<br>
><br>
> So for example the compute.libvirt.DiskIOPollster would provide a<br>
> transformer to map the raw disk stats reported by libvirt into<br>
> DiskWriteOps, DiskWriteBytes, DiskReadOps & DiskReadBytes metric<br>
> datapoints for CW, also indicating that this should be published<br>
> very minute. This CWPublisher would handle batching these data<br>
> as a single PutMetricData call.<br>
><br>
> The DiskIOPollster would also provide a second Transformer to<br>
> mediate between the raw stats format and the ceilo Counter<br>
> representation for metering.  Additionally, this second Publisher<br>
> could be configured with a longer period (as befits metering data<br>
> likely to be consumed by a billing engine).<br>
><br>
> Now the frequency aspect is a bit awkward. For notifications,<br>
> the frequency of the "exists" style of usage audit is out of our<br>
> hands, depending usually on the configuration of the emitter<br>
> (e.g. the nova instance_usage_audit_period config). Whereas ceilo<br>
> config direct controls only the frequency of polling. So one idea<br>
> would be for a publisher's frequency only to impact on the periods<br>
> under ceilo control - i.e. we'd accept and publish notifications<br>
> whenever we get them, whereas the polling cycle would be determined<br>
> by the greatest common divisor of all the configured publisher<br>
> periods for each set of related pollsters (the config would probably<br>
> have to be restricted so to ensure a sane GCD).<br>
><br>
> Also, I'm assuming that an alternative publication route would<br>
> generally be used when the target endpoint is not the ceilo collector<br>
> & metering store ... i.e. non-standard publisher would most often<br>
> be used in order to hive off the data to an alternative endpoint<br>
> or store, such as a CW metrics store, or say to be dumped as RRD<br>
> files to be consumed by graphite.<br>
><br>
> Thoughts?<br>
><br>
> Cheers,<br>
> Eoghan<br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br>