<br><br><div class="gmail_quote">On Thu, Nov 15, 2012 at 4:04 PM, Sandy Walsh <span dir="ltr"><<a href="mailto:sandy.walsh@rackspace.com" target="_blank">sandy.walsh@rackspace.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> From: Eoghan Glynn [<a href="mailto:eglynn@redhat.com">eglynn@redhat.com</a>]<br>
> Sent: Thursday, November 15, 2012 1:01 PM<br>
><br>
> Hi Sandy,<br>
<br>
Hey! Thanks for the prompt reply :)<br>
<div class="im"><br>
>> We don't *have* to use rabbit to handle the notifications. The<br>
>> notification system could easily be extended to allow different<br>
>> event types to use different notifiers. For example, billing events<br>
>> could go to rabbit while monitoring/lifecycle events could go to a<br>
>> log file. Or, if we wanted to introduce a debugging event, that<br>
>> could send to statsd (or something) directly as it strips out the<br>
>> cruft from the message.<br>
<br>
>Yes, so in ceilometer we've been making small steps towards that<br>
>idea with the concept of multiple publishers and transformers.<br>
>So a transformer would know how to distill what a publisher needs<br>
>from the raw data (strip out the cruft & massage into the expected<br>
>format) and then the publisher knows how to emit the data via<br>
>some conduit (over rabbit, or a UDP packet for stats, an RRD file,<br>
>a CloudWatch PutMetricData call, etc.).<br>
><br>
> So I'm thinking we're not a million miles from each other on that<br>
> score, other than I had been assuming the publishers would live<br>
> in ceilo, and it would understand their requirements in terms of<br>
> cadence etc.<br>
><br>
> Were you more thinking of this logic living elsewhere?<br>
<br>
</div>So this should be a Ceilometer notifier, that lives in the Ceilometer code base and is a nova.conf --notification_driver setting for whomever deploys it. This implies there are two ways to get notifications out of Nova:<br>

1. via the Rabbit Notifier with an external Worker/Consumer (preferred for monitoring/usage/billing)<br>
2. via a specific Notifier (like <a href="https://github.com/openstack/nova/blob/master/nova/openstack/common/notifier/log_notifier.py" target="_blank">https://github.com/openstack/nova/blob/master/nova/openstack/common/notifier/log_notifier.py</a>)<br>
</blockquote><div><br></div><div>We're talking specifically about values like disk I/O, CPU stats, etc. That data isn't generated as part of a notification, that's why we're having to poll for it. What we're looking for is a solution that doesn't involve ceilometer importing part of nova's code *in an unsupported way*, as it does now. Some of the options presented involve new network-based communication between the existing ceilometer agent and the compute agent (RPC or REST, in different directions). None of those is really optimal, because we don't want to burden the compute agent with lots of calls asking for stats, either for metering or for monitoring. I think the option the ceilometer team is favoring at the moment is making the hypervisor library in nova a public API, so we can use it without fear of the API changing in unannounced ways. That would let us keep the hypervisor polling in a separate daemon from the hypervisor management. There are details to work out about how such a separate library would be implemented.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Stuff such as converting format and varying polling rates seems to be something external to nova. Since the system will only issue notifications at the rate they occur. Higher sampling rates I think fall into the instrumentation category and should be dealt with separately.<br>

<div class="im"><br>
>> So, the messages that we are interested in are larger/less<br>
>> frequent/less time sensitive (within reason) and very important.<br>
><br>
> Are you contrasting with instrumentation data there?<br>
<br>
</div>yes, sorry, bad placement.<br>
<div class="im"><br>
>Certainly there would still be some time sensitivity, particularly for<br>
>metrics feeding into near-realtime monitoring. So for metering feeding<br>
>into non-realtime consumers (just as billing), we can tolerate a bit<br>
>of irregularity in the cadence and some delays in the pipeline, as<br>
>long as we maintain completeness. Whereas for monitoring, we need to<br>
>get at that data while its still fresh and ensure its sampled at a<br>
>near-constant rate.<br>
<br>
</div>Sounds like instrumentation to me.<br>
<div class="im"><br>
>> Also, they are ancillary to the task at hand (providing a cloud<br>
>> service) so their failure should not bring down the system. Which is<br>
>> why a queue-based approach seems the logical choice. Having nova<br>
>> call out seems wrong and if it did, it belongs as a new rabbit<br>
>> notifier where the person deploying that solution takes all<br>
>> responsibility.<br>
<br>
>True that, we certainly need to be cognizant of the load imposed<br>
>on a possibly degraded system potentially making things worse.<br>
>Hence the leeriness about garnering the info ceilo needs from<br>
>the public nova-api.<br>
<br>
</div>The public api has no place for this stuff. I must have missed it, but where was that being proposed? Hitting HTTP for metrics is just wrong.<br>
<div class="im"><br>
>> The existing information gathered from the hypervisors could easily<br>
>> be extended with optional sections to cover all use cases. Much the<br>
>> same way MP3 and JPG has optional data blocks. Notifications do not<br>
>> use the Nova RPC protocol and should be versioned separately from<br>
>> it. The entire structure of the notification should be changed to<br>
>> allow for these "optional" blocks ... not only for flexibility, but<br>
>> to reduce the already monstrous payload size (do we need to do 2-3<br>
>> db accesses every time we send a notification?)<br>
<br>
>So with nova-compute losing it's direct database access, then 2-3 DB<br>
>accesses per notification is not going to be a runner - all the<br>
>information we're talking about extracting here will I think have to<br>
>be available from the hypervisor, possibly mixed in with some cached<br>
>data retrieved by ceilo from the nova-api (e.g. on every polling cycle<br>
>we wouldn't want to go back to the nova-api to figure out the instance<br>
>flavor name, if that's not directly exposed by nova-compute but is<br>
>needed for metering purposes).<br>
<br>
</div>The big requirement for it today is for network information, which is already being cached in the Quantum driver. </blockquote><div><br></div><div>Quantum's knowledge about network stats does not differentiate between internal and external traffic. It's still useful for monitoring, but metering stats have to be collected somewhere else.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">If we can separate the network and the compute notifications I think we're ok. Likewise with storage. The downside is we wouldn't be getting these notifications as atomic updates and that can lead to race conditions. But, so long as the time stamps are accurate within reason (NTP), we should be ok there. If we're dropping events we've got bigger issues to deal with. </blockquote>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Another possibility we're exploring is having a read-only mirror of the production database for this sort of stuff. That could be the "best practice" in these tight situations. But that's a story for another time :)<br>

<br>
So, we need to revisit the notification format wrt versioning, structure, payload size, content and overhead. Getting the data out and doing something with it is easily do-able via a worker/consumer or a proprietary notifier (and with no impact on nova core).<br>
</blockquote><div><br></div><div>I'm not sure why any of that is necessary to solve this problem?</div><div><br></div><div>Doug</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
Next we need to be very clear on what is instrumentation and what is monitoring/usage/billing/lifecycle.<br>
<div class="im"><br>
>I'm not sure if I've really addressed all your concerns there, please<br>
>shout if not.<br>
<br>
</div>It's a good start :) Let's keep it going.<br>
<br>
(And I agree, we're not too far off)<br>
<span class="HOEnZb"><font color="#888888"><br>
-S<br>
</font></span><div class="HOEnZb"><div class="h5"><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>