nginx access_log 中记录“请求的处理节点 id”指当前实例唯一标识(如$hostname或自定义$nginx_node_id),用于多节点部署中定位处理机器;需区分于动态请求id $request_id,二者应同时记录以实现“节点×请求”二维日志索引。

在 Nginx 的 access_log 中记录“请求的处理节点 ID”,本质是记录当前 Nginx 实例的唯一标识(如主机名、实例编号或集群角色),而非请求本身生成的链路 ID(如 $request_id)。它用于区分日志来源,方便在多节点部署中定位具体哪台机器处理了该请求。
用 $hostname 记录本机主机名
最常用、零配置的方式是直接使用内置变量 $hostname,它返回 Nginx 所在系统的 hostname:
- 在
http块中定义日志格式时加入:log_format node_log '$hostname $remote_addr - [$time_local] "$request" $status $body_bytes_sent "$http_user_agent"'; - 在
server或location中启用:access_log /var/log/nginx/access.log node_log; - 优点:无需额外配置,系统级唯一(前提是各节点 hostname 不同);缺点:若集群中 hostname 未规范设置(如全为 localhost),则失去区分意义。
用自定义变量固定节点 ID
当 hostname 不可控或需业务语义化标识(如 api-gw-01、edge-prod-a)时,推荐用 env + set 方式注入:
使用tbot机器ID身份文件配合tsh CLI,通过Teleport访问控制SSH登录托管主机或执行远程命令。
- 在 Nginx 启动前,通过环境变量设定:
export NGINX_NODE_ID="gw-east-03" - 在
nginx.conf的http块顶部声明该变量(需开启env指令支持):env NGINX_NODE_ID; - 定义日志格式:
log_format with_node '$NGINX_NODE_ID $request_id $remote_addr "$request" $status $request_time'; - 注意:
env指令必须出现在http块最外层,且 Nginx 需以 systemd 或 shell 脚本方式启动(确保环境变量生效)。
记录上游服务节点(反向代理场景)
如果 Nginx 作为网关,还需知道最终处理请求的后端节点(如 Pod IP、实例名),可结合 $upstream_addr:
-
$upstream_addr记录实际通信的上游地址(含端口),例如10.244.1.12:8080或backend-svc.default.svc.cluster.local:80 - 添加到日志格式:
log_format upstream_log '$hostname $request_id "$request" $upstream_addr $upstream_response_time $status'; - 适用于排查负载不均、后端异常定位,但注意该字段在失败回退或多个 upstream 时可能为多个地址(用逗号分隔)。
避免混淆:节点 ID ≠ 请求 ID
务必区分两个概念:
-
节点 ID(如
$hostname、$NGINX_NODE_ID):标识“谁处理了请求”,静态、机器级 -
请求 ID(
$request_id):标识“哪个请求”,动态、每次请求唯一,用于链路追踪 - 两者应同时记录,形成「节点 × 请求」二维索引,便于在日志平台中既按节点筛选,又按 request_id 聚合全链路。










