大半夜被电话吵醒那种滋味干过运维的兄弟都懂。上周五凌晨两点多我正睡得香一个电话直接把我从梦里拽出来——某业务系统卡得不行研发那边查了一通没找到原因怀疑是网络问题让我赶紧看看。说实话接到这种电话第一反应肯定是烦躁但活儿来了还是得干。我揉着眼睛打开电脑先远程登录到核心交换机上瞄了一眼端口状态乍一看没啥问题端口也没down。但业务反馈就是慢这就很烦了——肉眼看不到的问题最难搞。先别急着抓包确定范围很重要很多新手一遇到网络问题就想着抓包分析这个思路不能说错但很多时候效率很低。流量分析也好抓包也好都是有成本的尤其是大流量的生产环境你一上来就在核心链路上开抓包可能会把链路打满搞得更糟。我一般会先做一件事缩小范围。这个业务慢到底是一个人慢还是一个部门慢还是全公司都慢如果只是某个人慢那大概率是终端或者他接入的那一段问题如果是整个部门都慢那问题可能在上游的汇聚交换机或者防火墙如果全公司都慢那基本就是核心设备或者出口链路的问题了。问了一圈下来发现是研发部整层楼都慢行政那边正常市场部也正常。这就基本可以判断问题在研发部那一段的接入层往上。范围一下子缩小了很多。用什么工具看流量别一上来就上Wireshark说到流量监控工具很多人第一个想到的就是Wireshark。Wireshark确实强大协议分析做得非常细致但它有个问题——太重了。在生产环境尤其是高流量场景下你不可能在每一台设备上都跑Wireshark实时抓包那对性能影响很大。我自己的习惯是先从轻量级的开始。比如交换机上看看端口计数看看有没有CRC错误、丢包、冲突这些指标。大部分硬件厂商的交换机都有这个功能华为的display interface、華三的display interface brief、思科的show interface都能看到。配置低的设备可能数据不准确但参考一下还是可以的。这次我先登录到研发部接入层的交换机敲了display interface发现有一个端口的input errors和CRC都明显比别的端口高。这个端口下面接的是一台汇聚交换机基本上可以判断问题点就在这段链路或者这台汇聚设备上。接着我又看了下设备的CPU和内存CPU飙到90%多内存也快满了。这就是典型的交换机累趴下了的表现。设备一旦CPU高丢包是必然的因为报文处理不过来了。抓到证据上sFlow或者NetFlow看具体流量光看端口计数还是不够细致的。要想知道到底是哪些流量在搞事情我一般会开sFlow或者NetFlow。这两个东西原理差不多都是把流量的统计信息不是原始报文发到采集器对设备性能影响很小特别适合长时间监控。我这边的环境是华为交换机用的是NetStream华为对NetFlow的实现。配置其实不复杂system-view netstream export ip 192.168.1.100 9995 // 指定采集器地址 netstream export version 9 // 用v9版本 interface GigabitEthernet0/0/24 netstream inbound netstream outbound然后在采集器上我用ntopng来收这个工具是开源的部署也简单装在一台Linux机器上就能用。配置完等个五到十分钟数据就开始往上报了。打开ntopng的web界面一看好家伙有个IP的流量占了整个接口的60%多。再点进去看详情这个IP发出去的包大部分都流向了一个外部地址。看了下目的端口是8443。研发那边主要用8443做啥呢想了想应该是某个内部系统的接口调用但这个流量明显不正常比平时高了几十倍。继续深挖必要时还是得上Wireshark到这里其实已经基本能定位了但为了搞清楚到底发的什么内容我还是抓了个包。抓包我一般不在问题设备上抓而是在它上游或者下游抓这样对问题链路的影响小一些。用tcpdump在采集器上抓了几分钟tcpdump -i eth0 -w /tmp/cap.pcap host 10.1.2.100把抓包文件拖到Wireshark里一分析发现这个IP在疯狂地往一个外部域名发请求而且请求的频率高得离谱1秒钟上百次。正常业务调用不可能这么频繁。再仔细看HTTP头虽然是8443但内部走了HTTP这哥们儿居然在循环重试每次都报504超时。问题就很明显了业务代码死循环调用某个接口但接口本身一直超时返回导致请求越积越多最终把网络带宽和交换机CPU都吃满了。定位到具体设备解决问题到这里我基本可以下结论了研发部业务系统调用外部接口失败代码进入死循环重试逻辑产生大量重复请求把接入层交换机CPU打满导致整个研发部网络卡顿临时解决也很简单——直接在交换机上把这个IP对应的MAC或者接口给shutdown了或者用ACL deny掉网络立刻恢复正常。但这只能算止血真正的根因还得研发那边去查代码逻辑。后来了解到是某个新上的功能代码里catch了异常之后没有break或者return直接retry搞了个死循环。这种问题其实上线前的压测应该能发现但有时候就是会被漏掉。我常用的几个流量监控工具盘点一下经过这么多年的折腾我手头常用的一些工具基本固定下来了给大家列一下Wireshark协议分析的王者没有之一。功能太强大了过滤器语法用熟了之后简直如虎添翼。比如常用的过滤条件ip.addr 10.1.2.100看特定IP的流量tcp.port 80 tcp.analysis.retransmission看TCP重传tcp.analysis.lost_segment看丢包http.request.uri contains api看特定URI的请求不过Wireshark对新手不太友好三次握手那个图就能把很多人看懵。建议初学者先把TCP/IP协议栈搞清楚再用Wireshark会顺手很多。ntopng基于NetFlow/sFlow的流量分析工具我个人非常喜欢它的一点是web界面做得漂亮能直观看到各种协议的占比、Top Talkers、Top Destinations。部署也简单# Ubuntu/Debian apt-get install ntopng # 修改配置 /etc/ntopng/ntopng.conf --community // 社区版 --interface eth0 // 监听网卡 --http-port 3000然后浏览器打开 http://服务器IP:3000 就能看到界面了。tcpdumpLinux下的命令行抓包工具适合在服务器上抓包分析。没有图形界面所以得配合过滤条件用。常用的tcpdump -i eth0 -nn -s 0 -c 1000 host 10.1.2.100-i指定网卡-nn不解析主机名和端口名-s 0抓完整报文-c抓多少包就退出Smokeping监控网络延迟和丢包的神器画出来的图非常直观。它会定期往目标IP发包记录延迟和丢包率。用来判断链路质量特别合适比起手动ping好用太多。配置好后看哪个时间段有尖刺丢包了就一目了然。Snort开源的入侵检测系统偏向安全方向。它能对流量做实时的模式匹配发现异常行为就报警。比如SQL注入、扫描行为、异常协议使用等等。我一般在出口或者DMZ区部署一份能及时发现很多攻击行为。网络排障的一些经验之谈干了这么多年我发现网络排障这个事情技术是一方面思路更重要一些。先全局后局部。遇到问题别一上来就钻细节先看大面的状态。设备CPU、内存、端口状态、路由表——这些信息看一眼可能就帮你排除了80%的问题。养成记录的好习惯。每解决一个问题把过程和原因都记下来。下次再遇到类似的问题搜索一下可能就能直接找到答案。我自己有个文档库分门别类记各种case时间长了这就是你最大的财富。善用对比。网络出问题往往伴随着各种指标的变化但你不一定知道什么是正常。所以平时就要把基线数据记录下来比如交换机的CPU平时都在20%以下端口流量峰值大概多少链路延迟多少毫秒。出问题的时候一对比异常就显而易见了。不要相信单一信息源。比如交换机显示一切正常但业务就是慢这时候要怀疑是不是监控本身有问题或者业务确实没问题但用户访问路径上有别的问题。多源验证是排障的黄金法则。保留现场。在动手改任何配置之前先把当前状态记录下来配置、日志、状态信息。改坏了还能回退没记录就完蛋了。我有血泪教训曾经改ACL把整个公司网络搞瘫过半小时从此之后再也不敢不备份就动手。多跟研发和业务沟通。很多网络问题其实是应用层的问题但表象在网络。就像我这次遇到的情况一样如果只盯着网络设备看永远也找不到根因。多了解业务的变化比如是不是上了新功能、是不是升级了版本、是不是数据量突然增加了这些信息对定位问题非常有帮助。写在最后网络排障这件事说难也难说简单也简单。难的是面对一个完全没见过的场景从零开始分析简单的是大部分问题其实都是那些常见的坑经验丰富的人一眼就能看出大概方向。流量监控是我们做网络排障最重要的武器之一但工具只是工具真正的核心还是你对网络协议的理解、对业务流程的理解、以及分析问题的逻辑能力。希望今天分享的这些经验能帮到大家也欢迎在评论区说说你们遇到过的奇葩网络问题咱们一起交流学习。如果你觉得这篇内容有点东西点个在看和转发给身边同样被网络问题折磨的兄弟吧这也是我持续输出干货的最大动力。
大半夜被电话吵醒那种滋味干过运维的兄弟都懂。上周五凌晨两点多我正睡得香一个电话直接把我从梦里拽出来——某业务系统卡得不行研发那边查了一通没找到原因怀疑是网络问题让我赶紧看看。说实话接到这种电话第一反应肯定是烦躁但活儿来了还是得干。我揉着眼睛打开电脑先远程登录到核心交换机上瞄了一眼端口状态乍一看没啥问题端口也没down。但业务反馈就是慢这就很烦了——肉眼看不到的问题最难搞。先别急着抓包确定范围很重要很多新手一遇到网络问题就想着抓包分析这个思路不能说错但很多时候效率很低。流量分析也好抓包也好都是有成本的尤其是大流量的生产环境你一上来就在核心链路上开抓包可能会把链路打满搞得更糟。我一般会先做一件事缩小范围。这个业务慢到底是一个人慢还是一个部门慢还是全公司都慢如果只是某个人慢那大概率是终端或者他接入的那一段问题如果是整个部门都慢那问题可能在上游的汇聚交换机或者防火墙如果全公司都慢那基本就是核心设备或者出口链路的问题了。问了一圈下来发现是研发部整层楼都慢行政那边正常市场部也正常。这就基本可以判断问题在研发部那一段的接入层往上。范围一下子缩小了很多。用什么工具看流量别一上来就上Wireshark说到流量监控工具很多人第一个想到的就是Wireshark。Wireshark确实强大协议分析做得非常细致但它有个问题——太重了。在生产环境尤其是高流量场景下你不可能在每一台设备上都跑Wireshark实时抓包那对性能影响很大。我自己的习惯是先从轻量级的开始。比如交换机上看看端口计数看看有没有CRC错误、丢包、冲突这些指标。大部分硬件厂商的交换机都有这个功能华为的display interface、華三的display interface brief、思科的show interface都能看到。配置低的设备可能数据不准确但参考一下还是可以的。这次我先登录到研发部接入层的交换机敲了display interface发现有一个端口的input errors和CRC都明显比别的端口高。这个端口下面接的是一台汇聚交换机基本上可以判断问题点就在这段链路或者这台汇聚设备上。接着我又看了下设备的CPU和内存CPU飙到90%多内存也快满了。这就是典型的交换机累趴下了的表现。设备一旦CPU高丢包是必然的因为报文处理不过来了。抓到证据上sFlow或者NetFlow看具体流量光看端口计数还是不够细致的。要想知道到底是哪些流量在搞事情我一般会开sFlow或者NetFlow。这两个东西原理差不多都是把流量的统计信息不是原始报文发到采集器对设备性能影响很小特别适合长时间监控。我这边的环境是华为交换机用的是NetStream华为对NetFlow的实现。配置其实不复杂system-view netstream export ip 192.168.1.100 9995 // 指定采集器地址 netstream export version 9 // 用v9版本 interface GigabitEthernet0/0/24 netstream inbound netstream outbound然后在采集器上我用ntopng来收这个工具是开源的部署也简单装在一台Linux机器上就能用。配置完等个五到十分钟数据就开始往上报了。打开ntopng的web界面一看好家伙有个IP的流量占了整个接口的60%多。再点进去看详情这个IP发出去的包大部分都流向了一个外部地址。看了下目的端口是8443。研发那边主要用8443做啥呢想了想应该是某个内部系统的接口调用但这个流量明显不正常比平时高了几十倍。继续深挖必要时还是得上Wireshark到这里其实已经基本能定位了但为了搞清楚到底发的什么内容我还是抓了个包。抓包我一般不在问题设备上抓而是在它上游或者下游抓这样对问题链路的影响小一些。用tcpdump在采集器上抓了几分钟tcpdump -i eth0 -w /tmp/cap.pcap host 10.1.2.100把抓包文件拖到Wireshark里一分析发现这个IP在疯狂地往一个外部域名发请求而且请求的频率高得离谱1秒钟上百次。正常业务调用不可能这么频繁。再仔细看HTTP头虽然是8443但内部走了HTTP这哥们儿居然在循环重试每次都报504超时。问题就很明显了业务代码死循环调用某个接口但接口本身一直超时返回导致请求越积越多最终把网络带宽和交换机CPU都吃满了。定位到具体设备解决问题到这里我基本可以下结论了研发部业务系统调用外部接口失败代码进入死循环重试逻辑产生大量重复请求把接入层交换机CPU打满导致整个研发部网络卡顿临时解决也很简单——直接在交换机上把这个IP对应的MAC或者接口给shutdown了或者用ACL deny掉网络立刻恢复正常。但这只能算止血真正的根因还得研发那边去查代码逻辑。后来了解到是某个新上的功能代码里catch了异常之后没有break或者return直接retry搞了个死循环。这种问题其实上线前的压测应该能发现但有时候就是会被漏掉。我常用的几个流量监控工具盘点一下经过这么多年的折腾我手头常用的一些工具基本固定下来了给大家列一下Wireshark协议分析的王者没有之一。功能太强大了过滤器语法用熟了之后简直如虎添翼。比如常用的过滤条件ip.addr 10.1.2.100看特定IP的流量tcp.port 80 tcp.analysis.retransmission看TCP重传tcp.analysis.lost_segment看丢包http.request.uri contains api看特定URI的请求不过Wireshark对新手不太友好三次握手那个图就能把很多人看懵。建议初学者先把TCP/IP协议栈搞清楚再用Wireshark会顺手很多。ntopng基于NetFlow/sFlow的流量分析工具我个人非常喜欢它的一点是web界面做得漂亮能直观看到各种协议的占比、Top Talkers、Top Destinations。部署也简单# Ubuntu/Debian apt-get install ntopng # 修改配置 /etc/ntopng/ntopng.conf --community // 社区版 --interface eth0 // 监听网卡 --http-port 3000然后浏览器打开 http://服务器IP:3000 就能看到界面了。tcpdumpLinux下的命令行抓包工具适合在服务器上抓包分析。没有图形界面所以得配合过滤条件用。常用的tcpdump -i eth0 -nn -s 0 -c 1000 host 10.1.2.100-i指定网卡-nn不解析主机名和端口名-s 0抓完整报文-c抓多少包就退出Smokeping监控网络延迟和丢包的神器画出来的图非常直观。它会定期往目标IP发包记录延迟和丢包率。用来判断链路质量特别合适比起手动ping好用太多。配置好后看哪个时间段有尖刺丢包了就一目了然。Snort开源的入侵检测系统偏向安全方向。它能对流量做实时的模式匹配发现异常行为就报警。比如SQL注入、扫描行为、异常协议使用等等。我一般在出口或者DMZ区部署一份能及时发现很多攻击行为。网络排障的一些经验之谈干了这么多年我发现网络排障这个事情技术是一方面思路更重要一些。先全局后局部。遇到问题别一上来就钻细节先看大面的状态。设备CPU、内存、端口状态、路由表——这些信息看一眼可能就帮你排除了80%的问题。养成记录的好习惯。每解决一个问题把过程和原因都记下来。下次再遇到类似的问题搜索一下可能就能直接找到答案。我自己有个文档库分门别类记各种case时间长了这就是你最大的财富。善用对比。网络出问题往往伴随着各种指标的变化但你不一定知道什么是正常。所以平时就要把基线数据记录下来比如交换机的CPU平时都在20%以下端口流量峰值大概多少链路延迟多少毫秒。出问题的时候一对比异常就显而易见了。不要相信单一信息源。比如交换机显示一切正常但业务就是慢这时候要怀疑是不是监控本身有问题或者业务确实没问题但用户访问路径上有别的问题。多源验证是排障的黄金法则。保留现场。在动手改任何配置之前先把当前状态记录下来配置、日志、状态信息。改坏了还能回退没记录就完蛋了。我有血泪教训曾经改ACL把整个公司网络搞瘫过半小时从此之后再也不敢不备份就动手。多跟研发和业务沟通。很多网络问题其实是应用层的问题但表象在网络。就像我这次遇到的情况一样如果只盯着网络设备看永远也找不到根因。多了解业务的变化比如是不是上了新功能、是不是升级了版本、是不是数据量突然增加了这些信息对定位问题非常有帮助。写在最后网络排障这件事说难也难说简单也简单。难的是面对一个完全没见过的场景从零开始分析简单的是大部分问题其实都是那些常见的坑经验丰富的人一眼就能看出大概方向。流量监控是我们做网络排障最重要的武器之一但工具只是工具真正的核心还是你对网络协议的理解、对业务流程的理解、以及分析问题的逻辑能力。希望今天分享的这些经验能帮到大家也欢迎在评论区说说你们遇到过的奇葩网络问题咱们一起交流学习。如果你觉得这篇内容有点东西点个在看和转发给身边同样被网络问题折磨的兄弟吧这也是我持续输出干货的最大动力。
全为0？揭秘验证集“空标签”引发的血案)
