When you start uwsgi, it prints all sorts of useful information:
Mon Jan 16 19:09:26 2017 - *** Starting uWSGI 2.0.14 (64bit) on [Mon Jan 16 19:09:26 2017] ***
Mon Jan 16 19:09:26 2017 - compiled with version: 4.8.4 on 21 December 2016 16:48:12
Mon Jan 16 19:09:26 2017 - os: Linux-3.13.0-106-generic #153-Ubuntu SMP Tue Dec 6 15:44:32 UTC 2016
...
Mon Jan 16 19:09:27 2017 - spawned uWSGI worker 1 (pid: 31170, cores: 1)
Mon Jan 16 19:09:27 2017 - spawned uWSGI http 1 (pid: 31171)
...and so on. While it's easy to add date (via --logdate), these messages are missing log level.
The problem is that if there's such an error in my application that propagates all the way to uwsgi, it is logged in there:
Mon Jan 16 19:14:06 2017 - spawned uWSGI worker 1 (pid: 31793, cores: 1)
Mon Jan 16 19:14:06 2017 - spawned uWSGI http 1 (pid: 31794)
Traceback (most recent call last):
...<SNIP>...
RuntimeError: Working outside of request context.
...
As can be seen, this line doesn't even get a timestamp. That is actually a bit weird, I wonder why that is and how can I prevent that?
It would be nice to have log levels visible, so one could filter out just errors (and maybe set alarms of them).
As a comparison, in gunicorn, this seems to work nicely out of box:
[2017-01-16 19:02:46 +0200] [30309] [INFO] Starting gunicorn 19.6.0
[2017-01-16 19:02:46 +0200] [30309] [INFO] Listening at: http://127.0.0.1:8000 (30309)
[2017-01-16 19:02:46 +0200] [30309] [INFO] Using worker: sync
[2017-01-16 19:02:46 +0200] [30312] [INFO] Booting worker with pid: 30312
[2017-01-16 19:02:51 +0200] [30312] [ERROR] Error handling request /client-api/v3/nodes/1/settings
Traceback (most recent call last):
...
RuntimeError: Working outside of request context.
This typically means that you attempted to use functionality that needed
an active HTTP request. Consult the documentation on testing for
information about how to avoid this problem.
...
Would love to have something similar.
Log levels are specific to the python logging module, i don't think we have any structured way of handling logs in uwsgi by default, it looks like everything goes to the same pipe in uwsgi_log.