Djangocon EU: beyond print() debugging: observability for Django apps - Laís Carvalho¶
(One of my summaries of the 2026 Djangocon EU in Athens).
OpenTelemetry (or OTel) is an open source vendor-neutral way of observering your app. There are lots of vendors, open source projects, language support, integrations.
What is observability? Understanding the inner works of a system from the outside. So: “why is this happening?”. For observability you need proper instrumentation. It is all about “signals” (or symptoms) and “causes”.
There are three pillars of observability:
Logs. A log message is normally a datetime, a level and a message. If you have a logfile, it can be hard to group the individual log messages that belong together: everything is in one long undifferentiated list.
Traces are more elaborate. Log items now have start/end datetimes and they can be nested.
Metrics. A collection of datapoints at intervals. When stored with timestamps, it becomes a timeseries. For instance a timeseries with the duration of all the web requests.
Monitoring and observability according to her definition: monitoring is what is happening, observability is about what happened.
Signals and causes. A signal might be “my website is showing lots of Error 500’s”, a cause might be “my database is down”.
When in doubt about your system health, measure these four:
Latency: time to serve requests. (ms)
Traffic: load in the django app. (req/sec)
Errors: rate of failed requests 4xx/5xx.
Saturation: how full the system is.
You can also monitor your AI usage. Requests that you make, the time it takes, whether you get errors, etc. There’s OpenLLMetry: opentelemetry instrumentation for LLM providers. “Evals” are apparently important, there’s info on hamel.dev about that.
Unrelated photo explanation: a trip in November to the Mosel+Eifel region in Germany. The elaborate castle ruins of the “Niederburg” in Manderscheid.