分布式系统日志排查综合场景

排查背景

在一个大型分布式电商系统中，用户反馈在进行商品结算时出现了报错。系统由多个子系统构成，包括商品管理系统、订单系统、支付系统等，各子系统分布在不同服务器上，且日志文件分散存储。

排查过程

确定当前位置并切换到可能的日志目录

•  首先使用pwd命令查看当前所在目录，确认初始位置；

pwd

• 然后通过和开发团队沟通得知订单系统日志一般存放在/var/log/order_system目录下，使用cd命令切换过去

cd /var/log/order_system

• 使用ls命令查看该目录下的文件列表，确认日志文件的命名规则，发现有order_20250219.log、order_error.log等文件。

ls

查找包含报错关键字的日志​​​​​

•  用户反馈结算报错时提到了 “payment_failure” 关键字，使用grep结合cat命令在所有日志文件中递归查找该关键字。

cat * | grep -r "payment_failure"

• 结果发现order_error.log文件中有相关记录，为进一步查看该文件上下文，使用cat和grep的组合，查看关键字前后 5 行内容。

cat order_error.log | grep "payment_failure" -C 5

动态实时查看日志

• 为了捕捉新的报错信息，使用tail -f命令动态实时查看order_error.log文件。

tail -f order_error.log

• 在等待过程中，又有新的用户反馈相同问题，实时日志中出现了更多相关报错记录。运维人员发现报错时间集中在 15:00 - 15:30 之间。

根据时间范围筛选日志

• 使用sed命令，根据时间范围筛选出 15:00 - 15:30 之间的日志记录。

sed -n '/2025-02-19 15:00/,/2025-02-19 15:30/p' order_error.log

• 从筛选结果中发现报错信息指向了支付系统的一个接口调用失败。

检查相关进程状态

• 怀疑是订单系统调用支付系统接口的进程出现问题，使用ps -ef命令查看当前所有进程，通过管道符|结合grep命令筛选出与订单系统接口调用相关的进程。假设相关进程名为order_payment_interface。

ps -ef | grep order_payment_interface

• 发现该进程的 CPU 和内存占用率异常高，可能是导致接口调用失败的原因之一。

进一步排查与解决

• 运维人员根据上述排查结果，联系支付系统团队和开发人员，告知他们订单系统调用支付系统接口时在特定时间出现报错，且相关进程资源占用异常。开发人员根据日志信息和进程状态，进一步深入代码层面排查问题，最终发现是支付系统接口的一个参数校验逻辑在高并发情况下出现了错误，导致订单系统调用失败。修复该问题后，经过测试，用户结算功能恢复正常。

开始（用户反馈支付失败）
│
▼
[阶段1：定位订单系统日志]
│
├─ 命令: pwd: 确认当前所在目录路径，避免误操作其他目录
│
├─ 命令: cd /var/log/order_system 切换到订单系统日志目录，开发团队提供的标准日志存储位置
│
├─ 命令: ls -l *.log 列出目录下所有.log文件，确认日志命名规则（如order_error.log）
│
▼
[阶段2：分析订单系统错误日志]
│
├─ 命令: grep -r "payment_failure" /var/log/order_system 递归搜索订单系统目录下的“payment_failure”关键字，定位具体日志文件
│
├─ 命令: cat /var/log/order_system/order_error.log | grep -C 5 "payment_failure" 查看order_error.log中匹配行的前后5行，分析错误上下文（如订单ID、请求参数）
│
▼
[阶段3：实时监控订单系统日志]
│
├─ 命令: tail -f /var/log/order_system/order_error.log 实时追踪日志尾部更新，观察新产生的支付失败记录
│
▼
[阶段4：按时间筛选关键日志]
│
├─ 命令: sed -n '/2025-02-19 15:00:00/,/2025-02-19 15:30:00/p' order_error.log > time_filtered.log 提取15:00-15:30的日志到新文件，聚焦高并发时段的异常记录
│
▼
[阶段5：检查订单系统进程状态]
│
├─ 命令: ps -ef | grep order_payment_interface 筛选订单系统中调用支付接口的进程，检查PID、CPU和内存占用率
│
▼
[阶段6：关联支付系统问题]
│
├─ 结论: 日志显示支付接口返回“参数校验失败”，进程资源占用异常（如CPU 90%+） 将日志和进程状态提交支付系统团队（示例：内部工单或邮件）
│
▼
[阶段7：支付系统修复]
│
├─ 操作: 支付系统团队修复参数校验逻辑，重启服务
│   └─ 命令: curl -X POST http://payment-system/api/healthcheck 调用支付系统健康检查接口，验证服务恢复
│
▼
结束（用户支付流程验证成功）