dd98e10dbf
Middleware is the backbone of the whole profiler facility. It adds an encoded payload to each request that should be profiled with osprofiler library. This library is embedded into other OpenStack services where it tries to decode the message with a known set of keys (so Horizon middleware should use one of these keys) and if successful, sends a message to MongoDB (via osprofiler driver). Every message has its own id, the base id (root message id) and parent id. Using these 3 ids a tree of trace messages is assembled. Actually, Horizon Django application uses 2 middleware classes: ProfilerClientMIddleware and ProfilerMiddleware. ProfilerClientMiddleware is used to enable Horizon self-profiling (profiling from the UI): if a specific key is found in cookies, then 2 standard osprofiler headers are added to a request. These headers are processed by ProfilerMiddleware which should always be the last middleware class in a Django config, since it's defines `process_view` method which returns HttpResponse object effectively terminating the middleware process_view chain. Assuming that all API calls happen during rendering a view, Horizon sets a tracepoint there which becomes a root node of the trace calls tree. Implements-blueprint: openstack-profiler-at-developer-dashboard Change-Id: Ib896676e304f2984c011bd1b610c86d1f24d46b9 |
||
---|---|---|
.. | ||
_10_set_custom_theme.py.example | ||
_11_toggle_angular_features.py.example | ||
_20_integration_tests_scaffolds.py.example | ||
_2010_integration_tests_deprecated.py.example | ||
_9030_profiler_settings.py.example |