需结合Nginx日志与系统级监控数据：启用stub_status获取连接状态，定时采集vmstat/ss指标并统一时间戳，增强access.log含$request_time等字段，再通过GoAccess、ELK或Telegraf+InfluxDB+Grafana融合分析。
记录系统资源使用情况并生成可用于性能分析的日志，不能只靠 Nginx 自身日志——它不直接记录 CPU、内存、磁盘 IO 或网络连接数。你需要把 Nginx 日志和系统级监控数据关联起来，形成“请求行为 + 资源负载”的完整视图。
启用 Nginx 自带的实时状态监控
Nginx 的 stub_status 模块提供轻量、低开销的运行时指标，是性能日志的第一层基础：
- 在 nginx.conf 的 server 块中添加：
location /nginx_status {<br> stub_status on;<br> access_log off;<br> allow 127.0.0.1;<br> deny all;<br>} - 访问
curl http://localhost/nginx_status可得三行输出，例如：Active connections: 124<br>server accepts handled requests<br>15689 15689 48234<br>Reading: 0 Writing: 3 Waiting: 121
- 用定时脚本（如每10秒）抓取该接口，并打上时间戳写入独立日志文件，后续可导入 Prometheus 或做趋势分析。
采集系统资源指标并打标对齐时间
Nginx 请求日志（access.log）有精确到秒的 $time_local，系统指标需按相同时间粒度采集，才能做归因分析：
- 推荐用 vmstat 或 pidstat 定时采样（避免高频采样拖慢系统）：
*/30 * * * * vmstat 1 3 | tail -n1 | awk '{print strftime("%Y-%m-%d %H:%M:%S"), $13, $14, $15}' >> /var/log/nginx/system-metrics.log
（记录时间、%us 用户态 CPU、%sy 内核态 CPU、%id 空闲） - 用 ss 统计并发连接状态：
ss -s | grep "TCP:" | awk '{print strftime("%Y-%m-%d %H:%M:%S"), $2}' >> /var/log/nginx/tcp-conn.log - 关键：所有采集命令都加
strftime或date +'%Y-%m-%d %H:%M:%S'，确保时间格式与 Nginx 日志一致（如[30/Sep/2026:22:38:15 +0000]），方便后期按分钟级聚合对齐。
增强 Nginx 日志字段以支持资源关联
默认 access.log 缺少请求耗时上下文，补充关键字段能让日志本身携带性能线索：
- 在 http 块定义更丰富的日志格式：
log_format perf '$time_local $remote_addr "$request" $status $body_bytes_sent '<br>'"$http_referer" "$http_user_agent" '<br>'$request_time $upstream_response_time $pipe $connection';
- 其中：
$request_time：整个请求处理耗时（秒，精度毫秒）
$upstream_response_time：后端响应耗时（反向代理场景）
$connection：当前连接序号（可辅助识别长连接复用） - 重启后，每条日志自带服务端处理延迟，结合系统 CPU 高峰时段，能快速定位是 Nginx 自身瓶颈还是后端或系统资源问题。
用 GoAccess 或 ELK 做日志+指标融合分析
原始日志和系统指标分开存储难以联动，需工具层整合：
-
GoAccess：支持自定义日志格式解析，可将
$request_time映射为“响应时间分布”，再叠加系统监控图表（需外部脚本合并 CSV）； -
ELK Stack：Logstash 同时读取 access.log 和 system-metrics.log，用 Logstash 的
date过滤器统一时间字段，再用 Kibana 做双 Y 轴图表（左轴：QPS，右轴：CPU%），直观看到“每万请求对应多少 CPU 使用率”； - 进阶做法：用 Telegraf 采集系统指标 + Nginx VTS 模块暴露的 metrics，全部推送到 InfluxDB，Grafana 统一看板，实现真正的全栈性能可观测性。
