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
dd98e10dbf