监控系统的前世今生

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

监控系统的历史

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

网络监控：OpenView  Tivoli Unicenter
系统监控：Ganglia Collected OpenNMS Cacti/RRDTool
服务应用监控：Zabbix Zenoss Nagios
业务监控： Graphite Grafana ElasticSearch StatsD TSDB Druid Hadoop/Spark
APM和AIOPS：
            终端用户体验监控
            应用拓扑的发现和可视化
            应用组件的深度监控
            异常检测。故障定位。大数据。机器学习
            自动化扩缩容。降级。封杀。流量调度

早期的监控系统

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

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

现在的监控系统

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

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

前沿方向

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

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

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

监控流派

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

Agent与Agentless

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

Agent与Agentless对比如图3所示。

Total solution与自由组合

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

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

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

选型

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

需要解决什么问题

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

我有很多服务器、数据库、网络设备，但可以知道它们的状态吗？

我给客户提供了一项服务，但服务是否有问题、服务质量如何？

我有一个（些）监控系统，但我对效果/成本/功能满意吗？（不满意是常态。）

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

分析自己的环境

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

确定你的预算

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

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

监控系统的目标

我们先来了解什么是监控，监控的重要性以及监控的目标，当然每个人所在的行业不同、公司不同、业务不同、岗位不同、对监控的理解也不同，但是我们需要注意，监控是需要站在公司的业务角度去考虑，而不是针对某个监控技术的使用。

监控目标

• 1.对系统不间断实时监控:实际上是对系统不间断的实时监控(这就是监控)
• 2.实时反馈系统当前状态:我们监控某个硬件、或者某个系统，都是需要能实时看到当前系统的状态，是正常、异常、或者故障
• 3.保证服务可靠性安全性:我们监控的目的就是要保证系统、服务、业务正常运行
• 4.保证业务持续稳定运行:如果我们的监控做得很完善，即使出现故障，能第一时间接收到故障报警，在第一时间处理解决，从而保证业务持续性的稳定运行。

监控方法

1.了解监控对象:我们要监控的对象你是否了解呢？比如CPU到底是如何工作的？ 2.性能基准指标:我们要监控这个东西的什么属性？比如CPU的使用率、负载、用户态、内核态、上下文切换。 3.报警阈值定义:怎么样才算是故障，要报警呢？比如CPU的负载到底多少算高，用户态、内核态分别跑多少算高？ 4.故障处理流程:收到了故障报警，那么我们怎么处理呢？有什么更高效的处理流程吗？

监控核心

1.发现问题:当系统发生故障报警，我们会收到故障报警的信息 2.定位问题:故障邮件一般都会写某某主机故障、具体故障的内容，我们需要对报警内容进行分析，比如一台服务器连不上:我们就需要考虑是网络问题、还是负载太高导致长时间无法连接，又或者某开发触发了防火墙禁止的相关策略等等，我们就需要去分析故障具体原因。 3.解决问题:当然我们了解到故障的原因后，就需要通过故障解决的优先级去解决该故障。 4.总结问题:当我们解决完重大故障后，需要对故障原因以及防范进行总结归纳，避免以后重复出现。