跨服务问题需分层排查：先验证调用链路与依赖拓扑，再统一时间基准和日志 trace_id，接着检查资源级瓶颈（文件描述符、端口、内核参数），最后用 strace/ltrace 定位卡点。
跨服务问题在 Linux 环境中很常见，比如 Web 服务返回 502，但 Nginx 日志只显示“upstream refused”，真正出问题的可能是后端的 Python 应用、数据库连接池耗尽，或是 Redis 响应超时。这类问题不能只盯一个进程，得从请求链路出发，分层验证依赖关系。
看清楚请求路径与依赖拓扑
先确认服务间真实的调用关系，别靠文档或记忆——它们常过时。用 ss -tlnp 或 lsof -i :端口 查哪个进程在监听；用 curl -v http://localhost:端口/health 逐个测试上游服务的健康接口；对微服务场景，可临时在关键跳点加 tcpdump -i lo port 服务端口 -w trace.pcap 抓包，再用 Wireshark 过滤 HTTP/HTTP2 流，确认请求是否发出、响应是否返回、有没有 RST 包。
统一时间基准与日志上下文
不同服务日志时间不一致，会误判因果。用 timedatectl status 检查各节点是否启用 NTP 同步；在关键请求入口（如 Nginx 的 log_format）加入唯一 trace_id，例如：
log_format main '$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent" "$http_x_request_id"';
后端服务也需透传并记录该 ID。这样就能用 grep "trace-abc123" /var/log/nginx/access.log /var/log/app/*.log 聚合整条链路日志。
检查资源级依赖而非仅进程状态
服务进程 running ≠ 服务可用。重点排查三类隐性瓶颈：
- 文件描述符：用 cat /proc/$(pgrep -f "gunicorn|uwsgi")/limits | grep "Max open files" 查上限，再用 lsof -p PID | wc -l 看实际使用量
- 本地端口耗尽：运行 netstat -an | grep TIME_WAIT | wc -l，若远超 3000，可能因短连接频繁导致后端无法建连
- 内核参数限制：检查 sysctl net.ipv4.ip_local_port_range 和 net.core.somaxconn 是否合理，尤其高并发场景
用 strace + ltrace 快速定位卡点
当某服务响应慢但无错误日志，直接 attach 到可疑进程：
- strace -p $(pgrep -f "redis-cli") -e trace=connect,sendto,recvfrom -s 200 -T —— 看是否卡在 connect 超时或 recvfrom 阻塞
- ltrace -p $(pgrep -f "node") -e "mysql_*|redis*" —— 观察数据库/缓存客户端库调用是否长时间未返回
- 注意：生产环境慎用全系统 strace，优先限定系统调用类型，避免性能抖动
