<br><br><div class="gmail_quote">On Fri, Nov 9, 2012 at 3:09 AM, Domas Monkus <span dir="ltr"><<a href="mailto:domas.monkus@canonical.com" target="_blank">domas.monkus@canonical.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi,<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
collector {<br>
  <a href="http://disk.io" target="_blank">disk.io</a>: 300,<br>
  instance: 60,<br>
  *: 600,<br>
}<br>
<br>
cloudwatch {<br>
  cputime: 300,<br>
 *: 0,<br>
}><br>
would mean the ceilometor-collector publisher would require <a href="http://disk.io" target="_blank">disk.io</a><br>
counters every 5 minutes, instance every minute, and the reset every 10<br>
minutes.<br>
</blockquote>
<br></div>
Since I am new to the ceilometer project and since a publisher is not mentioned in the architecture (<a href="http://ceilometer.readthedocs.org/en/latest/architecture.html" target="_blank">http://ceilometer.<u></u>readthedocs.org/en/latest/<u></u>architecture.html</a>), I want to make sure I understand everything clearly.<br>
</blockquote><div><br></div><div>Some of the things we are talking about in this thread do not exist yet, so they are not in the documentation or diagram.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
Am I right in understanding that the ceilometer-collector publisher is the [collector] component in the architecture diagram? Then the cloudwatch component must be the [central agent]. If I am correct, then I think there is a misunderstanding lurking somewhere here.<br>
</blockquote><div><br></div><div>The ceilometer-collector daemon is the collector component in the architecture diagram.</div><div><br></div><div>The cloudwatch component is not yet part of ceilometer, and is not represented in the diagram.</div>
<div><br></div><div>The central agent in the diagram polls services that do not run on the compute node (glance, quantum, etc.). The compute agent only polls services that run on the compute node.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
Since the feature to be implemented is centred around different polling intervals for pollsters, it is unclear to me how the collector component comes into play. If my reading of the ceilometer architecture and documentation is correct, the collector does not interact with pollsters directly, but listens to the information they emit (via the central agent) on the event bus. Does this mean that the collector should be able to aggregate metering information emitted by pollsters and publish it on the bus only at set intervals, even though the pollsters may be emitting it more frequently?<br>
</blockquote><div><br></div><div>The collector receives two types of inputs. Notifications come from all OpenStack components and the plugins for the collector turn them into metering events which are republished to the bus by the collector. The collector also receives metering events from the ceilometer agents.</div>
<div><br></div><div>When we talk about setting the intervals the metering events are emitted, we are (I think) talking primarily about the pollsters in the agents. The notification messages tend to be "auditing" events (an instance or volume still exists, for example) and so they do not need to come at a high frequency. The CPU or bandwidth utilization of an instance will need to be measured more frequently in order to have it trigger alarms for cloudwatch-like functionality.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
On a similar note, since agent plugins (e.g. plugins of the compute agent) are also polled at a set interval, will we need to support different polling intervals for these too?<br></blockquote><div><br></div><div>Yes.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
And finally, as I understand, a single pollster can emit several measurements. Will the polling frequency be set per-pollster or per-pollster's-measurement? This is an important question, since the solution will vary depending on the decision.<br>
</blockquote><div><br></div><div>The pollsters are managed at the plugin level, so it will be simpler to set the controls there rather than at the individual meter. We can always break meters out into their own plugin if we need to control their rates separately.</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>
<br>
Best regards,<br>
Domas Monkus<div class="HOEnZb"><div class="h5"><br>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</div></div></blockquote></div><br>