NGINX Unit

故障排除§

日志记录§

Unit 维护一个通用的 日志，用于诊断和故障排除（不要与 访问日志 混淆）。若要找出其在安装中的默认位置

$ unitd -h

    unit options:
    ...
    --log FILE           set log filename
                         default: "/path/to/unit.log"

--log 选项会覆盖默认值；如果 Unit 已在运行，请检查是否设置了此选项

$ ps ax | grep unitd
    ...
    unit: main v1.32.1 [/path/to/unitd ... --log /path/to/unit.log ...]

如果 Unit 未运行，请查看其系统启动脚本或配置文件，检查是否设置了 --log，以及如何设置。

可用的日志级别

  • [alert]：非致命错误，例如应用程序异常或配置错误。

  • [error]：严重错误，例如无效端口或地址。

  • [warn]：可恢复的问题，例如 umount2(2) 失败。

  • [notice]：自诊断和路由器事件。

  • [info]：通用报告。

  • [debug]：调试事件。

注意

请注意，我们的 Docker 镜像会将它们的日志输出转发到 Docker 日志收集器，而不是文件。

路由器事件§

Unit 的 设置 中的 log_route 选项允许在通用日志中记录 路由选择

事件

日志级别

说明

HTTP 请求行

[notice]

传入 请求行。

URI 已重写

[notice]

请求 URI 已更新。

已选择路由步骤

[notice]

已选择路由步骤来处理请求。

已执行回退

[notice]

在选择步骤后执行了回退操作。

示例路由器日志输出可能如下所示

[notice] 8308#8339 *16 http request line "GET / HTTP/1.1"
[info] 8308#8339 *16 "routes/0" discarded
[info] 8308#8339 *16 "routes/1" discarded
[notice] 8308#8339 *16 "routes/2" selected
[notice] 8308#8339 *16 URI rewritten to "/backend/"
[notice] 8308#8339 *16 "fallback" taken

它列出了可以通过 控制 API 查询的具体步骤和操作（例如 routes/2）以获取详细信息

# curl --unix-socket /path/to/control.unit.sock https://127.0.0.1/config/routes/2

调试事件§

可以将 Unit 的日志设置为记录[debug] 级别的事件；启用此模式的步骤因安装方法而异。

警告

调试日志面向开发者；它增长迅速，因此仅在需要详细报告和检查时才启用它。

我们的 存储库 提供了unit 包中的名为 unitd-debug 的 unitd 的调试版本

# unitd-debug <command line options>

在使用我们的 Docker 镜像 时启用调试级别日志记录

$ docker run -d unit:1.32.1-minimal unitd-debug --no-daemon  \
      --control unix:/var/run/control.unit.sock

另一个选项是在 Dockerfile 中添加新层

FROM unit:1.32.1-minimal

CMD ["unitd-debug","--no-daemon","--control","unix:/var/run/control.unit.sock"]

上面的 CMD 指令用其调试版本替换了默认的 unitd 可执行文件。

要在 从源代码安装 时启用调试级别日志记录，请使用 --debug 选项

$ ./configure --debug <other options>

然后重新编译并重新安装 Unit 和您选择的 语言模块。

核心转储§

核心转储有助于我们调查崩溃；在报告问题时附加它们。对于来自我们的存储库的构建，我们在特殊包中维护调试符号；它们具有原始包的名称，并附加了-dbg后缀，例如unit-dbg。

注意

本部分假定您以root身份运行 Unit（推荐）。

要在以systemd服务（例如，使用打包安装）运行 Unit 时启用保存核心转储，请调整/lib/systemd/system/unit.service中的服务设置

[Service]
...
LimitCORE=infinity
LimitNOFILE=65535

或者，更新/etc/systemd/system.conf中的全局设置

[Manager]
...
DefaultLimitCORE=infinity
DefaultLimitNOFILE=65535

接下来，重新加载服务配置并重新启动 Unit 以重现崩溃条件

# systemctl daemon-reload
# systemctl restart unit.service

崩溃后，找到核心转储文件

# coredumpctl -1                     # optional

      TIME                            PID   UID   GID SIG COREFILE  EXE
      Mon 2020-07-27 11:05:40 GMT    1157     0     0  11 present   /usr/sbin/unitd

# ls -al /var/lib/systemd/coredump/  # default, see also /etc/systemd/coredump.conf and /etc/systemd/coredump.conf.d/*.conf

      ...
      -rw-r----- 1 root root 177662 Jul 27 11:05 core.unitd.0.6135489c850b4fb4a74795ebbc1e382a.1157.1590577472000000.lz4

检查/etc/security/limits.conf中的核心转储设置，必要时进行调整

root           soft    core       0          # disables core dumps by default
root           hard    core       unlimited  # enables raising the size limit

接下来，使用ulimit提高核心转储大小限制，然后重新启动 Unit 以重现崩溃条件

# ulimit -c unlimited
# cd /path/to/unit/
# sbin/unitd           # or sbin/unitd-debug

崩溃后，找到核心转储文件

# ls -al /path/to/unit/working/directory/  # default location, see /proc/sys/kernel/core_pattern

      ...
      -rw-r----- 1 root root 177662 Jul 27 11:05 core.1157

检查/etc/sysctl.conf中的核心转储设置，必要时进行调整

kern.coredump=1
# must be set to 1
kern.corefile=/path/to/core/files/%N.core
# must provide a valid pathname

或者，在运行时更新设置

# sysctl kern.coredump=1
# sysctl kern.corefile=/path/to/core/files/%N.core

接下来，重新启动 Unit 以重现崩溃条件。如果 Unit 已安装为服务

# service unitd restart

如果它是手动安装的

# cd /path/to/unit/
# sbin/unitd

崩溃后，找到核心转储文件

# ls -al /path/to/core/files/

      ...
      -rw-------  1 root     root  9912320 Jul 27 11:05 unitd.core

获取支持§

支持渠道

详细信息

GitHub

访问我们的 repo 提交问题、建议功能、提问或查看路线图。

邮件列表

要向 unit@nginx.org 发帖提问并获取通知（包括发行新闻），请发送电子邮件至 unit-subscribe@nginx.org 或 在此处 注册。要接收 NGINX 的所有 OSS 发行公告，请 在此处 加入一般邮件列表。

安全警报

请将安全问题报告给 security-alert@nginx.org，特别在主题中提及 NGINX Unit 并遵循 CVSS v3.1 规范。

此外，我们提供 商业支持。

编辑此页面