蚂蚁集团的业务种类繁多，兼具金融级的“稳” 和互联网的 “快”，支撑又快又稳的业务发展需要完善的稳定性保障体系， 这个体系的基石就是可观测性平台-AntMonitor 。

早在2011年前，监控平台就已经完成初代建设，在2012到2017年这五年间，蚂蚁监控技术团队抽象出了业务视角监控牵引的模式，大大提升了核心业务的故障发现能力，同期研发了可视化引擎与易用的配置系统。为了支撑双11等大规模海量计算场景，在底层数据技术上做到了实时稳定的大规模日志和指标处理能力。随着这些能力的完成，可观测平台的产品也逐渐成熟。

2017年后，整个蚂蚁集团 可观测性能力逐步走向了全息化、数据化和智能化 。这一代整个团队除了继承前几年的平台建设优点之外，还着力解决了几个方面的问题，包括：

完成从客户端到服务端，从业务应用到基础设施的 一站式全场景监控基于监控的海量数据， 实时数据探查和分析AIOps 智能场景化 落地

#1 特色产品能力

1. 全息可观测

所谓的全息观测能力， 能力上 融合各项可观测能力（如指标、trace、日志、性能分析）； 覆盖面上 可以做到一站式解决端到端的各类组件。这两点共同解决了数据孤岛的问题。以前观测类平台往往是四分五裂的状态，所有平台都尝试从自身的角度出发，去解决业务系统的观测问题。但是这样最终带来的是“断头路”的效果，数据只有真正能相互流通关联的时候，才能真正发挥其作用。Google也在其论文中披露，其内部监控平台也是从各个团队自行运维的borgmon逐渐收拢到统一的平台Monarch上，以解决在应急和数据分析过程中跨组件，跨部门的隔阂。

就观测能力而言， 每类观测能力均有其优势与不足 。比如，指标类数据是可以方便地展现一个实体（或大或小）随时间变化的趋势。而日志能获取明细数据，在排查具体问题的时候非常有用。trace的话往往是站在业务请求的角度，可以串联这一次请求中的上下文。蚂蚁在统一的观测平台上，逐步建立了以指标和日志为主，trace为辅助的各种能力。并且更为关键的是，平台很好地融合了这三方面的能力，使之能够各取所长。除了业界强调的可观测能力三大支柱外，蚂蚁的可观测平台还深度建设了性能分析能力和线上单机程序诊断能力。

1）日志、指标和trace的融合产品

下图上，我们可以看到底层的表格上均是关于错误量级的指标监控，同时点开也能看到错误的具体日志详情，这里对日志做了大量的模式归类、运维维度的聚合。这极大提升了业务排障的效率。

2）一体化的性能分析产品

蚂蚁的一线研发运维，可以在平台上直接或间接（通过告警自动触发）做CPU的细粒度分析。基本上，用户可以从宏观的指标到精确的代码行，都能得到定量分析。图示为on cpu的火焰图分析。

3）客户端监控能力 ，以某个小程序为例，端到端的实现全面可观测性覆盖：

4）高效的观测能力接入

在长期的发展中，蚂蚁监控技术团队也发现需要被监控的技术产品多种多样，每次都单独适配成本非常之高，因此通过定义一套通用的模型体系，满足不同用户需要，不仅能解决效能的提升，还可以建立统一的监控数据模型体系。技术上来讲，主要是通过标准化、实体化和拓扑化来解决这个问题的。

首先是标准化 。技术栈模型方案，通过让用户自主的，标准的接入一个新产品，将所有能力开放给用户，化被动为主动，一方面为用户提供丰富的开放性能力，另一方面也以一定的标准规范约束用户。

第二是实体化 。平台有能力让了解每一个组件结构模型的人，为每一个实体建立所需要的实体采集模板、展现模版和告警模版。下图以内部的分布式数据库 oceanbase 举例，通过定义不同的实体模型就可以很清晰的了解它的拓扑模型（如下图），然后根据用户的需要对不同的实体采集指标数据，并汇聚成不同维度的数据源，然后根据数据源定义不同的展现模版。

第三是拓扑关联的处理 。不同的产品都有一定的依赖关系，我们在构建实体模型的时候就已经有能力做到这一点了。

