002_阿里监控平台的“打怪升级”之路

打怪升级

和大多数的公司一样，阿里巴巴最初也采用的是 Nagios+Cacti 的开源模式。

这个组合的最大问题是：不能规模化，一旦数据量达到规模级别之后，就会出现各式各样的问题。

另外，由于我们对该开源的组合未做深入研究，因此无法对它们进行定制与修改。到了 2009 年，我们决定废弃该组合，准备自己做一套监控系统。

如上图所示，这个系统支撑了阿里巴巴后续的五年发展，有一部分到现在还在用。

由于引入了域的概念，即：Monitor Domain。该监控系统的亮点是解决了数据量的问题，并能够支持水平扩展。在数据库方面，由于当时尚无 HBase 和 NoSQL 等解决方案，因此我们采用的是 MySQL。但是众所周知，MySQL 对于监控方面的支持并不好。

后来，在 HBase 成熟之后，我们就把整个数据库切换到了 HBase 之上。这对开发团队而言，带来了许多便利，同时整个系统的监控质量也提升了不少。

上图是阿里巴巴如今最新的一代、也是最重要的监控平台 Sunfire。在存储方面，我们之前用的是 HBase，现在则转为 HiTSDB（High-Performance Time Series Database，高性能时间序列数据库）。另外在数据采集方面，原来采用是在机器上安装 Agent 的方式，而现在的系统则主要采集的是日志，包括：业务方的日志、系统的日志、消息队列的日志等。

通过对接 SQL，我们将数据接入层抽象出来，同时保持上层的不变，此举的好处在于体现了“租户”的概念。

和许多采用推（Push）数据方式的监控系统不同，我们的这套架构是从上往下进行拉（Pull）数据的。

这一点，我们和普罗米修斯系统（Prometheus，它支持多维度的指标数据模型，服务端通过 HTTP 协议定时拉取数据的方式，灵活进行查询，从而实现监控目的）有着相似之处，不过我们在后台上会略强一些。

这套系统当前的规模反映在如下方面：

• 内部租户数为 90 多个。这里的租户是指：天猫、淘宝、盒马、优酷、高德等应用系统。

• 机器数为 4000 多台。这是去年双十一时的数量，其中后台并非纯粹是物理机，而是大多数为 4 核 8G 的虚拟机。

• 应用数为 11000 多个。

• 处理能力为每分钟大概 2 个 T 的数据量。当然，这同样也是去年双十一的数值。

修炼内功

下面我们来看看阿里巴巴现役监控系统的具体特征和能够解决的业务痛点：

Zero-Copy

因此我们通过优化，让各台受监控主机上的 Agent，不再调用任何业务资源、也不做任何处理，直接将原始数据汇聚并“拉”到中心节点。“用带宽换CPU”这就是我们在设计监控系统的 Agent 时的一个原则。

根据过往的监控经历，当业务方发现采集到的 CPU 抖动指标居然是监控系统所致的话，他们会宁可不要监控系统。而且，我们甚至都不会对日志进行压缩，因为压缩操作同样也会用到各个主机的 CPU。

Light-Akka

在框架方面，考虑到 Akka 先进的设计理念和不错的性能，我们曾使用它来进行构建。

但是后来发现由于它是用 Scala 语言编写的，消息不能“有且只有一次”进行传递，即无法保证 100% 可达。因此我们将自己最需要的部分抽取出来，用 Java 重新予以了实现。

Full-Asynchronous

由于数据量比较大，监控系统在运行的时候，任何一个节点一旦出现阻塞都是致命的。

我们通过将任务下发到 RegisterMapper，来“异步化”该架构的关键核心链路。

为了使得监控系统的全链路都实现“异步化”核心操作，我们可以使用网络传输中的 Unity和 Java 的异步 Http Client 等技术。大家只要稍作修改，便可达到全异步的效果。

LowPower-Agent

