阿里超大规模秒级监控平台的“打怪升级”之路
阿里巴巴的监控平台经历了多次迭代与更替，在曲折发展中慢慢从简单的自动化转换为颇具智能化的系统运维。
2018 年 5 月 18-19 日，由 51CTO 主办的全球软件与运维技术峰会在北京召开。
在“容器下的 AIOps”分论坛上，来自阿里巴巴集团监控负责人程超就《自动化到智能化的阿里监控发展之路》主题进行了精彩演讲。
本文将从如下三个部分来分享阿里构建超大规模的秒级监控平台的最佳实践：
打怪升级
修炼内功
仰望星空
打怪升级
和大部分的公司类似，阿里巴巴最初也采用的是 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
根据过往的监控经历，当业务方发现采集到的 CPU 抖动指标居然是监控系统所致的话，他们会宁可不要监控系统。
因此我们通过优化，让各台受监控主机上的 Agent，不再调用任何业务资源、也不做任何处理，直接将原始数据汇聚并“拉”到中心节点。“用带宽换CPU”这就是我们在设计监控系统的 Agent 时的一个原则。
而且，我们甚至都不会对日志进行压缩，因为压缩操作同样也会用到各个主机的 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 中呢？
就现在的交易模式而言，每一条交易都会产生一行日志。我们在一分钟之内会采集到海量的日志信息。
为了将它们最终转变成交易数字，大家通常做法是像 Hadoop 的“两步走”那样在 Map 层把数字抽取出来，然后在 Reduce 层进行聚合。
例如：原来在一万台机器里面有着好几个单元的维度，如今要再增加一个单元的维度，那么由于在 Reduce 层上代码是被“写死”的，因此我们要做相应的代码修改。
在完成之后，我们才能按照机房、应用、分组的维度聚合出来，并放到 HBase 之中。
如今有了 HiTSDB 的解决方案，我们就只要做一次 Map，将日志数据转换成为 Key/Value，然后直接扔进 HiTSDB 之中便可，因此也就不再需要 Reduce 层了。
此举的好处在于：通过省略其他的步骤，并仅使用 MQL 的 API，我们就能实现简单的统计。
总结起来叫做：“把前面做轻，把后面做重”。这也是我们在架构上的一项巨变。
上图是普罗米修斯的架构图，它与我们的 Sunfire 大同小异，操作理念都是“拉”的方式。
因此，我们正在努力去全面兼容普罗米修斯的前台生态，而不是它的后台。
如图右侧所示，普罗米修斯的前台提供了大量的 Exporters，甚至还有针对 IoT 的 Exporter。由于同属拉的方式，因此我们兼容起来并不费劲。
前面提到过我们用 4000 台机器来进行监控系统，这是一大笔开销。而兼容的另一个好处就是节省成本。
过去那种原封不动地拉取日志的模式，既消耗带宽资源，又耗费中心计算的成本。
如今根据普罗米修斯的概念则是：统计值，即它只统计单位时间的交易量，因此数据在总量上减少了许多。
对于报警与通知层面，我们通过“切出”的尝试，实现了如下两方面的效果：
粗剪掉报警和通知里的误报。
抑制报警和通知的爆发，避免出现报警风暴。
仰望星空
我们希望通过全方位、全链路的图表将各个系统关联起来。我认为业务的链路并非自动化产生的。
如上图所反映的就是应用与机器之间的关系。但是由于该图过于复杂、细节化、且没有分层，因此大多数的应用开发人员都不喜欢使用这张图。
于是，我们请来业务方人员进行人工绘制，详略得反映出了他们的关注点。根据他们给出的手绘图，我们再去做了上面的 Demo 图。在今年的 618 大促时，我们就是跟据此图实施的各种系统监控。
虽然我们从事监控工作的，多数出身于原来在运维中做开发、写脚本的人员，但是大家不要局限于仅解决眼前的各种运维问题，而应当多关心一些业务的方面。
去年阿里巴巴拆掉了整个运维团队，并将运维融入了开发之中。通过 DevOps，我们将各个平台层面、工具层面、自动化、智能等方面都追加了上来。
没有了保姆式的运维服务，工具团队和开发团队需要自行开发出一套工具，该工具在横向上是全方位维度+全链路的模式。
而在纵向上则包括：网络质量、应用、线路指标、APM、网络本身、IDC、以及数据。而这张图就能起到很好的“串联”作用。
如果您仔细观察就会发现：在上图中，每个方块下方的指标都是一模一样的。这是为什么呢？
在《SRE：Google运维解密》一书的监控章节中，它提出了“黄金四指标”，即流量、延迟、成功率、饱和度。
那么不管是业务、系统、还是应用，我们都可以运用这四个指标来进行判断和解决。
所以在此，我们也将这四个指标当做业务方和应用方的标准，来衡量各种业务上出现的问题。
例如，在数据层面的标准化方面，我们从前年开始就尝试着做了一个与 AI 沾点边的“智能基线”。
不知大家是否注意到，其实淘宝的交易量具有着一定规律：晚上睡觉、吃饭时交易量会比较低；而八点钟后，交易量会有所上升；另外白天十点钟的聚划算也会拉高交易量。
因此智能基线就是要把这个曲线给模拟出来，进而能够预测往后半小时的变化走势。
通过该曲线，不管是业务方、开发、运维、还是运营，都能够配置出自己的报警规则。
例如，我们可以配置为：在凌晨 2 点～4 点时段，如果真实的交易数据相对于基线下跌超过 20% 就执行报警（晚上交易量比较低，一旦波动就会很明显）；白天则在与基线相差 5% 时予以报警。
以此类推，我们相继开发出了上千条智能基线，并将它们作为基础规范，运用到智能的监控场景中，最终将准确率提升到了 80% 以上。
可见，通过对业务指标的标准化，我们从成功率的指标出发，就能够衡量和计算出来系统所碰到的问题。
说到 AI，我认为我们还处在“弱智能”的阶段，而且是不能直接一步迈到强 AI 状态的。
有一种说法是：“如今弱智能其实比强智能的需求更多”，可见我们需要有一个过渡的阶段。
如果我们将前一页图中的那些小方块的下方点击开来的话，就会看到出现这张图（当然真实场景会比该图更为复杂）。该图反映了业务指标和系统指标，而右侧是做出的智能分析。
在前面“全方位全链路”的图中，曾出现了一张红色的定单。在传统模式下，开发人员会在自己的脑子中产生一个排障的流程：从某个指标入手进行检查，如果它显示为正常的话，则迅速切换到下一个指标，以此类推下去。
那么，我们的系统就应该能够帮助开发人员，将其脑子里针对某个问题的所有可能性，即上图中各个相关的指标或框图，按照我们既定的算法扫描一遍，以检索出故障点。
此举虽然简单，甚至称不上智能，但着实有效。这也就是我所称之为的“弱智能”，而且今年我们将会大规模地上线该服务。
可见，此处体现出了“弱智能”比“强智能”更为重要的特点，这也是 AI 在监控领域落地的一个实例。
最后，我希望大家在日常脚踏实地从事开发与运维工作的同时，也能够抬头仰望星空。
在此，我给大家准备了一张图，它是从一幅巨大，巨细的总图中截取出来的。我曾用它向老板汇报 CMDB 的价值所在，且十分有效。
如图所示，你可以假设自己是一个企业的老板，试着从老板的角度思考对于企业来说，特别是对 IT 而言，如何拉高营收和降低成本。
例如：在一般情况下，监控是不会在阿里云上产生直接价值的，这体现的就是营收的维度。而我们要度量的成本还会包括额外成本，即图中所显示的“EX成本”。
例如：我们可以考虑是否真的需要用 4000 多台机器的成本来做监控系统？
因此，“仰望星空”的“观测点”可从图中的三个绿色的点出发，即 MTTR（平均故障恢复时间）、预防和度量。
这些都是企业运营者最为关心的方面。同时，图中的其他节点，大家也可以发散性地仔细思考一番。
作者：程超
编辑：陈峻、陶家龙、孙淑娟
投稿：有投稿、寻求报道意向技术人请联络 editor@51cto.com
十多年运维系统开发经验，现任职于阿里巴巴基础设施事业群，负责阿里巴巴集团监控。主导构建第一代的阿里巴巴 CMDB 系统。现负责的监控业务覆盖阿里巴巴全部事业群。
精彩文章推荐：