nginx 的 Error_log 可用于追踪核心模块运行时的问题。1. 配置 error_log 时，需在 nginx.conf 的 http、server 或 location 块中指定路径和日志级别，如 error_log /var/log/nginx/error.log warn; 2. 日志内容包含时间戳、级别、进程 id、错误描述等信息，有助于定位问题，例如 “upstream timed out” 表示上游服务器超时；3. 常见异常包括段错误（需用 gdb 分析 core dump）、内存耗尽（检查配置如 client_max_body_size）、配置错误（使用 nginx -t 检查）、连接失败（用 ping 或 telnet 测试）；4. debug 级别日志提供更详细信息，但影响性能，建议排查时临时启用；5. 区分核心与第三方模块错误可通过日志中的模块名判断，如 ngx_http_core_module 是核心模块，若为第三方模块可尝试禁用或升级以解决问题。
通过 error_log，你可以追踪 Nginx 核心模块在运行时遇到的问题。关键在于理解 error_log 的配置、日志级别，以及如何解读日志信息，从而找到问题的根源。
error_log 文件路径和日志级别是关键。先确保 nginx.conf 中 error_log 指令正确配置，然后分析日志内容。
如何配置 Nginx 的 error_log？
在 nginx.conf 文件中，通常在 http、server 或 location 块中配置 error_log。例如：
error_log /var/log/nginx/error.log warn;
这行配置指定了错误日志的路径是 /var/log/nginx/error.log，日志级别是 warn。 warn 级别会记录警告、错误和紧急事件。其他常用的级别包括 debug、info、notice、error、crit、alert 和 emerg。 debug 级别最为详细，但通常不建议在生产环境中使用，因为它会产生大量的日志。
修改配置后，别忘了 nginx -s reload 重载配置。
如何解读 Nginx error_log 中的信息？
Nginx 的 error_log 包含时间戳、日志级别、进程 ID、线程 ID（如果启用）、错误描述和相关的上下文信息。例如：
2023/10/27 10:00:00 [error] 12345#67890: *1 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 192.168.1.1, server: example.com, request: "GET / HTTP/1.1", upstream: "http://127.0.0.1:8080/", host: "example.com"
这条日志表明，在尝试从上游服务器读取响应头时发生了超时。 12345#67890 是进程和线程 ID，*1 是连接 ID，client 是客户端 IP 地址，server 是服务器名称，request 是客户端请求，upstream 是上游服务器地址。
仔细阅读错误描述，可以帮助你确定问题的类型和位置。例如，”upstream timed out” 通常意味着上游服务器响应缓慢或不可用。
常见 Nginx 核心模块异常及定位方法
Nginx 核心模块的异常可能涉及内存管理、连接处理、配置解析等方面。 以下是一些常见的异常和定位方法：
-
Segmentation fault (segfault): 这通常表明 Nginx 尝试访问无效的内存地址。 可能是由于 Nginx 本身的 Bug，也可能是由于第三方模块引起的。 在这种情况下，需要使用 GDB 等调试工具来分析 core dump 文件，找出导致 segfault 的代码。
gdb /usr/sbin/nginx core
-
Out of memory: Nginx 消耗了过多的内存，导致系统无法分配新的内存。 可以使用 top 或 htop 命令监控 Nginx 的内存使用情况。 如果发现 Nginx 进程占用了大量的内存，需要检查 Nginx 的配置，看看是否有内存泄漏或者配置不当的情况。例如，client_max_body_size 设置过大可能会导致 Nginx 缓存大量的客户端请求体，从而消耗大量的内存。
-
Configuration error: Nginx 无法解析配置文件，导致启动失败。 可以使用 nginx -t 命令测试配置文件的语法是否正确。
nginx -t
这个命令会检查 nginx.conf 文件以及所有包含的文件，并报告任何语法错误。
-
Connection refused/connection reset by peer: Nginx 无法连接到上游服务器，或者连接被上游服务器重置。 检查上游服务器是否正在运行，以及网络连接是否正常。 可以使用 ping 或 telnet 命令测试与上游服务器的连通性。
ping upstream.example.com telnet upstream.example.com 80
如果无法连接到上游服务器，需要检查防火墙规则和网络配置。
如何使用 debug 级别日志进行更深入的排查？
将 error_log 级别设置为 debug 可以记录更详细的日志信息，有助于更深入地排查问题。 但是，debug 级别会产生大量的日志，可能会影响 Nginx 的性能，所以不建议在生产环境中使用。
启用 debug 级别后，可以根据错误描述中的信息，找到相关的代码，并使用 GDB 等调试工具进行单步调试，从而找出问题的根源。 例如，如果错误描述中包含文件名和行号，可以直接在 GDB 中打开该文件，并设置断点，然后重新运行 Nginx，当程序执行到断点时，就可以查看变量的值，从而分析程序的执行流程。
如何区分 Nginx 核心模块和第三方模块的错误？
error_log 中的日志信息通常会包含模块的名称。例如，ngx_http_core_module 是 Nginx 核心模块，而 ngx_http_ssl_module 是 SSL 模块。 如果错误信息中包含第三方模块的名称，可以确定是第三方模块引起的错误。
如果是第三方模块引起的错误，可以尝试禁用该模块，看看是否能够解决问题。 如果禁用该模块后问题解决了，可以确定是该模块的 Bug。 在这种情况下，可以向该模块的开发者报告 Bug，或者尝试升级到最新版本。
