“IT大数据”，顾名思义是运用大数据技术对企业各类IT基础设施、应用系统、数据库系统，或者各类物联网设备产生的日志进行分析与挖掘的一个平台系统。借助海量数据存储、分布式技术等大数据领域技术，IT大数据可以帮助客户解决一些传统IT运维的难题。

● 海量日志的集中存储 用分布式存储实现低成本的日志数据存储，且存储空间支持快速扩展。

● 海量日志的快速检索 用分布式计算实现海量历史日志的快速查询。

● 事件根因分析 用数据挖掘技术，实现日志数据之间的关联分析，查找故障原因或发现事件规律。

● 预测事件趋势 通过分析历史数据，总结规律，预测事件未来趋势，并推荐管控策略。

● 数据可视化 借助各类可视化效果，让数据的表现力更生动，更直观的展现事件分析结果。

从运维的角度理解，IT大数据系统是一套具有自动化计算能力的工具。自动化计算是指self-configuring（自动配置）、 self-healing（自动修复）、self-optimizing（自动优化）和self-protecting（自动保护）。IT系统日志是记录生产设备运行过程中产生的记录数据。如网络流量日志、数据库错误日志、Windows Event Logs、Linux System Logs等，这些日志记录了网络、数据库、操作系统运行状态中的各种异常、错误以及设置变更等事件。IT大数据系统所具备的日志自动关联分析、系统趋势预测、管控策略推荐等特性，使IT运维更具自动化能力，节省企业IT运维成本，提高IT管理效率。

IT大数据作为一种多功能运维工具，在日常工作中有很多最佳实践，《新IT领航》杂志将分多期与读者分享这些生动有趣的应用场景故事。

IT大数据应用场景故事1——WannaCry病毒分析

5月12日全世界陆续爆发了WannaCry蠕虫病毒，正巧IT大数据产品部的NDP解决方案（Network Data Platform Solution）开发团队正在北京X客户信息中心做某重大活动技术保障，团队成员参与了整个病毒的防控工作，并利用NDP协助客户完成病毒防控效果监控及病毒传播过程分析工作。病毒的传播感染是一个复杂多样的过程，本次病毒防控借助数据挖掘技术分析异常网络流量以追踪主机间感染过程的思路，适用于某些通过网络协议漏洞传播的蠕虫病毒分析，希望能给读者提供一些可借鉴之处，以方便日常网络运维分析。

5月13日10点左右，在X客户处值班的NDP工程师发现网络异常情况，在网络态势实时监控页面上，广域网拓扑上出现多条红色链路。红色代表了该链路某个方向的5分钟平均吞吐量超过了带宽的80%，从微观上看，这样高的负载会造成端口的大量丢包。值班工程师立即上报相关情况，经确认是WannaCry蠕虫爆发产生的大量扫描报文和感染报文造成网路拥塞。客户的安全专家组很快给出的处置建议，“在广域网的网络设备上用ACL阻断TCP 445端口报文转发,以控制病毒进一步扩散”。客户要求NDP工程师即刻开始配合病毒处置行动。

从当日13点开始，NDP系统每隔5分钟，检索一遍采集到的广域网流量日志，筛选出有TCP 445端口报文转发的设备、链路、物理接口，以此指导网络管理员在网络设备上配置ACL策略。到14日凌晨，X客户的网络上不在看到对445端口扫描的报文。此后的数天，NDP继续发挥流量监控作用，成为一支病毒防控工作的关键力量，并获得X客户的表扬。

WannaCry导致X客户的一些分支机构因病毒而停止对外服务，造成一定损失。亡羊补牢，客户希望对蠕虫病毒的传播过程分析总结，做好后续的病毒防控工作。NDP团队接受任务，梳理出以下几点分析思路：

● 通过数据挖掘技术，在NDP上筛选出异常流量日志。

● 病理分析，摸清病毒的传播扩散模式。传播途径，感染周期，手工探索分析一个传播病例，搞清楚特征。

● 在筛选出的异常流量日志中，通过脚本过滤出病毒感染日志，确定受感染主机。

1、关于数据挖掘

数据挖掘不是什么新鲜东西，由于近几年分布式计算、分布式存储等的技术快速发展，数据挖掘的效率提高很快，并且从理论研究越来越多应用到实践中。从数据挖掘技术的角度分析，利用日志数据进行异常检测的方法大致分两类。一类是基于监督的，另一类是基于无监督的。这次病毒日志的发现与分析用了“无监督学习”

