Open Stack

On Fri, Nov 9, 2012 at 3:09 AM, Domas Monkus <domas.monkus at canonical.com>wrote:

> Hi,
>
>
>  collector {
>>   disk.io: 300,
>>   instance: 60,
>>   *: 600,
>> }
>>
>> cloudwatch {
>>   cputime: 300,
>>  *: 0,
>> }>
>> would mean the ceilometor-collector publisher would require disk.io
>> counters every 5 minutes, instance every minute, and the reset every 10
>> minutes.
>>
>
> Since I am new to the ceilometer project and since a publisher is not
> mentioned in the architecture (http://ceilometer.**
> readthedocs.org/en/latest/**architecture.html<http://ceilometer.readthedocs.org/en/latest/architecture.html>),
> I want to make sure I understand everything clearly.
>

Some of the things we are talking about in this thread do not exist yet, so
they are not in the documentation or diagram.


>
> 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.
>

The ceilometer-collector daemon is the collector component in the
architecture diagram.

The cloudwatch component is not yet part of ceilometer, and is not
represented in the diagram.

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.


>
> 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?
>

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.

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.


>
> 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?
>

Yes.


>
> 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.
>

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.

Doug


>
>
> Best regards,
> Domas Monkus
>
>
> ______________________________**_________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.**org <OpenStack-dev at lists.openstack.org>
> http://lists.openstack.org/**cgi-bin/mailman/listinfo/**openstack-dev<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121109/833d64c9/attachment.html>