openstack
/
osprofiler
Code Issues Proposed changes
OpenStack cross service/project profiler
309 Commits 2 Branches 81 Tags 4.7 MiB
Python 93.4%
HTML 4.7%
Shell 1.9%
Go to file
Ilya Shakhat 00eaa1096d Make dependency on oslo.messaging runtime only 
Oslo.messaging library is not required by OSProfiler core. It is needed
by "messaging" driver only and thus can be turn into runtime dependency
(just like client libs for other drivers).

Change-Id: Ie42cd0fdd5e96ce65b83edf934a139c282d1e784
 		2017-08-11 11:21:59 +02:00
devstack Expose connection_string parameter into DevStack plugin 2017-06-14 14:58:47 +02:00
doc doc: Fix formatting 2017-07-06 21:50:47 +00:00
osprofiler Make dependency on oslo.messaging runtime only 2017-08-11 11:21:59 +02:00
releasenotes Update reno for stable/pike 2017-07-28 21:06:02 +00:00
tools Trivial: Remove vim header from source files 2016-09-24 05:25:17 +08:00
.gitignore Update .gitignore 2017-07-06 16:24:38 +05:30
.gitreview Update .gitreview for new namespace 2015-10-17 22:34:15 +00:00
.testr.conf Add functional test for notifier backend 2016-12-15 19:36:35 +05:30
CONTRIBUTING.rst Add CONTRIBUTING.rst 2016-02-29 13:42:14 +08:00
LICENSE Init Strucutre of lib 2014-01-09 11:25:23 +04:00
README.rst Update URLs in documents according to document migration 2017-07-13 17:39:15 +08:00
requirements.txt Make dependency on oslo.messaging runtime only 2017-08-11 11:21:59 +02:00
setup.cfg Update URLs in documents according to document migration 2017-07-13 17:39:15 +08:00
setup.py Use pkg_resources to get version 2016-03-10 17:54:20 +08:00
test-requirements.txt Switch from oslosphinx to openstackdocstheme 2017-07-06 21:38:42 +00:00
tox.ini Python 3.4 support is removed 2017-03-08 12:37:37 +05:30

README.rst

Team and repository tags

image

OSProfiler -- Library for cross-project profiling library

Latest Version

Downloads

OSProfiler provides a tiny but powerful library that is used by most (soon to be all) OpenStack projects and their python clients. It provides functionality to be able to generate 1 trace per request, that goes through all involved services. This trace can then be extracted and used to build a tree of calls which can be quite handy for a variety of reasons (for example in isolating cross-project performance issues).