Monitor Django applications on Kubernetes
Connect Django request outcomes, database and cache health, worker behavior, Kubernetes state, and release context in one monitoring strategy.
A Django Pod can be Running while requests time out behind exhausted workers or database connections. A healthy database does not prove that the application can authenticate users, enqueue work, or reach a model service. Monitoring needs to start with user-visible outcomes and preserve enough application, dependency, and Kubernetes context to explain them.
Build the strategy around questions operators need to answer, not around whichever metrics a library exports by default.
Define service objectives
Choose objectives for important request classes:
- successful completion rate;
- p50, p95, and p99 latency;
- availability over the intended window;
- queue acceptance and completion for asynchronous work;
- freshness for scheduled or cached results.
Separate interactive requests from long-running ML work. A Django endpoint that submits a Polyaxon operation should acknowledge a durable submission quickly and return a run identifier; it should not hold the request open for the complete training job.
Alert on sustained impact or error-budget consumption rather than every individual exception.
Instrument the request path
Measure request count, status class, and duration by stable route template and method. Do not use raw paths, user IDs, or arbitrary query values as metric labels.
Trace a representative request through middleware, view logic, database or cache calls, task submission, and external services. Propagate a correlation identifier to logs and traces, and record the resulting Polyaxon run identifier when the request launches ML work.
Keep request and response payload capture disabled by default. Authentication data, prompts, uploads, and model output need explicit privacy and redaction policy.
Monitor Django dependencies
Track each required dependency separately:
| Dependency | Useful evidence |
|---|---|
| Database | Query latency, errors, connection use, transaction duration |
| Cache | Hit ratio, latency, eviction, errors, fallback behavior |
| Queue or broker | Publish latency, depth, age, retries, dead letters |
| Object storage | Request latency, error class, bytes transferred |
| Identity service | Authentication latency and bounded failure class |
| Polyaxon API | Submission latency, accepted run ID, status retrieval errors |
Avoid enabling unrestricted SQL logging in production. It can expose parameters, generate high volume, and distort performance. Prefer aggregate query metrics and targeted traces with controlled statement capture.
Observe the process model
Django can run under WSGI or ASGI servers with multiple processes, threads, or asynchronous workers. Monitor the actual server configuration:
- active and queued requests;
- worker utilization and restarts;
- process resident memory;
- event-loop delay for asynchronous workers where applicable;
- graceful-shutdown duration;
- timeout and cancellation behavior.
A memory leak may appear as periodic Pod restarts if a process manager recycles workers. A concurrency limit may look like low CPU with high queue time. Record worker configuration with each deployment so a performance change can be attributed correctly.
Design health endpoints by decision
Use Kubernetes probes for distinct actions:
- startup confirms initialization finished;
- readiness decides whether the Pod should receive traffic;
- liveness detects a local state a restart can repair.
Keep liveness independent of shared downstream systems. If every replica restarts when the database is briefly unavailable, the probe amplifies the outage. Readiness may account for a required dependency, but its checks must be cheap, bounded, and designed to avoid synchronized flapping.
Our Kubernetes probes guide covers these failure-mode distinctions.
Correlate with Kubernetes
Join application signals with image digest, Deployment revision, Pod, node, namespace, restart reason, readiness transitions, CPU throttling, memory use, network errors, and autoscaling activity.
If latency rises only on one node, investigate node or network behavior. If it follows a deployment revision, compare code, dependencies, configuration, and worker settings. If all Pods are healthy while requests fail at the edge, inspect ingress and load-balancer evidence.
Validate production configuration
Use Django's official deployment checklist as a baseline. Confirm DEBUG is disabled, secrets are protected, allowed hosts and HTTPS settings are correct, static and uploaded media have an appropriate serving path, and error reporting is configured.
Run Django system checks during the release workflow, but do not treat them as live monitoring. They validate configuration patterns; they do not prove that production dependencies and traffic are healthy.
Connect monitoring to releases and runs
Every dashboard and alert should identify the environment, service version, image digest, and recent change. For endpoints that orchestrate ML workloads, preserve the mapping from web request to Polyaxon run and from run to artifacts and outcome.
Use Django logging on Kubernetes for application-event design and Polyaxon platform observability for deployment health. The combined view should answer three questions quickly: what users experienced, which component caused it, and which release or infrastructure state introduced the change.