Open Stack

On 11/09/2012 09:09 AM, Domas Monkus 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), I want
> to make sure I understand everything clearly.
> 
> 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.

Yes, this is one example of a collector.  The idea here is to extend the
mechanism so that any agent can know about multiple destination that it
can use to send data at different interval.

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

No, it just means that each agent should be able to accept a list of
publishers, one of then being a "send to ceilometer collector"
publisher.  For each publisher, you should be able to set, on a per
counter/meter basis the frequency at which the data should be sent.

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

Per polster/meter/counter.

> Best regards,
> Domas Monkus

For more details have a look at the following 2 blueprints:

https://blueprints.launchpad.net/ceilometer/+spec/multi-publisher
https://blueprints.launchpad.net/ceilometer/+spec/publisher-counters-frequency

I would guess that the first task would be to break down the work as use
cases for each blueprint in a detailed spec and go at it with some first
implementation.

Cheers,
Nick



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 897 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121109/362dcf17/attachment.pgp>