Open Stack

On 7/31/14, 1:06 AM, Eoghan Glynn wrote:
>
>
>> Swift is already emitting those numbers[1] in statsd format; could
>> ceilometer consume those metrics and convert them to whatever
>> notification format it uses?
>
> The problem with that approach, IIUC, is that the statsd metrics
> provide insufficient context.
>
> Ceilometer wants to meter usage on a per-user & per-tenant basis,
> so captures[1] the http-x-user-id and http-x-tenant-id headers from
> the incoming request for this purpose.
>
> Similarly, the resource-id is fabricated from the swift account.
>
> I don't think this supporting contextual info would be available
> from raw statsd metrics, or?

Good point. Adding per-user and per-tenant fields to the statsd metrics 
is the wrong way to go on a couple of levels. First, it would leak 
Keystone-isms into the core Swift code, which is at odds with Swift 
having pluggable auth systems. Second, it would immediately wreck anyone 
who's got the statds metrics flowing into Graphite, as suddenly there'd 
be lots of new metrics for every single tenant/user pair, which would 
rapidly fill up the Graphite system's disks until it fell over.

I think your suggestion elsewhere in the thread of combining multiple 
API calls into a single notification is a better way to go. That'll 
certainly result in less client-visible slowdown from sending 
notifications, particularly if the notifications are sent in a separate 
greenthread.