有了前面几点能力，具体操作层面用户在接入一个新类型异构的观测实体的时候， 仅仅需要做三件事 ：包括定义被观测实体与它们之间的关系、定义实体之上的采集与计算规则、基于实体与其关系定义展现与告警模板。

2. 内置数据智能

监控的实时数据是实现AIOps的基础，在有了实时、全面、精准的监控数据后，就可以在传统监控的基础上构建AIOps的数据平台，实现智能化应用。

1）灵活的数据探索分析

数据分析视角中，最直观的其实就是 查询语言 。可观测平台内部，对所有的结构化数据分成了两大类表： 时序表和维度表 。针对时序表，蚂蚁监控技术团队兼容了业界在指标监控领域比较流行的promQL，用户可以直接提交进行查询。对于需要更丰富表达能力的分析诉求，平台上针对维度表和时序表都可以执行SQL查询，包括复杂的互相join操作等均支持。

技术实现上，平台对SQL和promQL的执行在架构上实现了“ 多模输入、统一执行 ”的结构。首先在api层面，用户对一个表（或者称之为指标）既可以提交SQL 查询和promQL查询。两者在语法解析层有各自独立的实现，但是在执行层，都统一共享底层的spark、flink以及团队自研的时序数据库CeresDB等基础设施。

2）算法工程平台

有了强大的数据能力后，监控团队针对性地建设了重点的业务场景，同时也在领域内落地了算法实验室，完成了整个数据算法智能化的内部闭环，包括算法的部署、训练、回归，外部场景的管理和样本数据的管理，以及用户打标数据的回流等。

3）技术风险场景智能化

在Antmonitor的提供的实时数据和AI工程能力之上，蚂蚁监控团队深度构建了技术风险的各种场景智能化防控能力，为提升支付宝全局系统稳定性做出了重要贡献。

a.智能变更防御场景

经过对蚂蚁多年的故障分析，可以发现60%以上的故障都是人为变更导致的，因此沉淀了 智能分批监控、错误码检测、跨链路检测、变更资损检测、变更窗口检测 等多种防御微服务，包含6000多个防御规则，每天256万次自动化的防御风险校验，自从有了这套架构，每年变更故障下降50%左右。

b. 智能应急定位场景

由于支付宝分布式系统规模庞大，一笔业务可能经过数十个系统，依赖的基础设施也非常复杂，涉及相关人员很多，当出现业务失败时，如何快速定位到具体的问题节点并协调相关人员助力 解决问题 ，就成为重要命题。因此产品基于监控指标和异常检测算法，在检测故障后在钉钉群自动提示、展示故障信息、展示辅助定位信息、组织相关人员进行相应的应急处理及善后，在部分场景实现了故障自愈。

c. 智能弹性容量场景

在蚂蚁金融属性业务高稳定性和互联网的业务复杂性要求下，往往造成经典在线应用利用率长期低下，资源成本浪费严重。但是 经典的弹性伸缩无法满足蚂蚁的业务要求 ，主要原因之一是经典弹性在线资源使用和利用率是无法通过简单的线性折算出来，之二是弹性伸缩变更风险高，无技术风险控制手段，特别是缩容无风控手段，异常会直接引发故障，之三是经典在线的扩缩容速度是需要十分钟以上，扩缩容无法满足快速弹性的诉求。

经过多年的摸索和落地实践，蚂蚁弹性容量 基于技术风险防控体系+云原生统一资源调度+数据智能 ，三者组充分结合，实现在稳定性和成本优化中取最大值。基于监控大数据和机器学习算法、K8S、erviceMesh和技术风险防控技术，建设了适合蚂蚁的全局在线资源利用率无风险精确管理和全局容量异常自适应体系。主要的核心技术有多阶段伸缩、预测式伸缩、云原生分时调度技术，这也是蚂蚁绿色计算的核心技术，目前 已经将7件 “绿色计算” 相关专利无偿开放。

3. Monitoring as a Service 能力开放

AntMonitor在针对可观测性这个领域，在解决一些已知的、有共性的需求的时候，都产出了对应产品能力。但是如何承载一些和外部系统（通常是SRE团队）联动型的需求、偏领域定制需求等“未知”的需求，如何协同平台生态仍然是巨大的问题。

