uWSGI Logging Monitoring Harakiri

Introduction

Running uWSGI in production without monitoring invites midnight 504 errors. Logging aids diagnosis, monitoring enables proactive alerts, harakiri insures against infinite loops and slow requests.

uWSGI offers built-in logrouter, multiple loggers, stats server, and harakiri; basic observability without external tools.

This article covers log configuration, metric collection, harakiri parameters, and Prometheus integration.

Log Configuration

logto /var/log/uwsgi/app.log writes all logs to one file. log-master = true includes master process logs. req-logger and logger route to different targets.

log-4xx = true and log-5xx = true log error responses in detail. log-x-forwarded-for = true reads real client IP from X-Forwarded-For.

[uwsgi]
logto = /var/log/uwsgi/myapp.log
log-master = true
log-4xx = true
log-5xx = true
log-x-forwarded-for = true
disable-logging = false

Multiple Targets with Logrouter

logrouter regex routes log lines to different files. Critical errors can go to a separate file; manage with logrotate.

For syslog use log-syslog = true or logger = syslog. Ideal for central log aggregation (ELK, Loki).

logrotate ile günlük rotasyon
syslog ile merkezi toplama
JSON format için custom logger
log-reopen SIGUSR1 ile yeniden açma

[uwsgi]
logto = /var/log/uwsgi/app.log
log-route = ^\[ERROR\] /var/log/uwsgi/errors.log
log-route = ^\{address.*\} /var/log/uwsgi/access.log

Stats Server and Metrics

stats = /run/uwsgi/stats.sock exposes JSON metrics: worker count, requests, memory, average response time. Read with uwsgi --connect-and-read /run/uwsgi/stats.sock.

stats-http = true opens /json and /csv endpoints over HTTP; scraped by Prometheus uwsgi_exporter.

[uwsgi]
stats = /run/uwsgi/stats.sock
stats-http = true
stats-http-port = 9191
memory-report = true

Harakiri Mechanism

harakiri = 30 kills workers on requests longer than 30 seconds. harakiri-verbose = true logs details. harakiri-no-ar behaves differently in async mode.

On infinite loops, slow DB queries, or deadlock, harakiri prevents exhausting the entire worker pool. Tune to your workload; too low kills normal requests.

[uwsgi]
harakiri = 60
harakiri-verbose = true
socket-timeout = 30
http-timeout = 60

harakiri değerini en uzun meşru istek sürenizin %20 üstüne ayarlayın; rapor export gibi işlemler için istisna route tanımlayın.

Alerting Strategies

Alert when worker count drops to zero or reload loop starts. Trigger PagerDuty when avg_response_time from stats JSON exceeds threshold.

Build Grafana dashboards with uwsgi_exporter metrics: uwsgi_workers, uwsgi_requests_total, uwsgi_response_time.

Stats socket veya HTTP exporter kurun
Worker ve bellek eşikleri tanımlayın
Log hatalarını merkezi sisteme yönlendirin
Harakiri loglarını düzenli inceleyin

Production Checklist

Is logto and logrotate configured? Is stats socket active? Is harakiri at production value? Is memory monitored with memory-report?

Keep disable-write-exception = false; exception tracebacks should appear in logs. py-autoreload must be off in production.

# logrotate /etc/logrotate.d/uwsgi
/var/log/uwsgi/*.log {
    daily
    rotate 14
    compress
    missingok
    postrotate
        kill -USR1 $(cat /run/uwsgi.pid)
    endscript
}

Conclusion

Logging, monitoring, and harakiri are the foundation of uWSGI production stability. Built-in stats server suffices for simple setups; add Prometheus + Grafana at scale.

Review harakiri values regularly; longest request times change as the app evolves. Do not keep logs only on disk; forward for central analysis.

Data Usage Notice