干货概览

做运维的人对监控这件事儿都太熟悉了，但是对于监控这么一件老生常谈的事儿，我们今天换个角度，从大数据的角度来看看有什么新的发现。

为什么要从大数据的角度来看监控这件事儿呢？首先，以大家最熟悉的服务器监控为例，虽然原理很简单，但从数据角度来看，其仍是一个典型且完整的数据采集（监控数据采集）、分析（报警）和可视化（趋势图、仪表盘）处理过程。其次，监控领域需要关心的数据不仅仅是服务器监控数据，还包含各种角度、各种来源的数据，如日志数据、网络通信数据等，数据呈现种类多、体量大和时效性要求高的特点，符合典型的大数据基本特征。

Gartner 在 2016 年第一次提出 AIOps 概念时，AI 代表了 Algorithmic（算法），算法的基石正是海量的数据，在 2017 年将 AI 含义改为 Artificial Intelligence（人工智能）后，同样需要海量的数据进行处理和学习。我们从下文的 Gartner 描绘的 AIOps 平台架构中同样能看到数据对于 AIOps、对于运维、对于监控的重要性。

我们从数据来源的角度对监控数据进行分类，比较常用的几种数据来源如下：

机器数据，常用指数★★★★★，获取难度★☆☆☆☆

日志数据，常用指数★★★★☆，获取难度★★★☆☆

网络通信数据，常用指数★☆☆☆☆，获取难度★★★★★

拨测数据，常用指数★★★★☆，获取难度★☆☆☆☆

Agent 代理数据，常用指数★★☆☆☆，获取难度★★★★☆

用户行为数据，常用指数★★★☆☆，获取难度★★☆☆☆

指数仅供参考

这么多种数据来源，各有什么特点和用途呢？接下来我们详细聊一下：

机器数据

机器数据是指服务器、网络设备等硬件或虚拟硬件运行过程中产生的状态数据，往往有对应的协议或规范，例如 SNMP、IPMI、WMI 等。通过机器数据可以准确的掌握业务承载平台的基本运行状态，例如 CPU、内存、磁盘等资源的使用情况和网络流量情况，是运维监控领域最常用的数据来源，各类开源或商业监控产品对此类数据的处理也大同小异，例如 Zabbix、Nagios 等。

云计算时代，同样离不开机器数据，虽然用户不用再关心底层物理设备的运行状态，但云厂商提供的各类云服务器、网关、负载均衡等虚拟设备同样会产生大量机器数据，需要用户时刻关注，例如云服务器的资源使用情况、带宽的使用情况、网关的负载情况等。

做好机器数据的监控可以说是做好运维监控的第一步，但仅仅有机器数据是不够的，因为机器数据存在与业务运行状态脱节的问题，机器运行平稳、资源充足并不能够代表业务运行正常，这就需要我们去丰富自己的监控数据来源，各位看官请往下看。

日志数据

日志数据是指应用程序、中间件和机器等在运行过程中由事件触发而产生的文本类数据，数据格式灵活多样。

通过日志数据可以深入的了解应用等运行过程中的详细情况，但其详细程度和覆盖面取决于产生日志的规则，有些应用产生的日志非常详细，包含了每一笔事务的处理过程，有些应用产生的日志非常简单，只会在应用报错时产生一些错误信息。

日志数据的应用场景非常广泛，上到业务指标分析，下到 Bug 追踪定位，是监控领域的全能选手。但由于日志数据的灵活性，要想利用好日志数据，必须先想好监控什么，再通过制定日志规范获取到需要的数据。日志数据的采集和分析最常用的开源方案就是 ELK Stack 了，可以说已经形成了一定的行业标准。

网络通信数据

网络通信数据是指通过抓包获取到的设备间网络通信数据，例如两台服务器之间存在网络通信，通过抓包分析可以详细的了解两台服务器之间通信的端口、协议、数据量甚至内容。常用的方式是通过硬件设备将网络流量进行镜像，对镜像数据进行分析，以避免干扰业务数据的正常流转。