为此，在产品层面提出了建议 MaaS 的设想（Monitoring as a Service), 监控能力服务化，开放、融合监控能力到SRE各个领域，快速完成 SRE 场景建设，沉淀可复用能力，主要包含以下 3 个业务目标：

开放服务把监控的计算、存储、算法、视图等等能力开放出来。促进分析服务的标准化沉淀，让更多的场景可以复用、共同建设这部分的能力。解决“监”与“控”之间的链接问题。

技术实现层面，蚂蚁监控技术团队主要基于serverless能力，做了一个领域性的研发与运行平台，让用户的定制化诉求能直接在这个平台通过写一段代码的方式得到满足。这里可以直观地看到一个检查变更的服务函数的产品效果：

蚂蚁技术内部的SRE、研发、质量都可以在这样的开放技术体系下，基于监控的数据和智能化能力快速实现自己的个性化需求，目前平台已经有3万个API持续为各种应用场景持续提供服务。

#2 平台核心技术

1. 融合的时序数据平台

前面叙述的整个蚂蚁可观测性平台AntMonitor的所有产品功能均是基于团队研发的底层时序数据平台pontus。这里的时序数据平台是一个广义的时序数据的综合解决方案，可以看做是传统的CMDB和时序数据的融合平台。这个解决方案中，包括了对结构化时序数据的统一建模，数据的采集、计算、存储能力，以及数据的管理能力。具体可以参考如下大图：

1）数据管理能力

在整个平台仅面对指标监控的固定需求时，对数据的管控诉求并没有这么大。但是随着上层观测产品的日益丰富、数据冗余、数据口径定义不清、数据的来源和存储引擎的多样化等现实情况，仅仅引擎层面提供的服务是不够的。

AntMonitor底层的时序数据平台 pontus 经过迭代，其数据管理能力也得到了不断地增强，从而形成了独立的底层技术平台。平台的管理能力包括了对数据整个流转过程的全方面管理，包括采集、计算、存储、消费等，是一个综合性的解决方案能力。放眼业界，知名的云厂商也都演化出了其时序数据平台或服务，比如AWS的timestream和Azure的time series insight，它们都提供给了非常强的数据管理能力。

当前，时序数据平台管理的表数量已经达到接近百万个，支撑了蚂蚁集团所有时序类数据和元数据。

2）多维时序模型

如何用一个统一模型去组织这些数据呢？经过考虑，团队决定让平台中的数据在技术上通过“表”来承载。业务上，考虑到数仓领域已经较为成熟，因此借鉴了其中一些理论， 多维时序模型其实就是数仓中雪花模型的应用 。

前面提到，时序数据平台是一个传统CMDB和时序数据的融合平台，其中就有两类相辅相成的数据，分别是元数据和时序指标数据。 元数据 是业务、应用、基础设施自身的结构描述，而 时序数据 是他们随时间变化的状态描述。因此，所有表又分为时序表和维度表。维度表用来承载元数据，时序表用来存储被监控对象的时序观测数据，同时两者之间可以进行关联。

最终，所有的数据都组成了一张大网，同时做好了对任何系统的结构描述与状态描述。

有了这样一个模型，平台和上层的可观测业务就能真正的解耦，底层平台中不会再有任何与特定的、异构的运维实体或者公司的技术业务架构绑定的概念。这也是前述技术栈产品接入能力的理论基础。

3）海量数据处理架构

整体上，可观测平台是一个需要实时处理巨量数据的（每分钟40T 输入数据，200亿个时序数据点写入）垂直领域实时数据平台。 而且，本身蚂蚁监控技术团队服务的上层业务就是公司的SRE与稳定性团队，因此可以 说是线上稳定性的最后一道保障，需要在各种极端情况下保证这个实时系统自身的稳定。 要在一套解决方案中同时做好实时性、稳定性、低成本这三个点，其基础技术挑战非常大。

整体运行时架构可以用下图表达：

在这套架构中，我们使用了 regional的多活架构。具体来说，regional 架构是指，所有的日志采集和指标采集的收集与解析层， 都是在机房内完成的，流量不出机房以减少对骨干网和专线的网络压力。基于此架构，蚂蚁监控技术团队保障了在极端环境下的机房级甚至城市级的容灾能力。同时常态化的使用多种手段（比如单节点的资源负载调度，多集群的负载分发管理等），确保整体数据流量的持续稳定使用。

