网络数据流量监测分析规程

网络数据流量监测分析规程作为一名有着近十年从业经验的企业网络运维人员，我见过太多因为没有规范的流量监测分析流程，出了问题后大家手忙脚乱乱摸一气，熬一整夜还找不到问题根源的场景：小到员工私下挂下载机占满全公司带宽没人查得出来，大到服务器被入侵变成挖矿肉鸡半个月才发现，给公司造成不少损失。正是踩过了这么多坑，我和团队慢慢整理出了这套可落地的网络数据流量监测分析规程，不管是日常运维、问题排查还是安全防控都能用，流程清晰，新手也能照着走。接下来我就把完整规程梳理清楚。1总则1.1规程制定目的制定本规程的核心目的主要有四个层面：第一是及时识别网络运行中的异常状态，不管是带宽拥堵还是非法攻击，都能第一时间发现，避免小问题拖成大故障；第二是标准化问题排查流程，缩小定位范围，提升排障效率，减少故障对业务的影响时间；第三是持续掌握网络资源的使用情况，为后续的网络扩容、架构调整提供真实的数据支撑，避免拍脑袋做决策；第四是满足行业合规要求，现在不少领域都明确要求留存一定周期的网络流量日志，规范的流程能避免检查的时候手忙脚乱补资料，我之前就帮朋友补过三个月的零散日志，累了整整两天才整理完，那滋味真的不想再试。1.2适用范围本规程适用于各类中大型企业内部局域网、私有云/公有云业务网络、面向公众提供服务的公网服务端网络，企业的运维团队、网络安全团队、网优团队都可以直接使用，小型办公网络也可以简化流程后复用，整体灵活性很强。1.3基本遵循原则整个监测分析过程要遵循四个原则：一是先整体后局部，先看全网的整体流量状态，再一步步缩小范围定位具体的异常点，不要上来就盯着某个IP抓着不放；二是先基线后异常，所有分析都要建立在和历史正常数据对比的基础上，脱离基线谈异常都是不准确的；三是止损优先，碰到恶意攻击这类紧急问题，先隔离异常源再排查原因，不要为了找源头任由异常流量影响整个网络；四是闭环管理，谁开展监测谁负责跟进到底，从监测到处置到复盘全流程跟进，不能查到问题就不了了之。明确了规程的基本要求后，我们开展监测分析的第一步不是立刻打开工具抓包，所有老运维都知道，准备工作没做足，后面十有八九要白忙活，接下来就是监测前准备阶段的具体要求。2监测前准备工作2.1网络基础信息梳理首先要梳理清楚完整的网络基础信息，这是所有工作的基础。你得先摸清楚整个网络的拓扑结构，核心交换机、出口网关的位置，各个功能区域怎么划分的——比如哪些是办公区、哪些是服务器区、哪些是对外服务的DMZ区，每个区域对应的IP地址段、核心设备的端口对应关系都要整理清楚。其次要提前标记出关键业务节点，比如企业的OA系统、客户的支付服务、核心数据库服务器，这些节点要标注优先级，监测的时候要重点倾斜资源。最后还要提前整理出不同时段的正常流量基线，比如工作日早高峰、晚间低谷、周末的平均流量大概是多少，单IP正常的连接数范围是多少，这些数据提前整理好，后面分析的时候能省超多时间。我刚接新公司网络那会，前任没留任何基础信息，上来就监测，看到核心端口流量跑到90%吓一跳，找了半天才发现那本来就是连服务器区的主干线，高峰期本来就是这个流量，属于正常情况，白白耽误了大半天，所以这一步真的不能省。2.2监测工具与权限准备常用的流量监测工具分几类，一类是交换机本身自带的流量统计功能，比如NetFlow、sFlow，不需要额外加硬件就能采样，适合日常监测；一类是硬件流量探针或者端口镜像，适合应急排查的时候获取全流量；还有各类开源和商业工具，比如日常监控用Zabbix，抓包分析用Wireshark，全流量分析可以用专门的商业平台，大家可以根据自己的预算和需求选，不用一味追求贵的，适合自己网络规模就行。工具准备好之后，还要提前申请好对应的操作权限，核心设备的配置权限、服务器区的抓包权限，如果要监测其他部门负责的业务节点，还要提前和对方负责人沟通打招呼，避免操作的时候引发误会，甚至影响对方业务运行。2.3监测范围与周期确认要提前根据监测目的确定范围和周期，如果是日常常态化监测，就是覆盖全网核心节点，重点业务每5分钟采样一次，普通业务每15分钟采样一次，全时段持续监测；如果是应急排查，就从问题发生前一小时开始，范围锁定在出问题的区域对应的设备和端口，不用全网络抓包，不然数据量太大，分析起来特别慢；如果是定期的全网流量普查，一般一个季度或者半年做一次，覆盖所有区域，采集连续三天的全时段数据，用来整体评估网络使用情况。当所有基础信息和工具都准备到位后，就可以按照不同的监测需求，开展规范的流量监测工作了，日常运维、应急排查和定期普查的操作流程各不相同，我分开说明。3流量监测实施规程3.1日常持续性监测日常监测是提前发现隐患的关键，不能放松。3.1.1核心节点监测出口网关、核心交换机的上下行端口是必须全时段监测的，要设置自动预警，当流量持续超过基线的80%的时候，就要触发预警提醒运维人员查看，不能等流量跑满了才发现问题。3.1.2关键业务监测提前标记的核心业务服务器的入口端口，除了监测总流量大小，还要监测包大小分布、新建连接数、并发连接数这几个核心指标，比如正常的HTTP业务包平均大小在几百字节，如果某台服务器突然出现大量几十字节的小包，大概率就是遭受了DDOS攻击，一眼就能看出来异常。3.1.3异常预警阈值设置预警阈值一定要设置合理，不能太松也不能太紧，太松了出问题不报警，太紧了一天跳几十个误报警，运维人员根本看不过来，反而会漏掉真的异常。我一般的设置方法是，拿连续三天同一时段的平均流量数据，上浮30%设为阈值，用下来误报率很低，也不会漏掉真异常。3.2应急针对性监测当已经出现业务卡顿、网络中断这类故障的时候，就要开展针对性的应急监测。3.2.1先定位故障层级首先查出口网关的整体流量，如果出口流量已经跑满，那就是全网层面的拥堵，如果出口流量正常，那就是局部区域或者单台设备的问题，一步步缩小范围，不要上来就去抓服务器的包。3.2.2规范配置镜像采样定位到具体的端口和设备后，再配置端口镜像获取流量，这里有个一定要注意的坑：不要随便在核心交换机上镜像大流量端口，镜像功能会额外消耗核心设备的CPU和带宽，搞不好会把原本正常的核心设备弄卡，扩大故障范围，最好是在接入层交换机或者下联设备上做镜像，风险小很多。我早年刚入行的时候踩过这个坑，核心交换机镜像之后直接卡了五分钟，全公司断网，吓出一身冷汗，这个教训真的记一辈子。3.2.3全流量留存应急监测的时候一定要把原始全流量留存下来，万一一次分析没找到问题，还能回头重新分析，不要抓完分析完就清空缓存，到时候需要的时候找不到数据，就真的没办法了。3.3周期性全网流量普查除了日常和应急监测，定期做全网流量普查也很有必要，很多隐性问题日常监测发现不了，普查就能找出来。比如我之前做普查的时候发现，公司存储区半夜十点钟流量突然翻了三倍，查了之后才发现，行政部门新上了一个云备份系统，默认设置成半夜备份全公司的文件，刚好占满了存储区的出口带宽，导致早上员工访问文件慢，之前一直找不到原因，普查一次就找到了问题。普查一般就是整体梳理各个区域的流量增长情况，看看有没有新增的不明大流量应用，整理更新基线，为扩容做准备。监测只是拿到了原始数据，核心目的是通过分析定位问题、解决问题，接下来就是流量数据分析和问题处置的具体规范。4流量数据分析与问题处置规程4.1基础分析步骤规范的分析步骤能帮你快速找到问题，不会走弯路。第一步就是对比基线，拿到数据先和提前整理好的正常基线比，看哪个指标偏离了正常范围，一下子就能把异常范围缩小；第二步就是定位异常源，现在大多数流量分析工具都能按流量占比对IP排序，占比最高的那个IP或者端口，十有八九就是问题源头，我之前碰到全公司上网卡，一排序看到某个办公IP占了80%的出口流量，过去一看就是员工私下挂了下载机下高清电影，十分钟就解决了问题；第三步就是确认异常类型，分清楚是正常的性能问题还是恶意的安全问题，正常性能问题就是业务增长、活动推广带来的流量上涨，没有恶意行为，安全问题就是攻击、病毒、挖矿肉鸡这类恶意行为，不同类型的处置方法完全不一样。4.2常见问题处置规范4.2.1非恶意流量拥堵处置如果是正常业务带来的流量拥堵，比如部门集体传大文件、电商大促带来的访问量上涨，首先和对应业务部门沟通，能错峰传输的就错峰，临时分流到备用带宽，要是这个流量增长是长期的，就整理好数据打报告申请扩容带宽或者调整网络架构，从根本上解决问题。4.2.2恶意异常流量处置如果确认是恶意流量，比如入侵、DDOS攻击、挖矿肉鸡，一定要记住止损优先，先把异常IP拉黑或者临时隔离断网，先让整个网络恢复正常，再去排查设备中毒或者被入侵的原因，查杀病毒、修补漏洞，要是是来自外部的DDOS攻击，就第一时间联系运营商开启流量清洗，封堵攻击源，不要抱着一定要找到攻击源头再处置的想法，耽误时间只会扩大损失。4.2.3隐性异常处置有些问题不是一下子就能看出来的，比如偶尔卡顿、流量忽高忽低，这种情况就要连续分析好几天的数据，找异常出现的规律，比如是不是一到上班九点就卡，那就是大家同时开机加载办公应用带来的正常峰值，要是每个月月底固定卡，那就是财务部门结账，服务器访问量上涨，找到规律之后问题就解决了一半。4.3分析结果输出不管有没有找到问题，分析完成之后都要输出正式的分析结果，写清楚监测的时间、范围、用到的工具，发现了什么问题，处置方法是什么，处置之后的效果怎么样，要是没有发现异常，也要写清楚当前的流量状态，更新基线数据，方便后面对比参考。问题处置完成不代表整个流程结束，做好收尾归档和持续优化，才能让我们的监测分析能力越来越强，少踩重复的坑，这部分的规范如下。5归档与持续优化规程5.1监测数据归档所有的监测日志、分析报告、原始流量文件，都要分类归档存储，存储周期按照行业合规要求来，一般日常日志至少存三个月，核心业务的流量数据至少存半年，归档的时候一定要做好命名和分类，按时间、按区域存到专门的存储位置，比如命名成“某年某季度-办公区流量普查分析报告”，不要随便存在个人电脑里，也不要乱命名，不然到需要找的时候，一堆文件翻半天找不到，太耽误时间。我习惯按年份分文件夹，每一个项目一个子文件夹，搜关键词就能很快找到，用着特别方便。5.2基线与规则更新每次处理完一个故障，或者做完一次全网普查，都要更新网络的流量基线，比如公司新增了几十名员工，办公区的整体流量涨了，还用老的基线就会出现大量误报警，新上线了业务系统，也要把新业务的基线加上，更新异常预警的规则，让整个监测体系一直符合当前网络的实际情况。5.3规程迭代优化每年年末都要把当年碰到的所有流量问题整理一遍，看看现有规程有没有什么漏洞，比如新增了云网络节点，就要给规程加上云流量监测的内容，碰到了新的攻击类型，就要把对应的识别方法加到分析环节，规程不是一成不变的死规则，要跟着自己网络的变化不停迭代，才能一直好用。结语以上就是完整的网络数据流量监测分析规程，整体流程从前期准备到最终复盘优化，形成了一个完整的闭环，说白了，这套规