Either osprofiler, or oslo, it sounds to me that the tools to instrument
the code should live and developed elsewhere. Once that's done,
Instrumenting the neutron codebase does not really need a blanket
(catch-all) BP, RFE or the likes. We can simply file patches on a case
by case basis.
For this reason, I am going to mark this as "won't fix", for the simple
reason that nothing else is left for Neutron to do rather than adopting
an openstack widely accepted instrumentation methodology (either to be
developed or extended), once is ready, and add instrumentation calls
where we see fit.
** Changed in: neutron
Status: Triaged => Won't Fix
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1512864
Title:
Application Metrics for Neutron
Status in neutron:
Won't Fix
Bug description:
Problem
--------
Currently, there is no application-metrics framework to measure neutron
behavior,
and identify trends and problems in operation. RPC latencies, HW programming
latency
(for security-groups, ovs), API latencies, DB latencies come to mind
immediately as metrics
which need to be monitored, trended, and analyzed continuously and in
real-time in operation.
Logs are useful but they do not capture tagged metrics data in a
format that can be easily analyzed.
This is filed as a RFE bug (following the blueprint protocol) and
this can be upgraded to a blueprint after discussion/inputs.
Fix
----
Provide a simple library that has the following components:
1) A metrics front end
provide at the least the following apis
@timeit(tag) - a decorator to time functions or code blocks.
increment(tag)
decrement(tag)
set_value(tag, value)
2) Metrics processor
A class that can provide functionality like: sampling, throttling
metrics data etc.
3) Configurable Metrics output driver
statsd-driver : output to statsd server
graphite/carbon driver: output to carbon server
logfile driver: output to logfile
With the above library, neutron code is instrumented to add tagged
metrics. The outcome is that neutron continuously emits metrics in
operation.
Example Usecases
------------------
1) Time a function or code block
@metrics.timeit
def _apply(self):
Example output data (in graphite format)
neutron.agent.linux.iptables_manager._apply 319.076061249 1446328923
neutron.agent.linux.iptables_manager._apply 274.07002449 1446328925
Notes
------
1) Swift already has "statsd" based application metrics, and serves as an
example for what we want in this RFE bug.
See:
https://review.openstack.org/#/c/6058/
2) See following for related efforts which are more extensive in their reach
- what we want is much simpler to begin with as done in the swift project.
https://github.com/timjr/tomograph
http://twitter.github.io/zipkin/
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1512864/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