在提升整体架构的性能水平上，重点的工作是做了算子下推。这个操作的核心思想都是就近计算，通过调度计算逻辑，减少数据的搬运。算子下推这个能力，经过自动化分析之后，甚至可能直接查询agent的数据；或者中心数据大规模聚合可以做到尽量分级提取，能在单机完成的聚合直接聚合给出部分结果再由中心聚合。

2. 高性能时序数据库

随着平台对时序数据存储能力的诉求不断提高，AntMonitor团队在调研了各种开源的时序存储之后，发现或多或少存在不满足当前业务诉求。在时序数据场景中，蚂蚁集团需要同时解决这个几个问题：

1）读写高吞吐与低成本

蚂蚁的观测平台平时每分钟都在产生200亿个时序点上。如何提升极致的读写性能，甚至在双十一这样的业务峰值的时候，也能达到比较好的性能是一个重要的命题。而且，由于业务体量巨大，在解决吞吐问题的时候，也需要考虑资源成本（机器）。

2）高可用能力

观测系统是线上稳定性的最后保障。时序数据库作为观测系统的存储。必须保证在任何极端情况下都能持续稳定提供服务，典型场景比如单机不可用、机房断网等。

3）多租户与管控能力

这一点，对于大型互联网公司来说也是很关键的。蚂蚁的观测数据也是分等级的，不同的租户内的管理需求，比如TTL、资源水位等都是不一样的。

4）时序与分析能力融合

业界的时序产品，往往仅强调时序分析性能。但是我们在蚂蚁的观测平台实践中，除了要支持时序分析之外，还需要做大量大规模数据分析，基本等同于大数据中的AP场景。两者的业务目标不同，如何在同一套时序数据库中同时完成，是一个业界暂时探索不多的命题。

最终，团队决定自研一款高性能的时序数据库，也就是Ceresdb。而上面说的这些技术问题，均在自研产品上得到了解决，Ceresdb目前已经完整商业化，近期我们会将其核心代码开源，贡献给社区开放共建，希望能帮助到更多的业务场景。

3. 新硬件探索 - AEP

AEP是新型内存介质产品（数据可以持久化）。CeresDB 已经有了纯内存时序数据库 MTSDB 用于缓存最新时间段的数据以提升查询性能，但内存是昂贵的，MTSDB 保存的数据时长也受到了内存的极大限制，很难保存超过 12 小时以上的数据，而用户的查询需求越来越高，这部分数据必须从更下层的分布式存储读取，时延相对较大，如果能将这部分数据存储在和内存读写速度在一个量级的 AEP 中，那么无疑会给查询体验带来很大的提升。

实践中，我们采用了 App Direct 模式，直接使用文件系统 API 访问 AEP，将 AEP 作为内存之下的二级存储，从 MTSDB 淘汰的数据直接写入 AEP，第三级为 OBKV。

目前 ceresdb 已经在线上完成了部分集群的 AEP 试点，从线上查询观察，查询 RT 接近内存，下一步将继续努力优化在 AEP 中的数据结构，提高压缩比，降低存储成本。

#3 总结和展望

业务诉求是技术发展的核心驱动力 ，在蚂蚁业务复杂多元、极高稳定性、超大规模处理的要求下，多年持续的投入和打磨核心监控系统，逐渐演进到了今天的技术架构。同时，我们也在不断探索技术开放，通过技术开源、产品化等方式为更多的行业数字化转型提供稳定的底盘支撑。

在开源领域，我们的方向是兼容、提升与共享。在平台发展的过程中兼容了大量业界的优秀实现，同时在公司超大规模的场景下，做出了大量的创新工作，比如多维时序模型、时序与分析融合的高性能时序数据库等，形成一套领先的技术体系。后续，我们在可观测领域的这些平台与能力组件，都会逐步开源，首先将开源的是时序数据库CeresDB，希望能不断吸收业界同行的意见，也可以被更多业务场景所集成。

除了服务内部，我们的可观测平台产品也在逐渐开展商业化探索。监控平台作为蚂蚁技术风险商业化产品 TRaas 的关键产品，已经输出到数十家银行、机构。未来，更多在蚂蚁内部监控广泛使用的技术能力，比如数据分析、智能检测、AIOps应用等，也将会通过各种产品形态进行技术开放，对外赋能。