由于 Agent 的主要任务就是获取日志，因此我们通过不断地猜测日志的周期，根据上一次日志所记录的“游标”，以时序的方式记住它们，便可大幅减少 CPU 的消耗，从而实现低功耗的 Agent。

上图中 MQL 和 Self-Ops 也是两个重要的方面，我们来继续深入讨论：

由于各种服务的功能众多，需要监控的数据量巨大，而且数据种类与格式也都比较复杂，因此大家异曲同工地采用了各种 API 的调用方式。

对于阿里巴巴而言，我们在内部按照标准的 SQL 语法，做了一套监控数据的查询语言：Monitor Query Language–MQL。它可以统一不同种类的需求，进而实现对所有监控系统的查询。

从理论上说，无论请求有多复杂，MQL 都可以用一种 SQL 语言来表达。而且语法是由我们自行定义的，如上图中白色文字所示。

上图的下方是一个真实的例子，它查询的是从 1 小时前开始，时间窗口为 5 分钟间隔的 CPU 数据。

可见它实现起来非常简单，大家一目了然。熟悉 SQL 的人基本上不学都会写。

上图是 Self-Ops 的界面，由于它是我们内部自用的，因此略显有些粗糙。

对于每天 4000 台机器的运维工作量，虽然不同的业务系统都有各自不同的监控工具，但是我们觉得有必要将自己的监控做成一个可自运维的系统。

因此，我们从机器的管理角度出发，自行建立了内部的 CMDB，其中包括软件版本控制、发布打包等功能。

籍此，我们不再依赖于各种中间件等组件，同时也奠定了监控系统的整体稳定性。另外，该系统也给我们带来了一些额外的好处。

例如：阿里巴巴可以通过它很容易地“走出去”，接管那些海外收购公司（如 Lazada）的系统。

众所周知，监控系统一般是在业务系统之后才建立起来的，不同的业务有着不同种类的日志，而日志中的相同特征也会有不尽相同的格式表示。

因此，我们在 Agent 上下了不少的功夫，让自己的系统能够兼容各种可能性。例如：对于一个日期的表达，不同的系统就有着非常多的可能性。

所以我们在此兼容了七种常用和不常用的日期格式。同时，我们也能兼容不同的日志目录的写法。

可见，大家在准备 Agent 时，不要老想着让业务方来适应自己，而是要通过适应业务，来体现整套监控系统的核心价值。

如前所述，我们实现了自己的 MQL，而后端却仍使用的是 HBase。虽然 HBase 非常稳定，但是在面对进一步开发时，就有些“乏力”了。它对于二级缓存的支持十分费劲，更别提各种维度的聚合了。

因此，为了让 MQL 发挥作用，我们就需要切换到阿里巴巴内部基于 OpenTSDB 规范所实现的一种 TSDB 数据库 HiTSDB 之上。

为了适应大规模的监控，我们如今正在努力不断地去优化 HiTSDB，并预计能在今年的双十一之前完成。

上面就是一个整体的框架图，我们的监控平台位于其中上部。当然在阿里巴巴的内部实际上有着多套不同的监控系统，它们在自己的垂直领域都有其独特的价值。

鉴于我们的这套系统体量最大，因此我们希望将监控平台下面的各种技术组件都统一起来。

如图中红色的“计算框架”部分所示，它在整个结构中的占比非常大，因此我们将容灾、性能监控、以及异步化等全都做到了里面。

阿里巴巴如今已经出现了某个单应用涉及到超过一万台虚拟机的情况，那么我们负责收集日志事件的几千台监控机，在收集到该应用的指标之后，又将如何进行 Map，以及直接存入 HBase 中呢？

如今有了 HiTSDB 的解决方案，我们就只要做一次 Map，将日志数据转换成为 Key/Value，然后直接扔进 HiTSDB 之中便可，因此也就不再需要 Reduce 层了。总结起来叫做：“把前面做轻，把后面做重”。这也是我们在架构上的一项巨变。

