Logging is important. Anyone who has had a call at 3am to say the site is down knows this. Without quality logging it is almost impossible to work out what on earth is happening.
The more you log, the harder it is to track down exactly what the effects of a particular request are. Enter Django Correlation ID. Incoming requests are assigned a unique identifier. This can either happen in your public facing web server (e.g. nginx) or be applied by Django itself.
This correlation id (also known as request id) is then available through the Django request/response cycle and may be automatically included in all log messages. That way, you can easily link all log messages that relate to the same request:
2018-10-01T08:18:39.86+00:00 correlation_id=2433d5d4-27a3-4889-b14b-107a131368a3 Call to plug from cpoint=1
2018-10-01T08:18:39.90+00:00 correlation_id=72fbd7dd-a0ba-4f92-9ed0-0db358338e86 Call to state by cpoint=2 with {'state': {'B': 'idle', 'A': 'on_charge'}}
2018-10-01T08:18:39.92+00:00 correlation_id=2433d5d4-27a3-4889-b14b-107a131368a3 Ended rental=7 customer="John Smith" on plug
In this example, we can see that the first and the third log messages are tied to the same request, while the second message relates to a distinct request.
In addition to these logs, django-cid can include the correlation
id:
- in all SQL queries (as a comment);
- in rendered templates;
- as a header in the HTTP response generated by Django;
- and possibly anywhere by using the API of
django-cid, for example as an HTTP header on a request to another internal system of yours, which is especially useful in service-oriented architecture.
Documentation can be found at: https://django-correlation-id.readthedocs.org/
Sources are on GitHub: https://github.com/Polyconseil/django-cid
We currently support Python >= 3.8 and Django >= 3.1.
Other versions may work but are not supported.