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