网络通信数据非常全面，只要有网络通信理论上就能够抓取到详细的数据，而不需要日志数据那样提前制定好数据输出规则。想象一下你在管理一个交易系统，不需要吐任何日志就可以获取到每一笔交易的详细情况，而且这种数据获取方式还不会影响到应用的运行，是不是很爽。

但是网络通信数据的利用是较少的，难度也较大，小编私以为主要是由于网络相关的运维和业务相关的运维往往是不同的 Team 在负责，不同运维团队的关注点和侧重点不同造成的。网络运维团队更加关心网络本身的稳定性，对业务的理解不是非常深入，即使通过抓包拿到详细数据，也很难进行详细的分析。而业务相关的运维和研发团队对网络又缺乏完全的掌控，对网络的理解也不够深刻。

此外，网络通信数据也有其局限性，一些业务事件可能不会产生网路通信，也就没有对应的数据，网络通信的数据包解析需要非常清楚应用层的规则，甚至很多数据被进行了加密，这都增大了网路通信数据的利用难度。

目前小编暂时没有看到成熟的围绕网络通信数据采集和分析的开源解决方案，聊以慰藉的只有 Wireshark 这样的工具型产品了。商业解决方案方面倒是有很多不错的厂商，感兴趣的同学可以百度一下 Gartner NPMD 了解，NPMD 是指 Network Performance Monitoring and Diagnostics。

拨测数据

拨测数据是指使用探测点，通过 HTTP、Ping、TCP 等多种协议对监控目标进行探测产生的数据，《站点监控 | 网站健康检查的外科医生》一文中提到网站监控数据就属于拨测数据的一种。拨测这个词最早源于电话通信网络，通信人员在建设好电话网络后需要拨一个电话来测试是否正常，这种主动式监控方式就称为拨测了。

对于 IT 业务系统，拨测采用的探测点可以在公网，也可以在业务系统内网，不同位置的探测点起到的作用是不同的。公网探测点主要关注业务系统的网络出口质量、运营商网络质量和 CDN 质量，而内网探测点主要关注的是业务或各个业务模块的可用性及性能状态。

内网探测点的搭建非常简单，几行脚本加上一些开源组件很快就能获取到拨测数据。但公网探测点需要在公网部署大量的服务器作为探测点，公网服务器部署会带来大量的运维成本和商务成本，各位同学可以考虑使用商业解决方案，百度云监控 BCM（Baidu Cloud Monitor）的站点监控功能就能很好的满足公网环境下的拨测需求。

Agent 代理数据

Agent 代理数据是指通过字节码增强等技术来获取应用运行过程中的各类数据，与日志数据的最大区别在与其不需要在应用程序的源代码中添加数据的输出逻辑，而是在应用程序的编译或运行环节去动态的指定数据输出逻辑，其形式上也可以输出为日志，但与一般的日志数据在原理和灵活度上有着本质的区别。

Agent 代理数据最常用的场景就是应用性能管理 APM（Application Performance Management）了，通过 Agent 代理数据可以获取到应用运行过程中的事务执行过程，包括外部调用、数据库调用、分布式调用追踪、代码执行耗时等，而这一切都不需要你去修改原有的应用程序。典型的开源方案是针对 Java 应用程序监控的 Pinpoint。

用户行为数据

用户行为数据是指通过在用户终端进行埋点获取到的用户行为数据，例如在网页中通过 JS 埋点获取到的页面访问情况和在 APP 中通过 SDK 埋点获取到的各交互页面和控件的使用情况。用户行为数据除了帮助运营同学进行用户分析，还可以帮助运维的同学更加准确的了解业务系统的最终实际表现，例如哪里的用户出现了访问缓慢、哪些业务模块用户量出现了突降，这些数据能够让你站在结果的角度去分析业务系统还有哪里可以优化，也能够在问题仅仅影响一小部分用户时就能够及时发现，第一时间干预。

总 结

说了这么多种来源的数据，我们来简要总结一下：

结合各种来源类型的数据，我们可以根据业务监控需求构建出适合自己业务系统的监控方案来，你有没有发现以前没有关注过的数据来源呢？赶快进一步深入了解一下，看看能不能解决你的痛点吧。