openstack
/
osprofiler
Code Issues Proposed changes
OpenStack cross service/project profiler
169 Commits 2 Branches 81 Tags 4.7 MiB
Python 93.4%
HTML 4.7%
Shell 1.9%
Go to file
Thomas Bechtold e8079b2ec3 Don't set html_last_updated_fmt without git 
Using a timestamp as value for "html_last_updated_fmt" isn't good
for the reproducible builds initiative from different downstream
distributions because the build result always differs due to the
timestamp in the documentation.
Also when not setting "html_last_updated_fmt", the value can be set
via command line when running "sphinx-build -D".

Change-Id: Ia23451e6b53f6f83dd22e069ef42a4a067ec5881
 		2016-06-01 11:08:15 +02:00
devstack Add raw Ceilometer events support to DevStack plugin 2016-01-27 16:39:37 +03:00
doc Don't set html_last_updated_fmt without git 2016-06-01 11:08:15 +02:00
osprofiler Merge "Add exception type to stop trace info" 2016-05-19 11:30:28 +00:00
tools Init Strucutre of lib 2014-01-09 11:25:23 +04:00
.gitignore Add DevStack plugin 2016-01-14 01:41:39 -08:00
.gitreview Update .gitreview for new namespace 2015-10-17 22:34:15 +00:00
.testr.conf Move osprofiler tests into osprofiler 2016-01-25 12:12:45 -08:00
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 Continue work on standardizing osprofiler docs 2016-03-24 21:35:30 -07:00
requirements.txt Use oslo.utils reflection and avoid refinding decorated name 2016-01-25 12:42:21 -08:00
setup.cfg Merge "remove python 2.6 trove classifier" 2016-02-12 02:14:12 +00:00
setup.py Use pkg_resources to get version 2016-03-10 17:54:20 +08:00
test-requirements.txt Enable bandit in gate 2016-03-03 11:30:00 +08:00
tox.ini Enable bandit in gate 2016-03-03 11:30:00 +08:00

README.rst

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).