基于监督学习的方法就是分类。对于系统异常检测问题，这里的类别一般就两类：“正常”和“异常”。其本质问题就是，判定一个事件，一个用户或者一个操作是“正常”还是“异常”。例如应用分类学习算法来判定Insider Threat。这里Insider Threat是指极少数异常并企图攻击内部系统的用户。在大型企业、学校以及政府的开放服务器系统内，通常都有几十甚至到几百的用户数量。这些用户来自不同的部门甚至有可能是外部公司的用户，所以并非每个用户都是可靠的使用者。极少数的用户会试图跨越本身用户等级，获取系统更高层的权限和秘密的数据。这类用户就被称之Insider Threat。通常网络设备、安全设备、Unix系统和Windows系统都会记录每个用户操作，包括系统调用、执行命令。通过收集正常用户和异常用户（Insider Threat）的用户日志数据，创建有类别的训练数据。这里的类别就是“正常”和“异常”。然后利用某种算法训练得到一个分类器，来对其他未知用户进行判定。

无监督的学习的异常检测，是指不需要提供标注的训练数据集进行的检测方法。标注的调练数据集通常很难收集,,所以基于无监督的学习方法应用更加广泛。简单来说,基于无监督学习的异常检测是异常点的判定。大致方法是通过数据挖掘里面的聚类分析找出远离类簇的数据点，基于此类方法的异常检测都有一个大前提假设:异常的日志事件出现的概率远小于正常的日志事件。

假设我们现在要分析的日志数据是一个检测程序发出的的结构化日志。每个日志包含两个属性,CPU使用率和内存使用率。

图1 数据样本分布

如图1所示出收集到的数据样本分布。正常情况下,CPU和内存使用率都是居中或者呈现一个正态分布,如图中的“簇”显示。图右上角的离群点代表着一个高CPU利用率、高内存利用率的日志事件。这个离群点远离常规的数据分布,因此可以断定此事件是个异常。在数据挖掘技术里面,离群点分析依赖聚类算法。我们可以先调用常见的聚类算法,先找到聚簇。然后遍历每个数据点,计算其到最近一个聚簇的距离。如果这个距离值远大于其他大部分点,那么这个数据点即可被判定为离群点。

2、病毒日志分析

每天NDP平台都会受到数百万如下格式的日志：

<6>Dec 6 11:25:20 H3C;110100400116022366784232;ipv4;3; network_operation: "10.5.81.4";"anonymous";"10.5.81.4";"10.1.2.48";51090;445;"AC:4E:91:5E:FD:62";"网络协议";"SMB数据共享(MS-DS)";10008;6496;9;4;270000;242000;28000;0;0;2016-12-06 11:25:17;2016-12-06 11:25:20;1;6

每条日志里面包含了22个字段，其中包括源IP、目的IP、上行字节、下行字节、会话起止时间、C/S间报文数、C/S间IP包字节最大/最小值、C/S间最大吞吐量等。根据这些特征分析用户行为，可以发现不同的用户群体会集中访问某一部分应用，这一现象与不同用户从事不同的工作内容相关。整体上大部分用户访问应用行为是正常的，但也有少数用户访问应用行为和整体行为相差较大，这些为异常行为嫌疑较大，将通过聚类算法找出这些嫌疑用户。其实这些嫌疑用户就可能是病毒感染过程的日志或者病毒扫描的日志。这个过程也好理解，例如J省某地某单位的PC，正常情况下不会连续访问总部园区的某个网段内所有PC的443端口，而这种访问正好是病毒对随机产生的IP的感染过程在网络日志中的体现。

把用户在一段时间内访问应用的端口号、上行流量、下行流量、C/S间访问频率、C/S间报文到达间隔、C/S间报文个数，作为行为特征通过聚类算法把所有用户聚成若干类，每一类中的用户都具有相似的访问行为，选用了K-means算法，NDP附带的Spark Mllib有现成可用的算法库。其中有一类点的行为与其他点的差别较大，将这些日志筛选出来，发现是从某个地址访问其他地址的445端口，并且有连续4个TCP会话。

联系安全监管部分，查证上述目的地址的主机都受到了蠕虫病毒感染。再通过NDP查询感染源主机的相关日志，可以发现该主机有大量的扫描报文，对于没有攻击成功的主机（linux ，或已经补丁的主机），TCP会话只看到从目的地址返回了一个40字节的回应报文。

3、病毒数据展现

将NDP上被筛选出的日志按照感染关系可以画出一个蠕虫传播路径的关系图，病毒的起源在10.35.108.159，然后10.201.52/24网段的6台主机被感染，然后10.39.138/24网段被扫描感染、10.192.48/24网段也被感染，病毒呈现指数级的速度不断扩散。

