在蚂蚁金服，无论是客户端还是服务端、基础设施，都统一在AntMonitor可观测平台中。我们会与业务团队合作，提供更多的平台化能力，由客户端的业务团队与我们配合建立运维体系。这包括小程序平台、客户端发布平台和客户端保障平台。针对第三方扩展，我们会提供一些行业开放的东西，大家自己编写小程序也能看到相应的数据。
二、客户端可观测技术难点
接下来，我们将讲解客户端可观测的核心技术难点，这些都是我们实际遇到的问题。既然要讲客户端，我们先回顾一下服务端的可观测数据，因为它们在很大程度上是与业界相似的。在这里，我们将介绍蚂蚁金服在服务端监控数据方面的体系，以及与其他公司的区别。
十年前，我们从日志开始构建了这个监控平台。字节可能在追踪（Trace）方面投入了更多的资源，这在每家厂商具体实际情况可能有一定区别。
我们具备可观测这三个方面（Logging、Metrics、Tracing）的能力，但是从应用程序日志转化为Metrics，最后变成指标监控的这个过程是我们使用最多的。
相对的，客户端比服务端更加复杂。针对这三个点，分别有如下难点和挑战：
Tracing：现代的SOA架构是一些小应用程序之间的串联，而客户端和服务端之间的串联是断开的。客户端本身有中间件、框架等，但是这些往往无法与后端联系起来，因此它们的价值会降低。
Metrics：聚合指标也面临着相同的问题，即如何处理早期版本和后期版本之间的指标差异。另外，”数据维度爆炸”是可观测领域普遍存在的问题。
在面对各种问题时，我们真正需要解决的是哪些问题呢？总结后有如下四点：
海量数据处理与水平伸缩架构
维度（Tag）爆炸与多维分析
海量多样化被观测实体告警
采集与埋点规范
对于维表和统一服务，我们需要对大量的数据进行对齐和补齐，同时需要补充很多用户手机端没有打上的信息。这个过程中，数据会被移动到实时数据中，并最终写入到实时数据库中。
难题一：维度（Tag）爆炸与多维分析
解决方案Part1：维度服务与维表Join
解决方案Part2：分析型时序数据库CeresDB
关于维度爆炸对存储带来的问题，我们和其他厂商可能不太一样，前面提到了腾讯、京东等存储方案非常多，我们是自研一套时序数据库，我们在设计层面就考虑到维度爆炸问题。
如何解决这个问题？我们选择了列式存储和分区剪枝。这个图有点问题，他写按年，实际我们是按天、按小时去分segment，每个segment里面有大量的源信息，对查询过程中的剪枝效果是非常好的。
解决方案Part3：分析型时序数据库CeresDB存算分离与弹性架构
介绍CeresDB分布式架构，我们自己从头开始研发了一款时序数据库，除了刚才解决单机维度爆炸的问题，还需要解决分布式问题，这包括原生Prometheus也是没有的，整个结构会变成计算存储分离结构。
解决方案Part4：分析型时序数据库CeresDB查询性能优化
CeresDB性能问题，我们通过如下三个方面解决这个问题。
针对超大数据表：百亿级别的数据表我们通过用分区表来增加水平扩展。
存算分离特有问题：
次查性能问题：次查其实就是构建多级缓存，首查已经查过了，我们需要用到首查拿回来的数据。
解决方案Part5：分析型时序数据库CeresDB性能优化
此外，查询性能也是非常重要的。目前在高筛选度条件下命中数据较少，针对某一台机器去查数据，由于存储结构设计我们跟InfluxDB不太一样，会有一定程度比InfluxDB要慢。这个问题可以通过针对小的数据块建立更多针对性的索引来优化。低筛选度条件，也就是说对大量数据做分析时，这种情况下CeresDB比InfluxDB快26倍。对于数据继续增长性能是没有什么特别大的影响的。
难题二：海量多样化被观测实体告警
我们有这么多数据，如何解决几百万被观测实体告警问题呢。运维出身的同学一定非常痛苦，不希望把所有报警手工配一遍，或者手工配出来，然后批量覆盖，这样针对每个有特点东西的覆盖效果并不是很好。
解决方案一：智能告警
目前业界比较流行，各个云厂商包括业界也有很多方案，针对曲线做异常检测。异常检测整体架构分为三层：第一层算法路由、第二层检测、第三层降噪。这三层在我们实际应用过程中效果非常好。
首先前置算法路由，拿到这个数据到底执行什么算法，不能把所有算法跑一遍，这样对系统开销是比较大的。算法路由模块会看这个数据当前有没有问题，有问题应该跑什么样的算法。中间会有具体的算法实现，但算法产生的结果并不总是我们想要的。
因此，我们需要引入降噪技术，将算法、规则和事件进行处理。这些事件可能是运维事件，也可能是主动或外部的突发事件。我们需要避免这些事件对真正需要收到告警的人造成干扰。
解决方案一：动态阈值生成技术
前面提到的单纯使用算法的异常检测可解释性非常差，真正用户并不知道里面发生了什么事情，也不知道什么情况下能告警出来，什么情况下不能告警出来，所以我们在推广时遇到非常大的阻力。
将生成的规则展示给用户，用户能直观地感受到这些规则的作用。生成规则时，可以结合数据特点，例如流量大小或检测业务总量等，这些特点可以帮助我们在生成规则时进行分类。下图解释了动态阈值生成技术的过程。
第一点和之前的内容相同，需要将一些事件的变更、突发情况或不太正常的情况剔除，以便我们通过常态的数据生成想要的规则。
上图是整体的模式实现架构。前置校验、推导任务统一调度，会由具体程序进行执行。再下面会有存储样本、算法结果，各种模板、阈值。最上面是实时运行，生成出来的规则缓存进行统一调度、告警检测。规则生成后，这些规则跟人工配置规则一起运行。
四、开源与技术演进
Holonsight在内部使用较少，主要用于小程序和云上。CeresDB的蚂蚁内部版本和开源版本完全相同，可以直接使用开源代码进行内部部署。
陈伟荣（蚂蚁集团高级技术专家）
2015年加入阿里集团，此后一直在可观测领域工作。阿里电商可观测平台
Sunfire
创始团队成员。2017年转岗蚂蚁集团，为蚂蚁
Xflush核心研发。
2019
年起负责蚂蚁可观测技术与架构团队，带领团队经过多年工作，产出了蚂蚁统一可观测平台
AntMonitor、开源时序数据库CeresDB、开源可观测平台
HoloInsight
等成果。
在小小的代码里挖呀挖呀挖，6月29-6月30，2023DOISDevOps国际峰会·北京站，可观测性、SRE、云原生架构，运维转型需要的内容，都在这里！