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.
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
