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 方式注入：

Teleport tsh SSH (Identity-First SSH Access, no passwords/static keys)

使用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 聚合全链路。