[uWSGI] Default Log Format Explained?

Roberto De Ioris roberto at unbit.it
Fri Mar 27 10:10:20 CET 2015


> Hello,
>
> could somebody tell me whether the default log format is explained
> somewhere? I.e. the exact meanings of the numbers and other data in
> lines such as:
>
>     [pid: 596|app: 0|req: 24/72] 222.127.73.32 () {50 vars in 1043
> bytes} [Wed Jan 14 11:44:29 2015] POST /countries/ => generated 2 bytes
> in 149 msecs (HTTP/1.1 200) 3 headers in 112 bytes (1 switches on core 0)
>
> I can make some educated guesses, of course, but would rather not have to.
>
> I have read the section in the documentation [1], which lists the
> available options, and found the mail in the archive announcing the
> log-format option [2] (cheers for that :) ). In the Git repository I
> found the code where the log line is assembled [3], but since it does
> not simply use the documented variables, it's not directly documenting
> itself. Before I start digging in the code, did I miss the docs?
>
> If not, I'd try to come up with a patch for the documentation. Does that
> make sense?
>
> Cheers,
> murat
>

Every kind of doc improvements is wellcomed (no-one want to write docs,
and everyone always rant about docs, so it is a catch 22 world ;)

Btw:

pid -> the pid of the worker managing the request
app -> the id (it is a integer, starting from 0) of the app, it makes
sense when multiple apps are hosted in the same instance. It is -1 when no
app managed the request (like when serving static files) or when the 'app'
concept does not apply (like with php or cgi's)
req: N/M -> N is the number of managed requests by the current worker for
the specific app, M is the grand total (sum of all requests of all
workers)

then you have REMOTE_ADDR followd by the (optional) REMOTE_USER (very
similar to apache)

vars are the number of CGI vars in the request, and their size (from the
uwsgi protocol point of view). The size is never higher than the
--buffer-size (higher requests are discarded)

The time of the request follows

Then you have REQUEST_METHOD + REQUEST_URI

Then the response size and the time required for generating it

"via" is the techology used to send the response, currently can be
sendfile, routing or offloading.

The response status follows, as well as the number of response headers.

"core" is the low-level concept for uWSGI concurrency context in a process
(can be a thread or a greenlet or a fiber or a goroutine and so on...)
while switches count is incremented whenever an app "yield" its status
(this has various meanings based on the lower concurrency model used)

-- 
Roberto De Ioris
http://unbit.com


More information about the uWSGI mailing list