Chapter 8[ 201 ]After the request has been processed, it can then be logged:
0000000000000000 0
0000000000000000 0
The client has closed the connection, so NGINX will as well:
handler
connection: 3
As you can see, there is quite a bit of information included here. If you have trouble
figuring out why a particular configuration isn't working, going through the output
of the debug log can be helpful. You can immediately see in what order the various
filters run, as well as what handlers are involved in serving the request.
Using access logs for debugging
When I was learning how to program, and couldn't find the source of a problem,
a friend of mine told me to "put printf's everywhere". That was how he was most
quickly able to find the source of a problem. What he meant by this was to place a
statement that would print a message at each code branch point, so that we could
see which code path was getting executed and where the logic was breaking down.
By doing this, we could visualize what was going on and could more easily see
where the problem lies.
This same principle can be applied to configuring NGINX. Instead of printf() we
can use the log_format and access_log directives to visualize request flow and
analyze what's going on during request processing. Use the log_format directive
to see the values of variables at different points in the configuration:
http {log_format sentlog '[$time_local] "$request" $status $body_bytes_
sent ';