【.com原稿】阿里巴巴的监控平台经历了多次迭代和更替，逐渐从简单的自动化转型到相当强大的曲折的发展。系统智能运维。2018年5月18-19日，由主办方主办的全球软件与运维技术峰会在北京召开。在“AIOpsunderContainers”分论坛中，阿里巴巴集团主管程超以《自动化到智能化的阿里监控发展之路》为主题进行了精彩的演讲。本文将从以下三个部分分享阿里打造超大规模秒级监控平台的最佳实践：阿里巴巴最初采用的是Nagios+Cacti开源模式。这种组合最大的问题是无法缩放。一旦数据量达到规模级别，就会出现各种问题。另外，由于我们没有对这个开源组合进行过深入的研究，所以我们无法对其进行定制和修改。2009年，我们决定取消合并，准备自建监控系统。如上图所示，这套自建系统支撑了阿里巴巴随后五年的发展，部分功能至今仍在使用。由于引入了域的概念，即：MonitorDomain。监控系统的亮点在于解决了数据量的问题，并且可以支持横向扩展。数据库方面，由于当时没有HBase、NoSQL等解决方案，所以我们用的是MySQL。但是众所周知，MySQL对监控的支持并不好。例如：当我们需要向数据库中插入一个新的监控项的数据时，我们必须依次建库建表，这显然是相当繁琐的。后来HBase成熟了，我们把整个数据库都换成了HBase。这给开发团队带来了很多方便，同时整个系统的监控质量也提升了很多。上图是阿里巴巴最新一代也是最重要的监控平台Sunfire。在存储方面，之前我们用的是HBase，现在换成了HiTSDB（High-PerformanceTimeSeriesDatabase，高性能时序数据库）。另外，在数据采集方面，原来的方法是在机器上安装agent，但是现在的系统主要是采集日志，包括：业务端日志，系统日志，消息队列日志等。通过连接SQL，我们抽象数据访问层，同时保持上层不变。这样做的好处是体现了“租户”的概念。与许多使用推送数据的监控系统不同，我们的架构从上到下拉取数据。在这方面，我们与Prometheus系统有相似之处（Prometheus，支持多维指标数据模型，服务端通过HTTP协议定时拉取数据，灵活查询，达到监控目的），但我们会背景稍强。系统的当前规模反映在以下方面：90多个内部租户。这里的租户是指天猫、淘宝、盒马、优酷、高德等应用系统。机器数量4000多台，这是去年双十一的数量。后台不是纯物理机，多是4核8G的虚拟机。应用程序数量超过11000个。处理能力约为每分钟2TB的数据。当然，这也是去年双十一的价值所在。来看看阿里巴巴主动监控系统的具体特点和可以解决的业务痛点：零拷贝根据以往的监控经验，当业务方发现采集到的CPU抖动指标其实是监控系统引起的，他们宁愿不监视系统。因此，我们通过优化，让各个被监控主机上的Agent直接将原始数据聚合“拉”到中心节点，而不需要调用任何业务资源，不做任何处理。“以带宽换CPU”是我们设计监控系统Agent的原则之一。另外，我们甚至不压缩日志，因为压缩操作也会占用每个主机的CPU。在Light-Akka框架方面，考虑到Akka先进的设计理念和良好的性能，我们采用它来构建。但是后来发现因为是用Scala语言写的，消息不能“oneandonlyonce”传递，即不能保证100%可达。所以我们提取了我们最需要的部分并用Java重新实现它们。Full-Asynchronous由于数据量比较大，在监控系统运行的时候，任何一个节点一旦被阻塞，都是致命的。我们通过向RegisterMapper发送任务来“异步”架构的关键核心环节。为了让监控系统的整个链路实现“异步”的核心操作，我们可以在网络传输中使用Unity、Java的异步HttpClient等技术。你只需要做一些小的修改就可以达到完全异步的效果。LowPower-Agent由于Agent的主要任务是获取日志，我们可以通过不断猜测日志的周期，根据上一条日志记录的“游标”顺序记忆，从而大大降低CPU消耗，从而实现低功耗的Agent。上图中，MQL和Self-Ops也是两个重要的方面。下面继续深入讨论：由于各种服务的功能众多，需要监控的数据量巨大，数据的类型和格式也比较复杂，所以每个人都不一样。使用各种AP??I调用方法。对于阿里巴巴，我们内部按照标准的SQL语法构建了一套监控数据的查询语言：MonitorQueryLanguage-MQL。可以统一各种需求，进而实现对所有监控系统的查询。理论上，无论请求多么复杂，MQL都可以用一种SQL语言来表达。并且语法是我们自己定义的，如上图白色文字所示。上图下半部分是一个真实的例子，查询从1小时前开始的CPU数据，时间窗口间隔5分钟。可见实现起来非常简单，大家一看就明白了。熟悉SQL的人基本不用学就能写。上图是Self-Ops的界面，因为是我们内部使用的，所以有点粗糙。对于每天4000台机器的运维工作量，虽然不同的业务系统都有自己的监控工具，但是我们觉得有必要让我们的监控成为一个可以自己运维的系统。因此，我们从机器管理的角度，建立了自己的内部CMDB，包括软件版本控制、发布打包等功能。这样我们就不再依赖各种中间件等组件，也建立了监控系统的整体稳定性。此外，该系统还为我们带来了一些额外的好处。例如：阿里巴巴可以很容易地通过它“走出去”，接管那些海外收购公司（如Lazada）的系统。众所周知，监控系统一般是在业务系统之后建立的。不同的业务有不同类型的日志，日志中相同的特征也会有不同的表现形式。因此，我们在Agent上投入了很多精力，让我们的系统兼容各种可能。例如：对于日期的表达，不同的系统有很多种可能。所以这里我们兼容了七种常见和不常见的日期格式。同时我们也兼容不同日志目录的写法。可见，在编写Agent的时候，不要总想着让业务端适应你，而是要通过适应业务来体现整个监控系统的核心价值。如前所述，我们实现了自己的MQL，而后端仍在使用HBase。HBase虽然很稳定，但是面对进一步的发展，还是有些“软弱”。支持二级缓存就很费力了，更别提各种维度的聚合了。因此，为了让MQL发挥作用，我们需要切换到HiTSDB，这是阿里巴巴基于OpenTSDB规范实现的TSDB数据库。为了适应大规模监控，我们现在正在努力对HiTSDB进行持续优化，预计今年双十一前完成。上面是一个整体的框架图，我们的监控平台位于上半部分。当然，阿里巴巴内部其实有很多不同的监控系统，它们在自己的垂直领域都有着独特的价值。由于我们的系统是最大的，我们希望将监控平台下的各个技术组件统一起来。如图中红色的“计算框架”部分，它在整个架构中所占的比重非常大，所以我们把容灾、性能监控、异步集成到里面。阿里巴巴现在已经看到单个应用涉及到10000多台虚拟机，所以我们负责收集几千台监控机器进行日志事件。收集到应用的指标后，我们如何映射并直接存储到HBase中呢？就目前的事务模式而言，每个事务都会产生一条日志行。我们将在一分钟内收集大量日志信息。为了将它们转化为交易号，通常的做法是像Hadoop的“两步法”那样在Map层抽取数字，然后在Reduce层聚合。例如：原来10000台机器有几个单位维度，现在我们需要再增加一个单位维度，那么由于Reduce层的代码是“硬编码”的，所以我们需要相应地修改代码。完成后，我们可以按照机房、应用、分组等维度进行聚合，放入HBase中。现在有了HiTSDB的方案，我们只需要做一次Map，将日志数据转换成Key/Value，然后直接丢进HiTSDB，就不需要Reduce层了。这样做的好处是我们可以通过省略其他步骤，只使用MQLAPI来实现简单的统计。概括起来就是：“使前轻，使后重”。这也是我们架构的翻天覆地的变化。上图是Prometheus的架构图，跟我们Sunfire类似，它的运行理念是“拉”。因此，我们正在努力完全兼容Prometheus的前端生态，而不是它的后端。如图右侧所示，Prometheus的前台提供了大量的Exporter，甚至是IoT的Exporter。由于拉的方式相同，我们不难兼容。如前所述，我们使用4000台机器来监控系统，这是一个很大的开销。兼容性的另一个好处是节省成本。以往原封不动拉取日志的模式，不仅消耗带宽资源，还消耗中心计算的成本。现在按照Prometheus的概念：统计值，也就是只统计单位时间内的交易量，所以数据总量就减少了很多。对于告警和通知层面，我们通过尝试“切掉”达到了以下两个效果：粗略地切掉了告警和通知中的误报。抑制警报和通知的爆发以避免警报风暴。仰望星空，我们希望通过一个综合的全链路图来连接各个系统。我不认为业务链接是自动生成的。上图反映了应用程序和机器之间的关系。但是大多数应用程序开发人员不喜欢使用这个图，因为它太复杂、太详细，而且没有层次感。因此，我们请来了业务方的人员手工绘制，详细反映了他们的顾虑。根据他们给的手绘图，我们做了上面的demo图。今年618推广的时候，我们就是根据这张图来进行各种系统监控的。虽然我们从事监控工作的大部分人都是以前开发写运维脚本的人，但是大家不应该局限于解决手头的各种运维问题，而应该多关注一些业务方面的问题。去年，阿里巴巴拆掉了整个运维团队，将运维整合到开发中。通过DevOps，我们增加了平台层面、工具层面、自动化、智能化等方面。没有保姆式运维服务，工具团队和开发团队需要自己开发一套工具，横向是全维度+全链路的模型。纵向包括：网络质量、应用、线路指标、APM、网络本身、IDC、数据。而这张图可以起到很好的“联系”作用。如果你仔细观察，你会发现在上图中，每个方块下面的指示符是完全一样的。为什么是这样？在《SRE：Google运维解密》一书的监控章节中，提出了“黄金四大指标”，即流量、时延、成功率、饱和度。所以无论是业务、系统还是应用，我们都可以通过这四个指标来判断和解决问题。所以在这里，我们也把这四个指标作为业务端和应用端的标准来衡量各个业务出现的问题。比如在数据层面的标准化方面，我们从去年开始就在尝试打造一个有点AI的“智能基线”。不知道大家有没有注意到，淘宝的交易量有一定的规律：晚上睡觉吃饭的时候交易量会比较低；八点以后，交易量会增加；此外，白天十点的聚划算也将增加成交量。所以，智能基线就是模拟这条曲线，然后能够预测接下来半个小时的变化趋势。通过这条曲线，无论是业务端、开发、运维，还是运营，都可以配置自己的告警规则。例如，我们可以这样配置：在凌晨2:00-4:00这段时间，如果真实交易数据相对于baseline下降超过20%，则发出告警（交易量在夜间比较低，一旦波动就会很明显）；当基线相差5%时会发出警报。以此类推，我们先后开发了数千条智能基线，并将其作为基础规范应用于智能监控场景，最终准确率达到80%以上。可以看出，通过业务指标的标准化，我们可以从成功率的指标出发，衡量和计算系统遇到的问题。说到AI，我觉得我们还处于“弱智能”阶段，还不能直接一步跨入强AI状态。有句话说：“现在弱智其实比强智更需要”，说明我们需要一个过渡阶段。如果我们点击上一页图片中小方块的底部，就会看到这张图（当然真实场景会比这张图复杂）。该图反映了业务指标和系统指标，而右侧是做出的智能分析。在之前的“全方位全链接”图中，有一个红色的命令。在传统模式下，开发者会在脑海中建立一个故障排除流程：从某个指标开始检查，如果显示正常，则迅速切换到下一个指标，以此类推。那么，我们的系统应该能够帮助开发者在脑海中扫描出某个问题的所有可能，也就是上图中的每一个相关指标或者方块图，按照我们既定的算法，找出故障点。这是一个简单但不聪明的举动，但它确实有效。这就是我所说的“弱智能”，今年我们将大规模推出这项服务。可见，“弱智能”比“强智能”的特点在这里得到了体现，这也是AI在监控领域落地的一个例子。最后希望大家在踏踏实实做开发和运维工作的同时，也能仰望星空。在这里，我为大家准备了一张图，它是从一张巨大而详细的普通图上剪下来的。我用它向我的老板展示了CMDB的价值，而且非常有效。如图所示，你可以假设自己是一家企业的老板，试着站在老板的角度思考如何为企业，尤其是IT增加收入，降低成本。比如：一般情况下，监控不会在阿里云上产生直接的价值，体现的是收入维度。而我们要衡量的成本还会包括额外的成本，也就是图中所示的“EX成本”。例如：我们可以考虑监控系统是否真的有必要使用4000多台机器的成本？因此，《仰望星空》的“观察点”可以从图中绿色的三个点开始，即MTTR（meantimetorecoveryfromfailure）、预防和测量。这些都是经营者最关心的方面。同时，你可以发散地考虑图中的其他节点。拥有十余年运维系统开发经验，目前就职于阿里巴巴基础设施事业群，负责阿里巴巴集团的监控工作。主导建设第一代阿里巴巴CMDB系统。目前负责的监控业务涵盖阿里巴巴所有事业群。【原创稿件，合作网站转载请注明原作者和出处为.com】
