[openstack-dev] [Ceilometer][Metering] Metadata on Meter table - use cases from StackTach ...

Sandy Walsh sandy.walsh at rackspace.com
Wed Jan 30 14:04:37 UTC 2013

On 01/29/2013 05:43 PM, Angus Salkeld wrote:
> On 29/01/13 14:31 +0000, Sandy Walsh wrote:
>> Here is a little video I put together to explain the StackTach data
>> model and some of the use cases we faced to get meaningful info out of
>> the system.
>> I did this to re-kick the discussion around metadata on the Meter
>> table in Ceilometer.
>> We're going to need rich indexing on the metadata and there's going to
>> be a lot of data, will the currently proposed scheme work or will we
>> need to introduce custom Meters to solve the problem?
>> (Currently we're at 10-12 million rows for 90+ days of raw
>> notifications from our RAX deployment. This is all running on a single
>> 2G instance with Apache, MySql, StackTach and the Workers all running
>> on the same box)
>> http://www.youtube.com/watch?v=B-zd0GW9eY0
>> Initial thoughts on the RichMeter approach (before learning about the
>> Dimension/Metadata table proposal): http://wiki.openstack.org/RichMeters
> Nice walk through, I need to try digest how that is all going to fit
> together.
> It initially seems to me that there is a new entity
> "Notification/TracePoint"?
> They don't really seem like meters, and it might make sense to just model
> correctly rather than trying to squeeze them into meters.

I see it as a Meter + Better Metadata ... if that db model is scalable.
The raw json payload however might be a different animal. But it
certainly should be archived.

> So we could have:
> Resources
> -> Meters
> -> Notifications

Yep, that might be the case.

> Immediately stuff the notifications into the db, and either inline or in
> parallel
> generate the meters from the notifications. I suppose another option is
> to have
> calculated Meters that only get created on request. So you ask for the
> request
> duration for resource X and it calculates the Meter samples on the fly
> from the
> notifications - or not, just thinking out aloud:)

The problem is jitter in processing the notifications. I talked about
this here http://wiki.openstack.org/RaxCeilometerRequirements under
"settle time". Once you have multiple workers pulling notifications
ordering will get lost so you have to put a delay in there.

I have a proposal for dealing with this, but I think I'll stick to this
issue first. :)

> This way we could have simple Meters and rich notification history? Also
> add that
> as a first class entity to the API.


> Notification might be a bit of generic name for this maybe TracePoint?

Hmm, tracepoint doesn't strike a chord with me (sounds like stacktrace).
Perhaps Raw?
> -Angus

Thanks for the feedback!

>> Hope it helps!
>> -S
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

More information about the OpenStack-dev mailing list