外观
3.2 日志定位方法
约 450 字
排查日志
本页对应「三、操作步骤」的 3.2,完成日志定位方法。返回上级:故障排查操作手册。
前置条件
- 3.1 已完成,故障层已定位到 Nginx、应用或数据库之一。
- 可读
/var/log/nginx、/srv/axis/logs与 journald 日志。 - 已知故障时间窗口与最近一次发布版本。
操作步骤
- 按服务定位日志文件,先看最近窗口。
sudo ls -l /var/log/nginx/
sudo journalctl -u axis-api --since '-1 hour' --no-pager | tail -n 50
sudo tail -n 50 /srv/axis/logs/app.log- 按状态码与时间窗口过滤访问日志。
sudo awk '$9 ~ /^5/ {print}' /var/log/nginx/example.access.log | tail -n 20
sudo grep '08/Jun/2026:09:1' /var/log/nginx/example.access.log | head -n 20- 用错误日志定位上游与配置问题。
sudo tail -n 100 /var/log/nginx/example.error.log
sudo grep -n 'worker_connections' /etc/nginx/nginx.conf- 关联数据库与系统层日志。
sudo tail -n 50 /var/log/mysql/error.log
sudo dmesg -T | grep -i -E 'oom|killed process' | tail -n 10- 把关键片段落到事件记录中,便于交接。
sudo grep -m 5 'request_id' /srv/axis/logs/app.log | sudo tee -a /srv/axis/logs/incident.log结果确认
- 找到第一条 ERROR 及其精确时间,与告警时间相差不超过 1 分钟。
- 5xx 请求可定位到具体 URI 与上游地址、端口。
- 系统日志中无 OOM 或磁盘错误,或已确认其就是根因。
- 事件记录中包含时间、URI、错误摘要与责任人。
注意事项
- 日志量大时先用
--since、tail、head限制范围,避免终端被大量输出拖住。 - 应用日志可能包含用户数据,导出与转发前必须脱敏。
- 日志轮转后旧文件被压缩为 .gz,排查历史问题需用 zgrep 而非常规 grep。
- 不要把整份日志直接贴到公开渠道,摘录关键行即可。