监控系统的前世今生

本文作者 刘俊

微博平台监控技术负责人，负责微博平台、PC微博大规模监控系统的建设，主要关注实时大数据、运维自动化、智能化方向，2014年加入微博，之前曾在新浪、搜狐等公司从事运维监控方面的工作。

随着互联网的发展，监控系统也得到了发展。从最早期的网络监控、系统监控，发展到现在的业务监控、日志监控、性能监控、代码监控、全链路监控等，并在监控数据的基础上，逐步发展出了APM（应用性能管理）、AIOps（智能运维）等。

本文主要分为三个部分，将介绍监控系统的历史、流派及如何选型，希望对读者能有所帮助。

监控系统的历史

首先来看看监控系统的发展历程和常用工具软件，如图1所示。

图1 监控系统发展历史

• 早期的监控系统

互联网发展早期的监控系统，主要是指基于SNMP（简单网络管理协议）的网络监控和系统（主要指操作系统）监控。这个时候的互联网应用都很简单，只有网络设备和操作系统可以提供标准的SNMP服务，一些Web服务器、中间件也支持通过SNMP获取状态，但不是很完善。

而且在这一时期，开源还不流行，业界主流的商业监控系统（实际上监控只是这些商业管理软件的一小部分功能）有IBM的Tivoli、HP的OpenView、CA的UniCenter，主要客户是银行和电信，而弱小的互联网公司（特指那个时代）用不起。

• 现在的监控系统

随着互联网公司的发展和强大，他们对业务、服务、应用也逐渐有了较强的监控需求，而基于前面的理由，互联网公司的监控系统一般都是走自主研发和开源软件相结合的路子。毕竟“昂贵”、“耗时”、“流程”这些词在互联网公司难以生存，而能发扬光大的系统一般具有“便宜”、“快速”、“简单”的特色。当时可用的开源监控软件包括Cacti、Zabbix、Nagios、RRDTool，这些软件今天仍然很活跃，像RRDTool这样的时序数据存储方式也是目前很多时序数据库参考的标准。

业务监控继续发展，并且更加细分，出现了性能监控、代码监控、日志监控、全链路跟踪（Trace）等方向。相应地有了全面的监控、日志分析等功能，有了告警的需求。随着告警功能的完善，出现了关联、收敛等技术，并能提供一定的建议，接着干预手段（降级、封禁、流量切换、扩缩容）也可以用上了。

• 前沿方向

随着行业做到一定的程度，大家的应用水平都差不多，区别在于工程水平、产品化的能力，基于前面这些基础，又演化出了两个比较前沿的方向：APM和AIOps。

APM，即应用性能管理，定义了五个功能维度，分别为真实用户体验监控、运行时应用拓扑的发现和可视化、用户自定义业务分析、应用组件深度监控、运营分析，如图2所示。APM各大厂实施的程度也不太一样，或多或少都能靠上一部分。国外做的比较好的SaaS厂商有NewRelic 和AppDynamics，国内的读者可以自行搜索。

图2 AMP定义

AIOps，原先指“AlgorithmicIT Operations”，也就是基于算法的IT运维，即利用数据和算法提高运维的自动化程度和效率，涵盖了数据的收集、存储、分析、可视化，以及通过API提供与第三方工具集成的能力，从这个角度来说，AIOps存在了很久，目前大多数公司努力达到的也是这个层次（但是国内除了少数初创公司，大部分公司内部各部门之间的运维、监控数据的互联互通都还做不到，别说在更高层次上统筹考虑运维方案了）。在这个基础上，再加上火热的大数据和机器学习，AIOps的内涵得到了发展，即我们现在所说的“智能运维”（Artificial Intelligencefor IT Operations），目前各个公司都在尝试使AIOps落地。

流派

说到流派，每个人都会有自己的喜好和一套理论，下面会对它们进行对比，读者自行评判选择。

• Agent与Agentless

在我们的监控实践活动中，一般将必须要安装配置、对运行环境比较敏感的监控组件（一般完成信息采集和初步聚合）称为Agent，而相对应地，不需要安装、直接运行的脚本、远程SSH和基于SNMP服务、第三方管理API获取信息的方式称为Agentless（无代理）。

Agent与Agentless对比如图3所示。

图3 Agent和Agentless的对比

• Total solution与自由组合

所谓“Total Solution”（整体解决方案）特指拥有特别多功能的、“大而全”的监控系统，能完成包括数据收集、聚合、存储、展示、告警等全套功能，Zabbix、Zenoss、Open-falcon、Prometheus等都是其代表。这一类功能比较完整的监控系统特点就是“完整”，除了必要的配置，一般你不需要考虑在其之上开发什么附加功能（当然二次开发也比较困难）。

“自由组合”是另外一种流派，核心思想就是“小步快跑”、“每次只做一件事”、“每个组件只完成一个功能”。具体说起来，就是通过组合各种小工具、循序渐进的实现一系列功能，为什么强调每次只做一件事呢？因为需求不明确，或者说需求变化太快，尤其互联网公司，业务更新变化太快，在这种环境下，不太适合规划一个需要较长开发周期、拥有很多功能的系统。

很难说哪一种方式最好，只能说哪一种方式比较适合。Total Solution的好处是可以快速搭建一套完整的监控系统，即使是默认配置，对于不太复杂的监控需求一般都能满足；小步快跑的好处是在一开始需求不明确的情况下，专注于矛盾最突出的地方，专注解决一个点，如有必要再扩展。

选型

选型的意思就是选择哪一种监控体系，是成熟的产品，还是自己研发，抑或基于开源软件来集成。当我们开始规划一个监控系统的时候，这问题就需要预先考虑和分析，列出竞品之间优缺点，结合需求来选择，而不是自己熟悉那个就用那个，也不是因为别人用了，所以自己也要用。

• 需要解决什么问题

选择监控系统，需要先问自己一些问题，明确自己的需求，下面是这些问题的范例。

1. 我有很多服务器、数据库、网络设备，但可以知道它们的状态吗？
2. 我给客户提供了一项服务，但服务是否有问题、服务质量如何？
3. 我有一个（些）监控系统，但我对效果/成本/功能满意吗？（不满意是常态。）

这些问题的答案就对应着不同的解决方案：基础监控、业务服务质量监控、性能监控等，另外可以明确是需要重新建设还是在原有的基础上升级和补充。

• 分析自己的环境

“环境”包括了软硬件的运行环境，比如操作系统的版本、容器、框架、日志落地方式等，一般经过一段时间发展，环境基本上会变得“五花八门”，这时选取一个各种环境都容易集成的方案会比较好，也就是一个计算“最大公约数”的过程。

• 确定你的预算

有人觉得自己使用的是开源软件，应该没有预算问题，但是这背后还是会有很多成本的。首先就是学习和时间成本，你需要理解软件的理念和设计思想，判断是否能解决自己的问题；其次是部署和二次开发的成本，很多时候开源软件文档并不完善，需要自己探索，并且可能不能直接用于自己的环境，所以面临二次开发。一定要提前规划，看是否能够接受这些成本。

本文的内容基本介绍完毕，简单来说，如果能预计自己的数据量，并且想尽快看到效果，那么直接用成熟的“Total Solution”比较好，前期成本较低，建设速度也比较快。另外一方面，如果需求不太明确，数据量无法估算，建议还是走“自由组合”的方式，利用一些小工具，先完成主要功能，再逐步迭代和演进。当然，现实中少有人会全盘推翻之前的遗留系统重新建设一套，一般大家都是从一个还“能用”的系统起步，再组合各种工具。

————

本文节选自即将在下半年出版的博文视点亮眼新书《大型监控系统设计与构建》。