Open Stack

On Mon, Jan 7, 2013 at 10:19 AM, Eoghan Glynn <eglynn at redhat.com> wrote:

>
>
> > Hi, Doug
> >       As a follow--up with you on the counter frequency discussion, I
> >       create a wiki page at
> >
> http://wiki.openstack.org/Ceilometer/blueprints/publisher-counters-frequency
> >       . Please have a look on it.
>
> Some initial thoughts ...
>
> "The pollster will decide the polling interval based on the GCD
> of interval requirement for all of it's counters."
>
> Would it make sense to factor out from the pollsters this common
> logic to calculate the period GCD?
>
> Also, should we constrain the possible periods to avoid lots of
> irregularity (e.g. just allow 1s, 10s, 60s & multiples thereof),
> or make it completely free form?
>

We need to specify a minimum. I'm not sure whether we need to be more
strict than that, though. Did you have an example of an issue that might
come up if we allow arbitrary values? We should also be clear that we're
ensuring a minimum interval, not an absolute rate, for the data. We can't
be sure how long it will take to collect a given piece of data, and if
there is a long list of counters even the publishing may get in the way of
delivering as quickly as is requested.


>
> "... the compute/central service will create a timer for each
> pollster based on it's polling interval"
>
> Do we need a separate timer for each pollster, even when the periods
> are common?
>
> "A interval transformer provided to support different
> interval. Considering followed counters sequence as "c0, c1, c2,
> c3 ..." for resource_1 and c3 happens "interval time" after c0."
>
> Is the implicatyion here that *all* counters associated with a
> pollster are calculated on the most granular interval, then the
> more coarse-grained values are eventually discarded in the
> transformer chain?
>
> That would be fine if only a single measurement (e.g. call out
> to a public API service or hypervisor daemon) is required for
> all the pollster's counters. But if multiple measurements are
> required, would it make sense to avoid the measure-and-discard
> pattern?
>

Yes, we shouldn't be collecting data we know we aren't going to use.

Doug


>
> Cheers,
> Eoghan
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> 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/20130107/f4272a1c/attachment.html>