就现在的交易模式而言，每一条交易都会产生一行日志。我们在一分钟之内会采集到海量的日志信息。为了将它们最终转变成交易数字，大家通常做法是像 Hadoop 的“两步走”那样在 Map 层把数字抽取出来，然后在 Reduce 层进行聚合。

上图是普罗米修斯的架构图，它与我们的 Sunfire 大同小异，操作理念都是“拉”的方式。过去那种原封不动地拉取日志的模式，既消耗带宽资源，又耗费中心计算的成本。如今根据普罗米修斯的概念则是：统计值，即它只统计单位时间的交易量，因此数据在总量上减少了许多。

对于报警与通知层面，我们通过“切出”的尝试，实现了如下两方面的效果：

• 粗剪掉报警和通知里的误报。

• 抑制报警和通知的爆发，避免出现报警风暴。

仰望星空

我们希望通过全方位、全链路的图表将各个系统关联起来。我认为业务的链路并非自动化产生的。

如上图所反映的就是应用与机器之间的关系。但是由于该图过于复杂、细节化、且没有分层，因此大多数的应用开发人员都不喜欢使用这张图。

于是，我们请来业务方人员进行人工绘制，详略得反映出了他们的关注点。根据他们给出的手绘图，我们再去做了上面的 Demo 图。在今年的 618 大促时，我们就是跟据此图实施的各种系统监控。

虽然我们从事监控工作的，多数出身于原来在运维中做开发、写脚本的人员，但是大家不要局限于仅解决眼前的各种运维问题，而应当多关心一些业务的方面。

去年阿里巴巴拆掉了整个运维团队，并将运维融入了开发之中。通过 DevOps，我们将各个平台层面、工具层面、自动化、智能等方面都追加了上来。

而在纵向上则包括：网络质量、应用、线路指标、APM、网络本身、IDC、以及数据。而这张图就能起到很好的“串联”作用。

说到 AI，我认为我们还处在“弱智能”的阶段，而且是不能直接一步迈到强 AI 状态的。

有一种说法是：“如今弱智能其实比强智能的需求更多”，可见我们需要有一个过渡的阶段。

如果我们将前一页图中的那些小方块的下方点击开来的话，就会看到出现这张图（当然真实场景会比该图更为复杂）。该图反映了业务指标和系统指标，而右侧是做出的智能分析。

在前面“全方位全链路”的图中，曾出现了一张红色的定单。在传统模式下，开发人员会在自己的脑子中产生一个排障的流程：从某个指标入手进行检查，如果它显示为正常的话，则迅速切换到下一个指标，以此类推下去。

那么，我们的系统就应该能够帮助开发人员，将其脑子里针对某个问题的所有可能性，即上图中各个相关的指标或框图，按照我们既定的算法扫描一遍，以检索出故障点。

此举虽然简单，甚至称不上智能，但着实有效。这也就是我所称之为的“弱智能”，而且今年我们将会大规模地上线该服务。

可见，此处体现出了“弱智能”比“强智能”更为重要的特点，这也是 AI 在监控领域落地的一个实例。

最后，我希望大家在日常脚踏实地从事开发与运维工作的同时，也能够抬头仰望星空。

在此，我给大家准备了一张图，它是从一幅巨大，巨细的总图中截取出来的。我曾用它向老板汇报 CMDB 的价值所在，且十分有效。

如图所示，你可以假设自己是一个企业的老板，试着从老板的角度思考对于企业来说，特别是对 IT 而言，如何拉高营收和降低成本。

在一般情况下，监控是不会在阿里云上产生直接价值的，这体现的就是营收的维度。而我们要度量的成本还会包括额外成本，即图中所显示的“EX成本”。因此，“仰望星空”的“观测点”可从图中的三个绿色的点出发，即 MTTR（平均故障恢复时间）、预防和度量。