uWSGI logging configuration that could be used with central logging servers such as Logstash, Fluentd, etc.
[uwsgi]
project = some_project
...
# file: prefix is required for req-logger
req-logger = file:/var/log/%(project)/%(project)_access.log
log-format = "method": "%(method)", "uri": "%(uri)", "proto": "%(proto)", "status": %(status), "referer": "%(referer)", "user_agent": "%(uagent)", "remote_addr": "%(addr)", "http_host": "%(host)", "pid": %(pid), "worker_id": %(wid), "core": %(core), "async_switches": %(switches), "io_errors": %(ioerr), "rq_size": %(cl), "rs_time_ms": %(msecs), "rs_size": %(size), "rs_header_size": %(hsize), "rs_header_count": %(headers)
log-req-encoder = format {"timestamp": "${strftime:%%Y-%%m-%%dT%%H:%%M:%%S}", "event": "uwsgi_request", ${msg}}
log-req-encoder = nl
daemonize = /var/log/%(project)/%(project).log
Access logs will have JSON format like following:
{"timestamp": "2014-09-09T09:21:28", "event": "uwsgi_request", "method": "GET", "uri": "/some_path?some_arg=some_value", "proto": "HTTP/1.1", "status": 200, "referer": "https://referrer.domain.com/", "user_agent": "Mozilla/5.0 (X11; Linux x86_64; rv:28.0) Gecko/20100101 Firefox/28.0", "remote_addr": "10.0.0.1", "http_host": "example.domain.com", "pid": 8450, "worker_id": 1, "core": 99, "async_switches": 3, "io_errors": 0, "rq_size": 0, "rs_time_ms": 31, "rs_size": 154, "rs_header_size": 105, "rs_header_count": 3}
It's pretty hard to read an actual JSON one-liner, so here is a formatted version:
{
"timestamp": "2014-09-09T09:21:28",
"event": "uwsgi_request",
"method": "GET",
"uri": "/some_path?some_arg=some_value",
"proto": "HTTP/1.1",
"status": 200,
"referer": "https://referrer.domain.com/",
"user_agent": "Mozilla/5.0 (X11; Linux x86_64; rv:28.0) Gecko/20100101 Firefox/28.0",
"remote_addr": "10.0.0.1",
"http_host": "example.domain.com",
"pid": 8450,
"worker_id": 1,
"core": 99,
"async_switches": 3,
"io_errors": 0,
"rq_size": 0,
"rs_time_ms": 31,
"rs_size": 154,
"rs_header_size": 105,
"rs_header_count": 3
}
i'm finding that the trouble is with the supported JSON encoder is that all of the fields we want in the JSON message aren't in fact available. we essentially have to serialize a message to put into the
msg
field, versus being able to take the KV pairs from the message and flatten them out onto the JSON object