采用主动探测与被动采集相结合:主动使用ping、mtr、iperf/iperf3进行连通性与带宽测试;被动通过SNMP、sFlow、NetFlow或BGP监控采集真实流量数据。
建议部署Prometheus + node_exporter、cAdvisor;使用Zabbix/Nagios做基础告警;利用ntop或nProbe/ELK分析NetFlow;部署smokeping或fping做延迟趋势监测。
设置基线:延迟(RTT)稳定在50-150ms为正常参考(视回程节点而定);丢包率>1%触发告警;带宽利用率>70%触发扩容预警。定期跑iperf3窗口测试于凌晨与高峰时段对比。
覆盖CPU、内存、磁盘IO、磁盘使用率、进程数和网络队列:采集频率根据指标重要性设为10s~60s,结合历史趋势设置动态阈值。
使用Prometheus+Grafana显示时序数据,node_exporter提供主机指标,黑盒监控(blackbox_exporter)检测端口/HTTP/HTTPS可用性;配置报警路由至Slack/钉钉/邮件与值班电话。
CPU长期>85%触发并持续5分钟;内存使用接近总量的90%时触发,关注swap活动;磁盘IO等待(iowait)>25%或磁盘使用>80%告警。启用抑制规则避免告警风暴(同一故障仅触发一次主告警)。
先判断是链路侧问题还是服务器侧问题:使用分层排查法,从外部探针、骨干路由到本地网卡逐步定位。
1) 从多个地域/节点(香港、新加坡、国内)用mtr/traceroute对比路径和每跳丢包;2) 查看运营商BGP路由是否发生变动(bgpmon或RouteViews);3) 在服务器侧检查网卡错误、队列拥塞(ethtool, ifconfig, sar)和防火墙策略。
若多个外部探针在同一跳有丢包,说明链路或骨干回程(可能是CN2中间段)问题;若仅本机访问异常,优先检查内核网络参数、连接数与socket耗尽。记录每次traceroute以建立基线。
结合集中式日志与应用性能监控(APM)能把疑点缩小到模块、接口或SQL查询,做到秒级定位。
部署ELK/EFK或OpenSearch集中日志;用Jaeger或Zipkin做分布式追踪;用Prometheus与Grafana监控事务时延(P95/P99)和外部依赖调用。建立日志标签(trace_id、request_id)以便链路追踪。
出现高延迟时:先看APM的慢请求调用栈,再查看对应时间段的数据库慢查询与锁等待;出现错误率上升时:在日志中按request_id聚合错误堆栈,定位是代码、依赖还是网络超时。
采用应急Runbook(演练过的SOP)、分级告警与责任人、以及可回滚的恢复步骤,确保在最短时间内恢复关键业务。
1) 接警并记录影响范围与时间窗;2) 快速分类(网络/主机/应用/依赖);3) 根据分类执行Runbook(例如重启服务、切换到备用链路、回滚发布);4) 持续沟通并记录恢复过程。
使用PagerDuty/飞书值班、建立一键切换脚本(流量切换/灰度回滚)、定期做故障演练与故障演练后复盘(RCA)。在CN2回国链路上准备备用运营商或BGP策略以实现快速迁移。