从一次线上服务调用失败说起用curl、telnet和ping层层递进定位问题那天凌晨2点15分企业级电商平台的支付网关突然告警。作为值班SRE我打开监控系统看到满屏红色核心微服务API的失败率在15分钟内从0.3%飙升到89%。这不是普通的服务抖动而是一场需要立即止血的生产事故。本文将还原这次故障排查的全过程展示如何像外科手术般精准使用基础网络工具定位问题。1. 第一层诊断网络基础连通性检查当服务不可用时90%的初级工程师会直接登录服务器查日志——这是个典型误区。正确的第一步应该是确认最底层的网络连通性就像医生先检查病人的生命体征。1.1 ping网络层的听诊器我首先对故障服务集群的3个节点执行ping测试ping 10.8.2.15 ping 10.8.2.16 ping 10.8.2.17得到的关键结果64 bytes from 10.8.2.15: icmp_seq1 ttl64 time0.342 ms 64 bytes from 10.8.2.16: icmp_seq1 ttl64 time112.783 ms Request timeout for icmp_seq 1 (10.8.2.17)这个输出立刻揭示了几个重要事实10.8.2.15节点网络正常10.8.2.16存在明显网络延迟10.8.2.17完全不可达注意现代云环境常默认禁用ICMP协议此时需要结合TCP层工具验证1.2 进阶ping技巧对于生产环境我通常会使用这些增强型参数ping -c 5 -i 0.2 -W 1 10.8.2.16参数解释-c 5发送5个探测包-i 0.2间隔200毫秒-W 1等待响应超时1秒通过统计丢包率和延迟波动可以判断是偶发网络抖动还是持续故障。2. 第二层验证TCP端口可达性测试当ping通但服务仍不可用时就需要检查TCP层的端口监听状态——这正是telnet的用武之地。2.1 telnet实战穿透防火墙的探测我们的支付网关使用8080端口对问题节点执行telnet 10.8.2.16 8080关键现象记录Trying 10.8.2.16... Connected to 10.8.2.16. Escape character is ^].这个连接成功的响应说明目标服务器TCP/IP协议栈正常工作8080端口有服务在监听中间网络设备未阻断该端口对比故障节点的测试结果Trying 10.8.2.17... telnet: Unable to connect to remote host: Connection timed out2.2 telnet的高级用法在复杂网络环境中我常用这些技巧连接测试后立即退出echo -e \x1dclose\x0d | telnet 10.8.2.16 8080带超时的快速检测timeout 3 telnet 10.8.2.17 80803. 第三层剖析应用协议交互诊断当网络层和传输层都正常时问题往往出在应用层协议。这时就需要祭出瑞士军刀curl。3.1 curl的深度透视使用verbose模式发起测试请求curl -v http://10.8.2.16:8080/api/v1/payment/status关键输出片段* Trying 10.8.2.16:8080... * Connected to 10.8.2.16 (10.8.2.16) port 8080 GET /api/v1/payment/status HTTP/1.1 Host: 10.8.2.16:8080 User-Agent: curl/7.68.0 HTTP/1.1 503 Service Unavailable Content-Type: application/json Connection: close {error:DB_CONNECTION_FAILURE}这个响应揭示了真相服务虽然运行但无法连接数据库。3.2 curl的进阶技巧仅获取响应头curl -I http://10.8.2.16:8080/health模拟慢速连接curl --limit-rate 10k -v http://10.8.2.16:8080/api保持连接复用curl -v --http1.1 --keepalive-time 60 http://10.8.2.16:80804. 问题定位与解决通过上述三层检查我们绘制出完整的故障图谱检查工具目标节点检查结果问题定位ping10.8.2.17请求超时主机宕机或网络中断telnet10.8.2.16:8080连接成功服务端口正常监听curl/api/v1/paymentHTTP 503 DB连接错误数据库连接池耗尽最终的解决方案对10.8.2.17节点执行硬重启扩容数据库连接池上限为10.8.2.16节点增加临时负载均衡权重5. 构建系统化的诊断流程根据这次经验我总结出网络问题诊断的决策树第一响应检查监控系统指标执行跨AZ的ping测试验证核心端口telnet可达性深度分析使用curl获取完整HTTP交互对比健康节点的响应差异检查TCP连接状态ss -tulnp根治措施分析根本原因(RCA)完善监控指标编写自动化诊断脚本例如这个bash脚本可自动化基础检查#!/bin/bash IP$1 PORT$2 echo Network Layer Check ping -c 3 $IP echo Transport Layer Check timeout 2 telnet $IP $PORT echo Application Layer Check curl -Is http://$IP:$PORT/health | head -n 16. 工具链的扩展应用现代分布式系统需要更全面的诊断手段并发连接测试nmap -p 8080,8443 10.8.2.0/24全链路追踪curl -H X-Trace-ID: $(uuidgen) http://service/apiTCP连接分析tcpdump -i eth0 -nn port 8080 -w debug.pcap这些工具组合使用可以构建起立体的网络诊断体系。就像那次事故后我们团队在每台服务器都部署了网络健康检查探针当类似问题再次出现时报警信息中已经包含了三层检查结果将平均故障定位时间(MTTI)从47分钟缩短到3分钟。
从一次线上服务调用失败说起：用curl、telnet和ping层层递进定位问题（附真实案例）
从一次线上服务调用失败说起用curl、telnet和ping层层递进定位问题那天凌晨2点15分企业级电商平台的支付网关突然告警。作为值班SRE我打开监控系统看到满屏红色核心微服务API的失败率在15分钟内从0.3%飙升到89%。这不是普通的服务抖动而是一场需要立即止血的生产事故。本文将还原这次故障排查的全过程展示如何像外科手术般精准使用基础网络工具定位问题。1. 第一层诊断网络基础连通性检查当服务不可用时90%的初级工程师会直接登录服务器查日志——这是个典型误区。正确的第一步应该是确认最底层的网络连通性就像医生先检查病人的生命体征。1.1 ping网络层的听诊器我首先对故障服务集群的3个节点执行ping测试ping 10.8.2.15 ping 10.8.2.16 ping 10.8.2.17得到的关键结果64 bytes from 10.8.2.15: icmp_seq1 ttl64 time0.342 ms 64 bytes from 10.8.2.16: icmp_seq1 ttl64 time112.783 ms Request timeout for icmp_seq 1 (10.8.2.17)这个输出立刻揭示了几个重要事实10.8.2.15节点网络正常10.8.2.16存在明显网络延迟10.8.2.17完全不可达注意现代云环境常默认禁用ICMP协议此时需要结合TCP层工具验证1.2 进阶ping技巧对于生产环境我通常会使用这些增强型参数ping -c 5 -i 0.2 -W 1 10.8.2.16参数解释-c 5发送5个探测包-i 0.2间隔200毫秒-W 1等待响应超时1秒通过统计丢包率和延迟波动可以判断是偶发网络抖动还是持续故障。2. 第二层验证TCP端口可达性测试当ping通但服务仍不可用时就需要检查TCP层的端口监听状态——这正是telnet的用武之地。2.1 telnet实战穿透防火墙的探测我们的支付网关使用8080端口对问题节点执行telnet 10.8.2.16 8080关键现象记录Trying 10.8.2.16... Connected to 10.8.2.16. Escape character is ^].这个连接成功的响应说明目标服务器TCP/IP协议栈正常工作8080端口有服务在监听中间网络设备未阻断该端口对比故障节点的测试结果Trying 10.8.2.17... telnet: Unable to connect to remote host: Connection timed out2.2 telnet的高级用法在复杂网络环境中我常用这些技巧连接测试后立即退出echo -e \x1dclose\x0d | telnet 10.8.2.16 8080带超时的快速检测timeout 3 telnet 10.8.2.17 80803. 第三层剖析应用协议交互诊断当网络层和传输层都正常时问题往往出在应用层协议。这时就需要祭出瑞士军刀curl。3.1 curl的深度透视使用verbose模式发起测试请求curl -v http://10.8.2.16:8080/api/v1/payment/status关键输出片段* Trying 10.8.2.16:8080... * Connected to 10.8.2.16 (10.8.2.16) port 8080 GET /api/v1/payment/status HTTP/1.1 Host: 10.8.2.16:8080 User-Agent: curl/7.68.0 HTTP/1.1 503 Service Unavailable Content-Type: application/json Connection: close {error:DB_CONNECTION_FAILURE}这个响应揭示了真相服务虽然运行但无法连接数据库。3.2 curl的进阶技巧仅获取响应头curl -I http://10.8.2.16:8080/health模拟慢速连接curl --limit-rate 10k -v http://10.8.2.16:8080/api保持连接复用curl -v --http1.1 --keepalive-time 60 http://10.8.2.16:80804. 问题定位与解决通过上述三层检查我们绘制出完整的故障图谱检查工具目标节点检查结果问题定位ping10.8.2.17请求超时主机宕机或网络中断telnet10.8.2.16:8080连接成功服务端口正常监听curl/api/v1/paymentHTTP 503 DB连接错误数据库连接池耗尽最终的解决方案对10.8.2.17节点执行硬重启扩容数据库连接池上限为10.8.2.16节点增加临时负载均衡权重5. 构建系统化的诊断流程根据这次经验我总结出网络问题诊断的决策树第一响应检查监控系统指标执行跨AZ的ping测试验证核心端口telnet可达性深度分析使用curl获取完整HTTP交互对比健康节点的响应差异检查TCP连接状态ss -tulnp根治措施分析根本原因(RCA)完善监控指标编写自动化诊断脚本例如这个bash脚本可自动化基础检查#!/bin/bash IP$1 PORT$2 echo Network Layer Check ping -c 3 $IP echo Transport Layer Check timeout 2 telnet $IP $PORT echo Application Layer Check curl -Is http://$IP:$PORT/health | head -n 16. 工具链的扩展应用现代分布式系统需要更全面的诊断手段并发连接测试nmap -p 8080,8443 10.8.2.0/24全链路追踪curl -H X-Trace-ID: $(uuidgen) http://service/apiTCP连接分析tcpdump -i eth0 -nn port 8080 -w debug.pcap这些工具组合使用可以构建起立体的网络诊断体系。就像那次事故后我们团队在每台服务器都部署了网络健康检查探针当类似问题再次出现时报警信息中已经包含了三层检查结果将平均故障定位时间(MTTI)从47分钟缩短到3分钟。
