Yes, I think support for metrics objects that can be leveraged both by monkey patches and decorators was what we'd been thinking along the lines of. The metrics would be controlled via config both in what scopes are active (e.g. on|off for a package, module, etc.) and also the outlet for the metrics (file, datagram, rpc). Support for instrumentation levels would also be nice so that metric flow could be controlled (i.e. instrumentation point is annotated as METRIC, MONITOR, PROFILE and then level to actually emit can be set in conjunction with a metric outlet/sink). With this approach, folks could control both the volume of metrics and also the outlet for the metrics. Ceilometer would also be an outlet that could be leveraged via RPC flow for metrics -- though I'd expect some would want to send via datagram to statsd or file for offline log aggregation.
I'll post a diagram tomorrow for review and comment. Oh btw, I updated the spec with most of what was in the etherpad. We can update the spec to reflect whatever we decide is the preferred approach. -jeff On Oct 25, 2012, at 5:30 PM, Angus Salkeld wrote: > On 25/10/12 11:13 +0000, Sandy Walsh wrote: >> grizzly-common-instrumentation seems to be the best choice ... hopefully the >> other groups will use this etherpad too. >> >> We need a proper blueprint to nail down the approach. IRC is great, but >> doesn't retain history for other groups. I think we need to get a plan for >> translating the etherpad into something concise and nailed down. > > Agree. > >> >> statgen should really just be a new notifier in Tach (or Scrutinize) ... vs >> copy-pasting the code into yet-another repo. Hopefully that's the plan? >> Tach should remain a generic tool and not pegged to OpenStack. > > Well that was just an "ideas play pen" not serious code. > > I might be coming at this from a slightly different angle... > I was looking at a library that can be used to generate trace, monitoring > and metering data (kind of like log levels for logging). Currently both > Tach and Scrutinize don't have enough fields (of course that could be > changed). > > Also I think we should be able to insert instrumentation into the code as well > as have the function level performance metrics monkey patched. > > Then we could have a config that directed metric data to different notifiers > like how you do it in Scrutinize perhaps. Also enforcing data rate limits > and possible data aggregation could be neat configurable features. > > Anyway more at the meeting... > > -Angus > >> >> -S >> ________________________________________ >> From: openstack-bounces+sandy.walsh=rackspace....@lists.launchpad.net >> [openstack-bounces+sandy.walsh=rackspace....@lists.launchpad.net] on behalf >> of Angus Salkeld [asalk...@redhat.com] >> Sent: Thursday, October 25, 2012 1:00 AM >> To: openstack@lists.launchpad.net >> Subject: Re: [Openstack] Ceilometer, StackTach, Tach / Scrutinize, >> CloudWatch integration ... Summit followup >> >> On 24/10/12 23:35 +0000, Sandy Walsh wrote: >>> Hey y'all, >>> >>> Great to chat during the summit last week, but it's been a crazy few days >>> of catch-up since then. >>> >>> The main takeaway for me was the urgent need to get some common libraries >>> under these efforts. >> >> Yip. >> >>> >>> So, to that end ... >>> >>> 1. To those that asked, I'm going to get my slides / video presentation >>> made available via the list. Stay tuned. >>> >>> 2. I'm having a hard time following all the links to various efforts going >>> on (seems every time I turn around there's a new metric/instrumentation >>> effort, which is good I guess :) >> >> Here is some fun I have been having with a bit of tach+ceilometer code. >> https://github.com/asalkeld/statgen >> >>> >>> Is there a single location I can place my feedback? If not, should we >>> create one? I've got lots of suggestions/ideas and would hate to have to >>> duplicate the threads or leave other groups out. >> >> I'll add some links here that I am aware of: >> https://bugs.launchpad.net/ceilometer/+bug/1071061 >> https://etherpad.openstack.org/grizzly-common-instrumentation >> https://etherpad.openstack.org/grizzly-ceilometer-actions >> https://blueprints.launchpad.net/nova/+spec/nova-instrumentation-metrics-monitoring >> >> >>> >>> 3. I'm wrapping up the packaging / cleanup of StackTach v2 with Stacky and >>> hope to make a more formal announcement on this by the end of the week. >>> Lots of great changes to make it easier to use/deploy based on the Summit >>> feedback! >>> >>> Unifying the stacktach worker (consumer of events) into ceilometer should >>> be a first step to integration (or agree upon a common YAGI-based consumer?) >>> >>> 4. If you're looking at Tach, you should also consider looking at >>> Scrutinize (my replacement effort) https://github.com/SandyWalsh/scrutinize >>> (needs packaging/docs and some notifier tweaks on the cprofiler to be >>> called "done for now") >> >> Looks great! I like the monkey patching for performance as you have >> done here, but we also need a nice clean way of manually inserting >> instrumentation >> too (that is what I have been experimenting with in statgen). >> >> Can we chat in #openstack-metering so we are a bit more aware what we are >> all up to? >> >> >> -Angus >> >>> >>> Looking forward to moving ahead on this ... >>> >>> Cheers, >>> -S >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Mailing list: https://launchpad.net/~openstack >>> Post to : openstack@lists.launchpad.net >>> Unsubscribe : https://launchpad.net/~openstack >>> More help : https://help.launchpad.net/ListHelp >> >> _______________________________________________ >> Mailing list: https://launchpad.net/~openstack >> Post to : openstack@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~openstack >> More help : https://help.launchpad.net/ListHelp > > _______________________________________________ > Mailing list: https://launchpad.net/~openstack > Post to : openstack@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