将不同省份受感染时间做成热力图，可以看到从5月13日上午9点左右开始，到下午18点左右全国各省基本无一幸免，如图2所示。

图2 各省感染情况热力图

各省感染主机数量增长趋势如图3所示，在13点左右，客户采取了封堵网络设备445端口的手段，所以传播速度减缓，到16点左右感染速度不在增长。

图3 各省感染主机数量增长趋势

小结

IT大数据之NDP解决方案在这次病毒事件总起到两个作用:

● 实时监控病毒重播通道(TCP 445)的流量状态，协助管理员检验ACL策略的实施情况，这里利用了日志全文检索技术，其核心技术是分布式文件存储和分布式计算。

● 在事后病毒传播分析时，用直观的图表绘制了病毒传播路径、传播范围、传播速度等分析结果，这里利用了数据挖掘技术、日志全文检索技术。

蠕虫病毒传播过程复杂多样，本文仅阐述了一种以网络流量日志来监控和分析病毒传播过程的场景，希望给读者带来一些帮助。

IT大数据应用场景故事2——链路流量拥塞原因分析

一个企业的WAN链路带宽永远是不够用的。首先，只要涉及到跨省的链路，成本都比较高，尤其是要通过跨省的专线来建设WAN。其次，总存在一个现象，有多大带宽，有会有多大的业务流量，这种矛盾一直存在。

X 客户在10年前建设了跨全国32个省的WAN，有点类似SP的核心网的形态，WAN 分为接入（各省都有）、汇聚（全国划分若干大区）、核心。由于建设年代比较长了，很多接入层设备的链路，即是从省级单位上行到大区汇聚层设备的链路都是 155M 的POS链路。可以想象一下，X客户的分支机构遍布各地，一个省内可能有几百个分支机构，数万名员工。都走这两条155M（双设备上联），稍有风吹草动，就可能形成链路拥塞。

所以，如何发现、分析和处置发生在 WAN接入层的流量拥塞，一直是X客户的网管部门面临的问题。看看传统值班员用网管系统的处理过程。

1) 网络值班员收到指令：“A省出口流量拥塞，请协查”。

2) 开NTA系统（网络流量分析系统），查看A省出口链路情况，点击链路实时流量（SNMP）,以及流量分布统计（Netstream）。看看哪个业务/应用（传输层端口号）的占比最高。

3) 值班员凭借经验判断哪个业务流造成突发。通常来说，流量占比最大的就是造成突发的流量。但这只是“通常情况”，有时会出现多个业务流量都比较大的情况，这就难办了，只能靠网管的经验了，所谓“经验”，就是网管平时对网络中常见的业务流很清楚，指导哪些应该多，哪些应该少。如果网管想看一下“过去3周的同一时段的流量分布情况”，NTA 给出的是以“小时”为颗粒度的流量分布。对于一个小时的业务平均流量，突发早就被“平滑”掉了。顺便说一句，网管系统看到的实时流量通常是分钟级的（5分钟）。

4) 如果有经验网管值班员看出了异常突发，接下来还要判断，突发流量对应的系统是啥。网管会打开一个excl 表，对照服务器IP看看是什么应用系统。凭经验分析一下，这个时段该系统是不是有这么大的流量。举个例子，如果网管看到某分支机构在工作日上午10点的时候视频流量占用一半以上的链路带宽，而往日没有这种现象，那么这个视频流量就是异常突发了。还要一种情况，如果服务器的应用系统没有登记在案怎么办？对于X客户来说，这种是经常发生，各级X单位经常以“涉密”为理由，在数据中心托管服务器，但不解释托管的事啥业务系统。即使网管能看到这个系统是TCP 80端口，也说明不了问题，因为HTTP可以承载视频、语音，即使突发的流量都是“小电影”，如果没有DPI设备，网管也不能分析出来。

5) 很幸运，网管从excl中定位到应用系统的信息了，继续分析，网管还要看看是哪些地方（省、地市、区县、单位）、哪些设备（以MAC对应的PC、PDA等你、哪些人（登录账号）在这个时段在产生大量流量。这有是个麻烦的事情，找各种EXCL，找资料数据库，打电话到相关部门要去协查，等等。

6) 最后，网管要拿出个分析报告来，请值班领导决策“是否在接入层上将突发流量限制”。这个时候需要准确的分析报告，否则万一判断错了，就会影响正常业务。比如，3月初的一天上午，X的总部需要通过WAN调阅H省的大量视频，瞬间H 省上行的一条155M链路就满了，H省用户访问总部业务都阻塞的，但这是正常流量。

