Access logs lack sufficient detail for troubleshooting.But running a production system is seldom that simple.
In general terms, we want to use the access log to provide analytics and usage statistics, and use the error log for failure detection and troubleshooting. For example, two access_log directives might be used to create both a standard CLF log file and a second, more detailed log. Multiple logging directives may exist in the same context.A logging directive in a child context overrides inherited directives.(There is also a third logging mechanism which uses the debug severity level, but we won’t discuss it here.)Ī typical, default NGINX logging configuration looks like this. These mechanisms are available in both the HTTP and Stream (TCP/UDP) modules, but here we focus on HTTP traffic. NGINX provides two different logging mechanisms: access logging for client requests, and error logging for when things go wrong. More specifically, we discuss the balancing act of collecting the right amount of detailed logs for troubleshooting without being swamped with unnecessary data. In this article we talk about just one of the hard things about a production deployment – logging.
Regardless of your scale and choice of deployment infrastructure, running in production is not easy. NGINX helps organizations of all sizes to run their mission‑critical websites, applications, and APIs. For the complete list, see Use Cases for the NGINX JavaScript Module. It’s also one of many blogs about use cases for the NGINX JavaScript module.
NGINX LOGTAIL PLUS
Application Tracing with NGINX and NGINX Plus.Troubleshooting in Production Without Tuning the Error LogĮditor – This blog is one of several that discuss logging with NGINX and NGINX Plus.
0 kommentar(er)
