首选通过Ping、mtr/traceroute检测连通性与路径丢包,观察延迟抖动和跃点异常。若出现稳定的高延迟或丢包,应检查本地网卡统计(ethtool/ifconfig/ip -s link)、虚拟网络配置(bridge、vnet)、以及KT机房的上游链路公告与维护公告。
使用tcpdump或wireshark抓包,关注重传、RST或ICMP错误;在高并发场景下,查看内核netstat、conntrack以及防火墙(iptables/nft)是否达到限制。
若怀疑机房侧问题,可向KT开工单,提供抓包、mtr与时间戳,便于对方排查骨干链路或交换设备故障。
使用iostat、iotop、dstat观察IOPS、平均等待时间(await)、利用率(%util)与队列长度。若%util接近或达到100%、await显著升高且吞吐下降,则可能存在IO瓶颈。
检查虚拟化层(宿主机或存储池)是否限速,查看虚拟磁盘类型(QCOW2/RAW)、是否启用了写缓存(O_DIRECT、cache=none),以及是否受限于KT机房的共享存储IOPS策略。
可做fio基准测试(读写混合、顺序/随机)以测得真实IOPS与延迟,并比对宿主或同机房实例的表现来判断是否为机房限速或单实例问题。
通过top、htop、mpstat查看CPU利用率、各核负载与上下文切换率。若单核长期接近100%或系统负载(load average)远高于CPU核数,说明CPU或某个线程占用了过多资源。
注意查看软中断(softirq)和硬中断(irq)占比,若中断消耗过高可能与网络IO或磁盘驱动相关。还应确认是否受限于KT提供的vCPU配额或防止“超售(oversubscription)”导致的抖动。
使用perf、pidstat分析热点函数或系统调用,定位是应用层算法问题、垃圾回收(GC)频繁,还是内核层面瓶颈导致的CPU饱和。
建议按“观测→对比→隔离→验证”流程:1) 观测:收集指标(CPU、内存、磁盘、网络),日志和抓包;2) 对比:与历史基线或同机房实例对比;3) 隔离:停用非必要服务、切换到备用磁盘或网络测试实例;4) 验证:用压测或回归验证是否恢复。
记录每一步的时间戳和输出,便于与KT机房或第三方支持沟通并快速定位责任域(宿主机、网络、存储或客户配置)。
常用命令包括:ping/mtr/traceroute、tcpdump、iostat/iotop/fio、top/htop/mpstat、vmstat、sar、dmesg、ss/netstat、ethtool。监控项应涵盖:延迟/丢包、带宽、IOPS、延迟(disk await)、CPU各核利用率、load average、内存与Swap使用、磁盘队列长度和中断统计。
结合Prometheus+Grafana或Zabbix可长期保存基线与告警,便于在KT机房出现异常时快速比对并判断是宿主/网络/存储还是应用问题。