端到端分析需分段定位：先查网络链路（dns、tcp、tls、中间设备），再验服务进程（线程cpu、系统调用、锁状态、资源配置），接着排查依赖组件（db、redis、下游http），最后检查系统底层（中断、i/o、内存、oom）。
Linux服务响应慢，不能只盯着应用日志或CPU使用率看。得从客户端发起请求开始，一路追踪到后端服务处理完成，中间每个环节都可能成为瓶颈。端到端分析的关键是分段定位、交叉验证、避免盲猜。
网络链路：先确认请求是否顺利抵达服务端
很多“服务慢”其实是网络层卡住——连接建立慢、丢包、DNS解析延迟、防火墙策略限制等，根本没走到应用逻辑。
- 用 curl -v 或 wget --debug 查看 DNS 解析、TCP 连接、TLS 握手各阶段耗时
- 执行 tcpdump -i any port -w trace.pcap 抓包，重点观察 SYN/SYN-ACK 延迟、重传、窗口缩放异常
- 对比 telnet
和 curl http:// 的耗时差异，快速判断是 DNS 还是网络连通性问题 - 检查中间设备（如负载均衡器、iptables、nftables）是否有连接限速、连接数限制或 conntrack 表满
服务进程：确认请求是否被及时调度和处理
即使网络通畅，服务进程也可能因资源争用、锁竞争或配置不当而响应滞后。
- 用 pidstat -u -t -p
1 观察线程级 CPU 占用，识别高消耗线程（如 GC、正则回溯、同步 I/O） - 执行 strace -p
-e trace=accept,read,write,sendto,recvfrom -T 跟踪系统调用耗时，发现阻塞点（如 read 等待 socket 数据、write 被 TCP 窗口阻塞） - 检查 /proc/
/stack 和 pstack，看线程是否卡在 futex、epoll_wait、pthread_cond_wait 等同步原语上 - 确认服务最大连接数（如 Nginx 的 worker_connections）、文件描述符限制（ulimit -n）、JVM 堆/线程池配置是否合理
依赖组件：别让数据库、缓存或下游 API 拖垮主服务
服务本身轻快，但每次请求都要等 MySQL 查询 800ms、Redis 超时重试、HTTP 下游返回 5s，端到端自然变慢。
- 开启应用层全链路日志或指标（如 OpenTelemetry），按 trace_id 关联上下游耗时，明确慢在哪一跳
- 对 DB 执行 SHOW PROCESSLIST + EXPLAIN，查慢查询、锁等待（State = "Waiting for table metadata lock"）、连接池打满
- 用 redis-cli --latency -h
测 Redis 实例延迟；redis-cli monitor 观察命令堆积或大 key 扫描 - 检查下游 HTTP 接口的 TLS 握手时间、Keep-Alive 复用率、是否启用 HTTP/2 流控，避免连接反复重建
系统底层：内核与硬件状态常被忽略却影响深远
CPU 负载不高，但服务仍卡顿？可能是中断风暴、内存回收压力、磁盘 I/O 阻塞或 NUMA 不均衡导致。
- 运行 vmstat 1 关注 si/so（swap 交换）、bi/bo（块 I/O）、wa（I/O 等待）持续偏高
- 用 cat /proc/interrupts 查看软中断分布，结合 top -H 看 ksoftirqd 线程 CPU 是否飙升（常见于网卡收包过载）
- 执行 iostat -x 1 观察 %util、await、r_await/w_await、svctm，区分是磁盘性能瓶颈还是队列深度过大
- 检查 dmesg -T | grep -i "oom\|kill\|throttle"，确认是否触发 OOM Killer、cgroup 内存压制或 CPU throttling
端到端不是堆砌工具，而是带着假设去验证：请求发出去了吗？服务收到了吗？它在做什么？依赖返回快吗？系统撑得住吗？每一步都有可观测依据，才能把“好像慢”变成“确定慢在哪”。
