网络出问题时，我是怎么用流量监控一步步把"凶手"揪出来的
大半夜被电话吵醒那种滋味，干过运维的兄弟都懂。上周五凌晨两点多，我正睡得香，一个电话直接把我从梦里拽出来——某业务系统卡得不行，研发那边查了一通没找到原因，怀疑是网络问题，让我赶紧看看。
说实话，接到这种电话第一反应肯定是烦躁，但活儿来了还是得干。我揉着眼睛打开电脑，先远程登录到核心交换机上瞄了一眼端口状态，乍一看没啥问题，端口也没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 就能看到界面了。
tcpdump：Linux下的命令行抓包工具，适合在服务器上抓包分析。没有图形界面，所以得配合过滤条件用。常用的：
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把整个公司网络搞瘫过半小时，从此之后再也不敢不备份就动手。
多跟研发和业务沟通。很多网络问题其实是应用层的问题，但表象在网络。就像我这次遇到的情况一样，如果只盯着网络设备看，永远也找不到根因。多了解业务的变化，比如是不是上了新功能、是不是升级了版本、是不是数据量突然增加了，这些信息对定位问题非常有帮助。
写在最后
网络排障这件事说难也难，说简单也简单。难的是面对一个完全没见过的场景，从零开始分析；简单的是大部分问题其实都是那些常见的坑，经验丰富的人一眼就能看出大概方向。
流量监控是我们做网络排障最重要的武器之一，但工具只是工具，真正的核心还是你对网络协议的理解、对业务流程的理解、以及分析问题的逻辑能力。
希望今天分享的这些经验能帮到大家，也欢迎在评论区说说你们遇到过的奇葩网络问题，咱们一起交流学习。
如果你觉得这篇内容有点东西，点个在看和转发给身边同样被网络问题折磨的兄弟吧，这也是我持续输出干货的最大动力。
关注@运维躬行录，后面会继续分享各种实战排障案例和工具使用技巧，咱们江湖再见！
公众号：耕云躬行录
个人博客：躬行笔记
