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

阿里巴巴监控平台通过了这么多年的发展，与时俱进从最开始的简单自动化到如今的人工智能的系统运维。在这我的叫作容器下的 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

所以咱们经过优化，让各台受监控主机上的 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（平均故障恢复时间）、预防和度量。