1、NDP的流量拥塞分析

IT大数据的NDP解决方案有一个流量拥塞专项分析功能，可帮助客户直观的分析造成拥塞的主要原因，这里以6月某日上午10点，X客户G省出口流量拥塞分析为例，说明分析过程。

第1步：看拥塞网络拓扑-SNMP

6月某日上午10点多，控制中心来电话要求协查G省出口流量拥塞原因。其实，收到电话前，值班的网管员已经在NDP系统拓扑上看到G省上行的一条链路拥塞的。拓扑图用双向三色法标识出了，该链路上行方向（从省到总部）链路利用率超90%。这说明从G省上行到总部的流量将链路都占满了，各种业务系统都不能正常访问了。

第2步：分析拥塞链路的流量组成-Netstream

网管员在“拥塞分析功能”中，用鼠标点开拥塞链路，看到了目前上行方向占比高的TOP5 应用。占比高的主要有两个应用，目的地址分别是 10.8和67.31。

界面上同时给出了这两个应用的基线。所谓基线，就是一个阈值的范围，表示该应用在此时段正常情况时的吞吐量的范围。这个是基于历史数据拟合出来的。这个功能，在传统的网管系统中不具备或功能很弱。这个功能需要以大量的历史数据存储和大量数据计算为基础。

相比与基线，目的地址是 67.31的流量明显异常了。 TOP4的出方向流量基本达到 150Mbps。

基本定位了，就是67.31。接下来继续下钻，深入分析

第3步：流量深度识别-PI采集器

67.31服务是G省某单位客户托管到总部云数据中心的服务器。客户单位只要求打开80端口的访问，服务器具体什么业务，没有进一步信息了。由于流量是去往云数据中心的，在云中心出口的DPI采集设备可以对访问67.31的流量进行分析。

DPI 给出的结果：67.31的80端口，应用协议HTTP协议，承载“视频或语音”业务。注意，这里虽然是HTTP，但在HTTP中携带了视频流量。看来G省的好多客户端都在上午访问视频应用。

第4步：客户端设备确认-DDI

流量分析系统的一个数据来源是客户的DDI系统（DNS、DHCP、IP管理系统）。X客户采用了固定IP与DHCP 向结合的管理方式。所以，通过查询DDI系统，流量分析系统可以具体定位某个IP地址对应用户具体信息，比如MAC，地理位置等。“拥塞专项分析”功能还列出了访问67.31的TOP50的设备的信息。

第5步：用户身份确认-EAD

X客户部署了我司的EAD解决方案。所以事情简单了，用户信息也确定了。是谁、什么时间、在哪台PC上正在看视频，都清楚了。

第6步：设备资产分析-资产数据库

用户的设备资产库配合 DDI系统的数据库，可以很准确的定位到PC设备的位置。如果能配合无线定位软件，还可以找到移动客户端的大概位置。

第7步：网络影响分析-SYSLOG等

“拥塞专项分析”功能还列出了发生拥塞的路由器的一些SYSLOG，可以帮助网管人员分析检测拥塞对网络的影响。

至此，网管人员用几分钟时间，就完成了本次流量拥塞的分析。

“G省的各地市的多个单位，在6月X日上午10点，集中访问托管在云中心的67.31服务器，业务系统是某类基于HTTP的视频力量，峰值流量70M bps”

后经过电话查证，这些视频是G省“XX业务”相关的一些培训视频。总部要求G省尽快在出口侧配置流量限速，避免造成更大影响。

总结

本次事件展示了IT大数据之NDP解决方案对网络拥塞的快速分析能力，主要采用了日志全文检索技术。

但事情还是有点遗憾。目前没有将“管控系统”与流量分析系统集成。从G省上行WAN汇聚有两条155 M链路，在其中一条发生拥塞的时候，另一起的利用率只要不到20%，为解决这种路年糕部均衡问题，可以有三种管控解决方案：

● 调整路由策略——传统做法，可以实现，有很多最佳实践，但配置部署很考验网络设计与运维人员。

● QOS限速——与“调整路由策略”的问题相似，部署端到端QOS都比较考验网络规划与实施能力。

● SDN——利用SDN的控制集中，配置集中下发的特性,可以实现网络流量自动化调整，这种方案符合网络向智能化、自动化发展的趋势。当然，SDN方案对设备款型有一定要求，某些老款设备无法通过软件升级以支持SDN。

网络拥塞是日常运维中最常见的一种故障，NDP方案通过对多种类型网络日志的分析，实现了拥塞原因定位，希望上述分析思路能给读者带来一些帮助。