Django is a web framework used in a wide variety of websites. It just takes a quick web search to discover which large companies use it as a production platform. And the reason for this is simple—it lets developers quickly deploy a website. Some of Django’s features include security and scalability right out of the box so developers can focus on their code.
Though Django comes with some great features to launch an application, you also need to make sure the application performs as expected both at launch and throughout its life span. Once in production, having no errors is a big part of the user experience. You need to keep an eye on the whole environment, but you especially need to know what to look at—and what to look for in monitoring tools.
What to Measure
There are many metrics of which you should be aware, but depending on the stage your application is in and who’s looking at it, different metrics may matter more. To demonstrate, let’s group metrics by audience.
Key Performance Indicators (KPIs) for Developers
Error Rate
First and foremost, you want to ensure your code produces no errors. Every request must produce a valid response, even if the response contains an error message. If it fails, you must dig deep enough to find the root cause and solve the problem.
Response Time
The request must also take the least amount of time possible, depending on the problem. Waiting for the result of a process analyzing data isn’t the same as waiting for a simple notification. This metric may be difficult to measure, even more so after the code is deployed to production when there are other elements—such as network activity or database response time—to account for. However, similar conditions should produce the same results.
KPIs for System Administrators
Resource Use
After you deploy your application to production, it’s important to closely monitor other metrics:
- CPU usage. Proper use of CPU time means taking advantage of the available processing power to execute your code efficiently. More available resources means more processing power to respond faster or digest more data. As long as no errors occur, if you’re using 100% CPU, you’re using it in the most efficient way. Still, if errors occur and they don’t derive from the code, you may need to scale up. On the other hand, if your CPU usage is low most of the time, you may be wasting CPU capacity.
- I/O. I/O goes hand in hand with CPU, as slow access to disk will impact CPU usage and mostly waste CPU resources. Operations such as checking permissions, remote storage, data encryption, and disk failures affect I/O rates and are reflected in your application’s performance.
- Memory. More memory means faster access to data, thus reducing processing time and avoiding waits derived from disk access.
- Network. In current distributed systems, you may have a bunch of Django servers talking to a remote database and writing files to network file systems. All elements may also require secondary replicas to achieve data redundancy. In this scenario, a fast and reliable network is paramount to make sure the application works and response times are under a certain threshold.
Security and Alerts
System administrators must have a mechanism in place to ensure system security. Most metrics here go hand in hand with tools scanning applications, looking for vulnerabilities, and classifying them. Notification of such findings and remediation will depend more on the business priorities. This guide can provide more insight on these indicators.
KPIs for Management
Management has a different way of looking at metrics. Usually, they’re more interested in the overall application performance and resource utilization. They’ll use this information to predict application usage, anticipate product success, or forecast costs. No application downtime means a better experience for their customer, which may turn into additional earnings.
Interaction With External Components
The previous metrics are directly related with Django and how it behaves as a single entity. However, interactions with external entities always influence application behavior directly or indirectly, and they influence Django metrics, too. Here are some elements to consider:
Working With Databases
When measuring request response time, you must consider three steps:
- Connectivity: The time it takes your application to open a database connection, send the query, and obtain a response.
- Query execution: The time it takes the database to execute the query producing the necessary data output.
- Data processing: The time it takes your application, once it has received a response from the database, to process the information (i.e., either to format it and send it to the client or perform additional processing to produce the output requested).
Correlating these metrics with Django logs will provide a better view of performance and can help diagnose performance issues.
Connecting to Remote Storage
Storage limits
Nowadays, it’s common not to store files locally within the same server as Django. Instead, it’s common to send them to remote storage, where they can be viewed by other servers and other processes. Although remote storage is big, file space isn’t infinite, and there are always restrictions, whether they’re physical or by design.
Permissions
A proper set of access rules must always be in place—it’s even required by law in many countries. Errors noticed in Django may be the result of an access configuration
Production Infrastructure
Although development and production environments look similar due to container technology, there are still differences with the potential to affect a Django application, given resource availability or security restrictions. These may give way to unforeseen errors or system limitations.
Django Monitoring
Now that you have an overall idea of which metrics to watch, you need to know the tools available to perform such operations.
Logging
This is one of the most common ways to monitor Django. It uses Python’s logging module to perform system logging.
There are five log levels:
- DEBUG
- INFO
- WARNING
- ERROR
- CRITICAL
Once a log record is received, it’ll be handled or filtered according to its level.
This is a small example of log configuration:
import os
LOGGING = {
'version': 1,
'disable_existing_loggers': False,
'handlers': {
'console': {
'class': 'logging.StreamHandler',
},
},
'root': {
'handlers': ['console'],
'level': 'WARNING',
},
}
And this is how you use it:
import logging
# Get an instance of a logger
logger = logging.getLogger(__name__)
def my_view(request, arg1, arg):
...
if bad_mojo:
# Log an error message
logger.error('Something went wrong!')Django Packages
Another way to monitor Django is to use packages. Packages are Django projects designed to integrate into Django to add more functionality. There are a wide variety of them for our purposes; you can take a look at some of them here:
These packages are open-source and ready to be added to your Django project. On the other hand, they may not be updated to work with the latest version, or they may not include the metrics you require.
Django Services
Finally, another way to monitor Django is to use a cloud service. These services have a few advantages: they require little configuration, they can provide you with the above metrics, and you can perform additional analysis with your data. This makes them suitable for developers, system administrators, and management. You can also integrate other systems and metrics, bringing all your systems together into a single monitoring tool.
Final Thoughts
To monitor a Django application, you need to know what information is relevant for you. Most of the time, the application also interacts with external elements, and these elements have an impact on overall performance. There are many ways to monitor a Django application, either with logs, packages, or cloud services. As a recommendation, take a look at SolarWinds Observability SaaS (formerly known as SolarWinds Observability) and all the features it has so you can improve your monitoring experience.
This post was written by Juan Pablo Macias Gonzalez. Juan is a computer systems engineer with experience in back-end and front-end databases and systems administration.