开发者学堂课程【阿里云可观测峰会：开源全场】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/1060/detail/15342
开源全场
五、基于 eBFF 的 Kubernetes 可观测最佳实践
1、背景介绍
自2018年加入阿以来，先负责了分布式任务调度系统 SxhedulerX 的核心引擎设计与开发工作。企业级pass平台一个的云原生架构升级工作。从零到一个构建基于EBPF的监控产品，这些经历使得对大型复杂分布式系统的可观测性有了多角度的理解，正因为如此对EBPF在可观测领域起的作用以及它的发展潜力都十分认可，这项技术值得学习与应用。
（1）问题排查的原则
可观测是为了解决问题，在可观测之前，问题排查的朴实原则。以排查一个系统问题为例。首先要理解系统，主要关注基础知识，必须要理解业务，理解编程语言，基本的计算机科学知识，要关注系统大图，比如架构部署和一些重要大的流程，要关注运行细节，要对核心功能的算法数据结构了于心，关注系统的运维工具要能够发布和监控它，在理解的基础上面，一定要能够复现问题，主要关注问题发生的触发条件以及问题发生时数据现场的保留，包含指标、链路、日志、事件数据等等。有了现场并且我们理解系统就可以定位问题，通过现场保留的数据进行一个关联分析。基于理解可以快速的用二分查找定位到根因。在定位的过程当中，尤其要关注变更，因为有大量的系统问题是由变更带来的。在确定更新之后就要进行一个修复，在修复这块主要是既要治标，还要治本，并且要充分验证确定，不要引入新的问题，依次循环。其实一个问题排查的普适原则，它不仅仅适用于系统问题的排查，其实可以应用到生活的方方面面。而可观测就是使得问题排查的一个过程更加高效稳定和低成本。他要帮助理解系统，出现问题的时候，要留下足够多的现场，数据之间很方便的去关联，帮做一个二分的关联分析。最终它可以帮验证修复是否正确。
（2）Kubernetes 可观测挑战
复杂度是恒定的，它不会消失只会转移。构建的编程语言，编程框架，容器，操作系统都只是把复杂度关在合适的地方。当一切运行正常皆大欢喜。但是一旦出现问题是灾难。这种复杂度不断下沉的趋势使得可观测面临着很大的压力。因为K8S的流行，使得微服务架构十分流行。多语言、多通信协议成为常态。带来了挑战一，端到端观测复杂度上升，买点成本居高不下，但只是冰山一角。有大量的能力下沉到管控层，容器运行层，还有网络和操作系统层面。这些基础设施能力的下沉给带来了挑战。由于关注点的分离，使得应用问题与底层的问题无法置顶向下形成关联。与此同时，还面临着挑战三。虽有很多工具，但是上下文缺失，数据散落，导致无法用些数据来很好的理解应用。因为现场的缺失，无法关联，使得问题排查效率低下，可观测需要有统一的技术来解决自身的复杂度。
2、基于eBPF的可观测实践分享
（1）eBPF介绍
从一开始内核其实就是一个可观测的绝佳地方，由于效率和安全问题。一值无法实现，经过多年发展，EBPF 技术为可观测打开了一个新的大门。EBPF是一个可以安全的在内核中运行沙盒程序的技术，在无需修改代码即可在内核用户态程序事件发生时运行。
它具备以下特性:无侵入特性。使得观测的成本极低，应用不需要修改任何代码也不需要重启进程。具备动态可编程性:不需要重启探针，可以动态的下发脚本即可修改探侦测的逻辑，具备高性能特性，自带git编译，使得探针获得内核本地运行的一个效率。具备安全特性。Fire机制限制了 EBPF 脚本能够访问的内核函数能够做的事情，使得内核的运行一定是稳定。除了些令人振奋的特性之外，EBPF的使用流程也是方便的，以监控应用性能为例，只需要加载编译EBPF程序去监听网络的内核事件，将网络协议解析出来聚合成指标，输出trace即可完成目标。
（2）基于eBPF 的统一个可观测平台架构
EBPF的生态现在发展也相当不错，背后有很多公司在支持，整体的发展十分迅猛，过去一年阿里云可观测团队基于 EBPF 技术构建了统一个可观测平台。
自下向上来看首先是数据采集层，主要是采用TRACE LOG 等函数来抓取相关的系统调用，关联进程容器信息形成原始的事件，通过EDPF和CD的结合来支持多内核版本，同时为了解决事件爆炸的问题，引入了事件过滤和高性能事件传输的机制。其次是数据处理层，当用户获取到原始事件之后，首先会进行一个协议的解析，生成指标链路、日志等数据。在过程当中也会对信息做一些收敛，将填充原信息。比如K8S信息填充或者自定义应用信息填充，最后的监控数据会通过open Telemetry collector输出，引入 open Telemetry collector 主要是为了支持多种数据类型以及多数据传输通道，使得可以支持将监控数据写入用户指定的存储，默认情况下指标会存储在Prometheus，用CMDB存储链路和日志会存在，使用SLS来存储，最后是数据服务层，通过arms的前端以及Grafana最终呈现用户多种多的观测服务。
（3）如何进行无侵入式多语言的协议解析
Arms 可观测团队关注EBPF在应用层的应用，通过监听相关的网络内核调用构建连接跟踪，将传输的网络包进行协议分析，得到应用层面的请求响应对，可以无侵入式的支持多语言场景下请求数响应时间错误数黄金指标的监控，目前支持http 、Redis 、DNS、卡夫卡、Mexico grbc htp等协议，支持的协议列表在不断的扩充。
（4）线上问题与解决方法
过去一年多的生产实践中遇到最多的问题主要是有四个。第一内核版本适配问题。EBPF 在内核版本4.14以上才有较为成熟的支持，但是线上还是有很多老的内核版本，部分使用CCD进行支持，高版本在core不成熟的情况下是使用动态下载内核头文件，动态编译的方式进行支持。
第二问题是内核事件爆炸。传统的监听Transports cap Pro会产生巨的事件，给探针的性能造成巨的压力，为解决问题引入了世界过滤机制只处理相关的网络调用事件，同时优化事件传输序列化，达到一个高性能事件传输的目的。
第三在事件的消费侧，协议解析效率低下，在此优化了高性能解析算法，比如可以减少分析的一个字节数，优化更多的一个匹配算法来提升解析的一个效率，与此同时，还使用了多线程、内存复用等工程手段来提升协议解析效率。
第四点：指标时间爆炸。所有的事件最终都会聚合为指标，链路和日志，其中指标一个块，由于别维度发散，比如接口会对存储的稳定性造成极大的影响，在这块支持在写指标的时候进行一个维度收敛，比如每维度的基数不得超过100，超过之将收敛成一个星号，代表一个通用的收敛的一个标记，与此同时，还在查询侧进行了一个优化，主要是做一个精度的降级。
3.统一个可观测交互界面
（1）统一个告警
EPS技术因为它无侵入性，以及多语言支持的的特性，使得开箱急用成为了可能，基于这样的一个事实，阿里云可观测团队开始构建统一个可观测的界面，首先是统一告警，接入阿里云eBPF监控，因为指标开箱即用，设计了一个套默认的告警模板，涵盖了应用层, K8s 管控层,基础设施层和云服务层，可以快速帮助发现问题，开箱即用的发现问题。
（2）统一个的关联分析逻辑
有了EBPF开箱即用的保存了现场数据，有了告警告诉系统现在有问题，如何统一进行关联分析，找到根因，需要有一个界面承载的一个关联分析逻辑，它应当是目标明确的，比如要解决容量规划问题，成本消耗问题还是应用性能问题，它应当是内容丰富的，包含解决问题所有需要的内容，比如指标、链路、日志、事件，问题的影响面、关联关系等等。它应当具备一个非常清晰的使用路径，能够回答当前是否有问题，未来是否有问题，问题的影响是什么，问题的根因是什么，能做什么，一个步步引导用户去解决问题。
（3）统一个 Grafana 大盘
基于以上逻辑推出了统一Grafana 大盘，他符合关联分析逻辑，无论是全局还是特定实体都有总览，能够发现问题。细节能够排查问题，它包含日志、事件、指标等多数据源，以告警异常阈值为驱动，整个大盘可以交互点击跳转，可以定位根音，涵盖了贴吧的集群最核心的资源类型。
（4）统一个拓扑图
推出了统一拓扑大图，它具备拓扑感知，依赖分析流量监控、上下文关联特性，可以按维度筛选出来节点和边，构建业务语义化的一个视图，接下来可以看基于EBPF的统一交互页面的一个演示。
先在容器服务ACK进入到一个集群之后，点击运维管理，进入到集群拓扑的一个功能页面，
他会如果没有安装 ebpf 探针的时候，提示安装，一旦安装了可以开箱即用的获得整集群的一个流量拓扑，可以看到一个workload的视图，它包含了deployment之间的一个流量关系，点击一个节点，可以看到它对外提供的一个七层的应用性能，比如对外提供的HP的响应时间，对于每一个节点，可以看它的上下游。通过上下游的查看，可以快速的去检查它是否是按照预定的一个架构去运行的，除了节点之外，边也可以点击来查看。比如from end，访问了服务，可以看到MYSQL的QPS以及一个响应时间，除了指标之外，还可以查看它的详情，比如SQL语句到底是什么以及它在网络上面的耗时，比如请求发到这端用了多久，对端处理用了多久，内容下载用了多久，可以快速帮定位到到底是服务端的问题还是一个网络问题，
同时可以快速过滤出自己感兴趣的一个节点，同时也可以搜索对应的节点。
第二交互界面，提供了 Grafana统一大盘，提供了一个1加N的盘。它包含了整集群最核心的资源的一个种类。
包含了事件，可以快速的看到各类事件的个数及他的一个详情，可以看到节点是否健康，无状态应用deploy是否健康，有状态应用还有The step said 等。
在每一个特定资源总览中，它的结构也是一个致性，主要分为总分的一个结构，总的话是对整个进行概括的总结，可以快速的通过这些值
看有没有问题，超过一个定值就是认为有，就会用鲜艳的颜色标出来。
比如这可以看到CPU请求率过高的一个节点数有一个，知道资源请求率过高会导致节点它是无法调度的，新进来的pod就会处于一个painting状态，通过总的可以看到有一个节点的CPU率是过高的，有五节点它的内存请求率是过高，比如哪一个节点的请求率过高时候就是下面的分应该要做的事情，通过请求率进行一个排序，就可以快速的找到节点，请求率是过高的。同时有五个内存请求率过高，也可以在内存请求率排序，也可以快速的找到五节点，是总分的一个逻辑。比如还有下面
这是eBPF采取到的七层的的一个应用的性能数据，这也可以看到请求数突变和响应时间突变认为它是一个异常的，把它总结出来，可以快速的看到有六个QPS，变化率是比较高的，也快速的找到这六个，有状态和守护技能也是一个的，可以看到整个集群级别。两个pod它是并不是ready状态，通过对face进行一个排序。可以快速的看到有两是处于一个pending状态的，同时也看到有15pod在过去24小时是具备重启的一个行为，所以在总览边可以快速的通过的一个总分的使用的一个排查逻辑，快速的找到有问题的。
继续以节点资源为例，假设看到node，现在是可以看到下面其实已经处于pending状态，知道pending状态就是因为请求率过高。假设是因为CPU判定，就来看节点它为什么请求高，点击可以看到它的CPU有一个请求率的一个top ten，可以看到有两个pod请求率是特别高的，可以点击查看详情，到系统资源面查看。
可以看到pod请求量是一核，但是它实际上只使用了0.01，所以请求量非常不合理的，他应该要降到比如0.1，可以释放出0.9给新的pod，使用也就可以被调度，可以看到具备交互能力，也是具备的逻辑，
除了一个交互可以看到是前端应用，它也是在每一个或者资源的详情页，它依旧是具备的一个排查逻辑的，首先在面也是一眼能看到有没有问题。比如管控层面没有问题、CPU没有问题、网络没有问题、内存也没有问题，可以看到它的调度有没有问题，如果有问题，可以快速的知道是谁有问题，并且在下面还继承了他的日志，以及它七层的一个应用性，全部都是基于EPS无侵入性，开箱即用的能力。
（5）总结与展望
基于技术阿里云可观测团队构建了统一个监控，无侵入式的提供多语言应用性能黄金指标。支持多种协议，结合管控层与网络系统层监控提供全站一个体式的可观测体验，通过流量拓扑链路资源的关系可进行一个关联分析，进一步提升在环境下排查问题的效率。
在未来阿里云可观测团队将进一个步挖掘EBPF全覆盖、无侵入、可编程的特性。在以下三方面持续发力，第一个点就是可扩展的 APM，简称 EAPM，主要是做无侵入式的多语言性能监控，第二点是无侵入式的分布式链路追踪，第三点是应用请求力度的系统与网络分析，主要是围绕着APM不断的去扩展它的边界，解决他需要侵入每种语言都需要单独买点的一个问题，解决在应用层面看不到的底层的黑盒问题。比如经常会碰到并不知道到底是代码问题还是系统问题还是网络问题。通过eBPF的一个全覆盖的能力，希望能够进一步扩展，第二块就是提供一些工具，包含traing proing包的dump以及内核事件在用户进行处理的一个开发框架进行优化，第三点就是EBPF增强的一些内置的指标链路和日志，主要还是应用协议更多的支持，高阶的系统指标，高阶的网络指标，通常看到CPU或者内存还有，IO些资源被占用比较高。但是很难回答他为什么高，通过eBPF的的一个无限的能力，希望提供一些更加高阶的指标，进一个步去回答一些问题。
六、基于 Elasticsearch 的指标可观测实践
首先会介绍Elasticsearch 对可观测场景的支持，会分享Elasticsearch 在存储指标数据遇到的痛点和挑战，接下来就会介绍Elasticsearch 存储指标数据，做了相关的优化，最后分享Elasticsearch 和PROMETHEUS 和 GRAFANA 的一个集成实践。
1、Elasticsearch 对可观测场景的支持
首先来看一个下Elasticsearch 对可观测场景的支持，Elasticsearch 就简称为ES，这张图是一个ELASTIC STACK的全貌。
Elastic是ES的所在的公司，是它所有产品的一个全貌，最底下是Deployed，目前整Elastic产品最常被用户使用的是以cloud的方式，公司自己在国外包括AWS和GCP上都部署了cloud的服务，在国内是跟阿里云和腾讯云合作，阿里云ES，包括腾讯ES也是以云的方式提供给用户去使用，另外两种是私有化的部署方式，一种是可以部署在K8S 上，另外一种是可以部署在物理机上是部署的方式中间层是软件层，被熟知的就是ELK，现在还有一个B，B就是 beats ，它是部署在节点上,就是去采集节点上的指标，包括日志的数据，log stash负责数据传输，它可以把beats 采集到的数据传输到ES上，ES就是负责存储数据，提供查询的能力，KIBANA 是一个可视化的系统，用户可以在 KIBANA 上很方便的查询到ES数据，做一些数据的探索分析之类的需求。在软件层次上，最上层是解决方案层。现在所能支持的主流的是三大解决方案，第一类是搜索，第二类是观测场，第三类是安全，所以可以看到观测场景是整ELASTIC STACK非常关键的一个解决方案。
具体来看一个下ELASTIC可观测场景的一个支持。
可观测场景所熟知的包括三方面，Tracing ,loggin和metris。Tracing 有一个APM 的服务是提供能力的，在loggin方面，ES最早为人熟知的就是EK的解决方案就是把ES用作日志的存储和分析。ES非常擅长做日志的处理的，ELASTIC的bit有一个叫me beat的方式，可以采集节点上节点上的指标数据，包括各种服务的一些指标数据，它能够很方便的把数据采集到ES，但是目前的ES在指标数据的存储方面就做的进入能力跟专业的TDB比，差距还是不小，所以也是开始去优化ES指标存储的一个初衷。
2、Elasticsearch 存储指标数据的挑战
ES做指标数据的存储主要有下面三痛点，首先是使用门槛高，是查询出的问题，查的慢，而且查询语句复杂，第三是成本方面的问题。下面的话就一个一个看。
（1）使用门槛过高
ES它定位是一个通用的搜索引擎，所以它的功能都比较通用，如果想用ES做持续场景的最佳时间，可以看到要做下面一个系列的优化手段，其中可以看到用到很多ES的一个些高级的特性，比如你要在mapping上做一个些更高级的配置，比如只存到DOC,还要用到ES一个叫index的功能，功能是在持续场景上是非常使用的，它可以让数据更好按持续的数据去存储，可以降低成本，提高查询性能，所以只有做了这些最佳实践，ES才会相比通用通用的索引来会有更好的优化，但是如果你用正常的TDB，直接创建一个库，一个表，就是时序场景的一种使用方式，ES是需要做最佳实践的。但即使做了些最佳实践，ES还是还是有很多缺陷。
（2）查询问题
首先来看一个下指标up的监控曲线的需求，需求对于 PromQL 直接传递一个up指标的关键字，就能查询到对应的数据。对于ES，可以看到右边是需要传递很长的一个DSL的查询语法，包括要使用quality的语法，还要用到agg的语法才能够查询到对应的数据。
再来看第二事例，按集群维度去查看EXQPS的监控曲线。
对于 PromQL 首先做一个能够获取到每索引的QPS，再做一个QBS，把它按集群维度去聚合计算，每集群的所有索引加起来的一个QBS就就能够满足需求，右边ED，可以看到他的aGG写的非常的复杂，而且面还用到了一个ES内部，AG是ES在协调节点，把数据节点的数据，在协调节点做二次运算，所以它需要数据节点传输很多的数据到节点上，所以的查询往往是非常的低效以及耗内存的，所以针对ES查询是非常低效的，但是也是持续场景非常通用的一个需求。
（3）成本方面问题
主要是存储容量方面的问题，存储介质方面，ES的冷热存储等的一些方式还是做的非常好，但是存储容量方面ES非常的不尽如人意。存储容量指的是存下同一份数据，ES需要消耗多少的容量，有一份DB给出了一个benchmark的数据，只列出了存储方面的一个对比，通过更多的数据对比，可以看到来源下面的链接地址，关键存储能量，一个FRDB存储了同一份数据，对比了储存储同一个份数据，可以看到ES用了1.8G，一个FRDB只用了155兆，ES的存储量是DB的12倍，即使ES做了像前面的最佳实践节省了400兆左右，但还是比一个FRDB高很多。也去做了的存储容量的对比，找到了一个份比较夸张的数据，是一个阿里云ES的监控数据，可以看到也是存储同的一份数据，ES 的存储容量是4300DB，整整74倍的存储能量的差距，可以看到ES如果去做指标数据的存储，面临着使用门槛过高、查询慢且复杂成本过大三个问题。
3、Elasticsearch 存储指标数据的优化
（1）降低使用门槛
首先先针对降低使用门槛，来看一个下ES包括阿里云做了哪些优化。首先ES社区提出了一个TSDS的概念，它的全称叫DATASTREAM。DATASTREAM是ES面对索引的一层封装，它主要解决的是ES索引无法无限膨胀以及案例数据过期的问题，具体TSDS它是怎去降低使用门槛的。
首先在配置ES的索引方面，TSDS它增加了一个index model=time series的一个配置。有了配置ES就知道索引是用来做场景，在引擎内部，它就能自动的完成很多持续场景的最佳实践，比如它先结合下面的，一个叫time sales和time两配置，两配置是告诉ES的哪些段用来做维度字段，哪些字段用来做指标字段。最底下有一个time step字段配置，配的上面应该是model等于其实字段就无需额外配置。他的索引会自动生成时间字段，所以知道了哪些是维度，哪些是指标，哪些是时间，它再结合model=time，就能够完成很多在持续场景的最佳时间，比如他用维度的字段去拼接成一个叫时间线ID的一个内部字段，用时间线ID和时间去做等的配置，都直接在内部自动给完成。中间还有一个配置叫SOURCE等于genetic等于true，
意思是配置了就可以让索引不存储source在ES面是一个明细，以及可以认为是一种可行的方式。因为在实际场景面都是针对列去操作的，所以没必要去存储原文，去增加很大的一个部分存储开销，设置之后就不再存储了sources，用户查询是不受影响的，因为是把所有列的字段直接拼装成让用户直接查询到，是在所以模板上做的一个配置，还有一个TSDS做了一个优化，就是一个时间分区上的一个优化。
普通的索引，它的时间是左边的方式，他的做法是所有的索引始终都会写在最新的索引上，可以看到图中的数据的时间是一个种乱序写入的方式，它是以时间从左到右向前写入，用户在写数据的时候，始终都写在当前的一个索引上，在ES 做完一个次就会生成一个新的索引，生成一个新的索引后所有的数据都开始往新的索引写，再做一层，新的数据又往新的作业上写，所以它的数据写入是都往新索引写的方式，存在的问题就是，它并不是以数据真实的时间出来做时间分区。做一个时间范围的查询需要在每一个索引上去，去判断索引上是否包含了时间范围内的数据。针对持续场景经常是基于一个时间范围去分去查询，所以 TSDS 做了一个针对性的优化，把索引支持设置一个叫 start time 和 end time 的一个字段，针对索引，它的数据只能写入start time 和 end time之间的数据。TSDS写判断时间，在哪一个时间范围内的索引上，去做针对性的写入。TSDS还有一个比较有特的事情是time并不是用户自己去制定的，而是在内自动生成的。
start time它是固定不变的，end time它不停的不停的去增加。直到数据索引要做一次就是要翻转成一个新的索引，他的end time才被确定下来。做的好处就是，比如有些所以固定的按天或者按月分格，但是实际上它的分布可能可能不是均匀，比如有的天所以很多或者或者一个可能一天的数据很少，也得给他创建一个索引，有了种弹性的种扩出的扩容的机制，它其实就是一个种按需的区域，把索引给做一个次翻转。有了，有了按具体时间去做，去做分区的索引。他在做时间时间范围的一个些分统查询的时候，如果桶明确的在某索引的 start time 和 end time 之间，它就只需要查询索引就行，其他索引是不会出现时间范围内的数据的。是TSDS做的一个事情。
来看阿里云ES timeSTRteam的服务。Time stream是基于TSDS，
再整合了阿里云内核的特性，去打造了一个持续场景的一个服务。它能够进一个步的再降低用户去使用ES做指标存储的一个成本。首先可以看一下它怎去使用的，如果你需要创建一个time索引。你只要去Put索引名字即可。就可以看到跟创建一个在TDB上创建一个库表很是很类似的。time streamam内部会把所有在ES在场景的最佳时间都直接集成。如果用户想做更高级别的一个些配置，就只要使用ES他的语法，去做更高级的配置，比如自定义数量，或者做一个些更高级的一个些筛选配置等等。用用户在正常的读写数据，就是跟ES原生的方式直接用索引的名称去做数据的put，包括它的摄区也好，是完全用原生的API。
他使用之所以能够做到简单的创建，主要是他内部直接指定了持续的模型。他指定以labels开头的作为指标维度，以METRICS 开头的作为，以labels开头的作为。作为维度的数据，以match开头的作为指标的数据，stamp就是时间段，所以用户的写入要按照数据模型去写，当是他是用内置的数据模型，用户有人在创建索引的时候，指定哪些字段要做label，哪些字段要做，只是如果你不指定，默认的就是用模型。所以可以看到通过time stream。极大的降低了用户使用ES做持续做指标存储的一个门槛。
（2）成本方面的优化
ES 主要是它的存储量过大。所以优化的核心目标就是降低ES存储同的数据它的实际的存储容量。要去降低的存储容量要对ES内部数据存储进行一个非常详细的分析。把阿里云ES之前看到份比1DB74倍的监控数据，做了一个很详细的一个数据分析。如下表格。
在default下可以看到ES当时可以看到是4300兆是它的原数据就占了3000兆，持续的数据占了1222兆。而做了最佳时间以存储容量降到了1945兆，原数据也占到了1155兆，持续的数据也占了780兆，细节的数据占比，只要是不跟用户相关的数据，比如每条记录写过来都会生成ID、number等的一些字段，列举出来的是一些占比比较高的一些字段的一些实际数据。可以看到在default场景下，最主要的占比是ID跟source，占到了60%，在最佳实践的情况下，ID source 48，其他各个指标数据的占比也很高，其中可以看到指标的存储容量，就要对ES内部数据存储进行一个非常详细的分析，就会考虑去针对性的去做优化，优化主要就分成下面两目标。
第一个目标是减少原数据的容量占比，因为原数据实际上是不会被用户使用到的，第二就是在指标指标场景上，能更好的提高压缩率来降低它的存储容量，针对目标主要是做了三个方式，第一个就是合成source，前面在设置中可以看到，可以不存储source，使用列式的数据，直接生成source，相当于直接减少了数据的存储，再合成ID，ID就直接使用时间线和时间戳作为唯一ID直接存储，ID的存储也不再需要。第三是指标的存储，以及有一些其他维度之类的字段也用到了叫ES一个劣势的数据。针对劣势的数据，在指标上发现这块做的并不够高效，所以这块的压缩发现，在ES这种持续可以把压缩率提高十倍以上。
来看一下做了优化的效果。首先看第三个柱状图。在做了一个压缩增强后，相比最佳实践存储容量从1900兆下降到1126兆，大概下降到八百多兆，再看第四曲阵，就是在做了一个ID和source的生成之后，它的存储容量再进一步的降低近800兆，从1126降到了288兆。288兆还有100多兆其实是由另外一个元素second number的一个元数据，也还在优化中。所以可以看到经过了压缩以及和原数据存储的优化、ES存储成本已经非常接近EBRGB，在有些数据场景上已经能够做到，甚至比EBRGB空间更小，右边可以看到ACK已经比ES大很多，做了存储容量优化明细的结果
数据还是104兆，下面一个明细可以看到，做压缩指标数据的占比直接从27%降到了百分之一点多，主要也是使用的DSTD的压缩算法，在持续的指标存储上可以有非常明显的效果，合成source方面，ID和source占比就直接降成了零，也可以再额外说明为什么对原数据的占比非常高，持续的数据本身它是非常有规律的，但是源数据它生成的唯一个ID，以及他把所有的明细数据都存下来，相比指标数据它会导致存储的空间非常高，也是为什么现在ES去存指标数据，它会占用多的空间。数据方面的优化也是非常关键的，number还有100多兆，number是自增的，但它的存储并不是完全按照自增的顺序去存储，所以它相比持续的数据，它的空间占比也是比较大的。
关于存储成本的另一个优化是DownSample方面的优化。
主要作用是它能够降低数据的精度，来达到存储的空间更小，查询更快的效果。比如原始数据，假如是一分钟的精度，如果你把它当一个60分钟经度的数据，它的精度少了60倍，但它相对应的存储容量也基本上会下降将近60倍左右，因为存储量下降，在查询小量数据的时候，它的查询性能也会高效，同时由于它存储能量降下来，所以针对种粗精度的数据可以用更长的保存周期，比如以上图设计，在创建索引的时候，直接可以指定精度，假设原始数据的精度是20秒一个精度，为它配置了三种精度，一种是一分钟，一种是十分钟，一种是60分钟，当原始数据在写入的时候，内部就会自动生成三种精度索引，可以针对不同进度的索引，配置不同的规则。比如原始索引可能三天就过期，一分钟精度保存七天，十分钟精度可保存一个月，60分钟精度保存一年等。就可以看到更长远的数据，同时因为它做了DownSample，它的存储空间也会有降低，是写入册的，查询对用户也是完全透明的，用户还是按照原始索引的正常去查询，在ES的内部会根据查询语句中的interval参数，类似于Prometheus的step。根据不同的interval，实际查询到的数据 ES 内部是会有一个选择的，他会选择当前最初精度能满足的索引，比如你设置是60分钟或者120分钟，用户查询的虽是原始索引，但是实际上它转到的是一个60分钟精度的索引，它的查询性能也会有一个极大的提升，所以可以看到time stream是内部的，把写入和查询的细节全部，全部被用户给屏蔽了，有一份阿里云ES监控数据的一个查询性能对比，可以看到ES如果查询到了DownSample的索引，它的查询性能是有一个质的提升，列举了四点，也跟CK等做一个对比。
可以看到，ES的表现都比DB好，有的场景会比CK好。
（3）指标查询的优化
ES去存储指标数据，有两个最关键的问题，一个就是存储能量过大的问题，另一类就是查询数据的问题。在指标数据查询里面，经常有下面一个case，图中一条条的线可以认为是时间线，针对查询，很多时候一般是首先把一个时间窗口内的数据做指标参数，会把窗口内的一条线上的所有点汇聚成一个点，接下来针对每条线上的点去做一个AGG，是时区场景非常通用的一种查询。可以用下面的PromQL直接去解释出来，对于ES来，ES它做的一个普通的AGG，它只能针对一个窗口类的数据做运算，比如框里面有很多点，它无法区分些点来自于哪些时间线，它最多只能把些点的数据做一次运算，比如你做一次，他是把框内的所有点一起算，他无法先做一次，当按每个时间先做一个点，再对点去做一次，ES要完成需求，他必须得借助一个比较高级的APP方式，再协调几点去运算，针对需求，如果在其他节点上，就会存在变成消耗内存以及性能低效的问题。首先他只能在数据节点做DownSample的操作。比如把每个点的数据算一个date出来，得把所有时间线的数据全部传输到协调节点，在协调节点完成AGG的功能。
中间如果时间线数据很多，传输的数据以及协调节点的数据量是非常大的，所以ES做这个它的性能是非常的低下的，ID越多性能越差。针对持续的索引引入了一个新的AGG，会传递很多的参数，会传递DownSample参数，能够传递gator的参数，还有group 之类的，在数据节点直接去做一个二次运算，再协调节点只要基于算好的结果再做一次聚合即可，是能够满足查询需求的，它的性能也相比用其他方式高效非常多，实际测下来可能会有十倍以上的性能提升，但是可以看到首先用起来非常复杂，它需要传递很多的参数，其次，只是一个简单的，如果你要做一些更高级的运算，比如多指标之间的一些二元运算，其实是非常难以完成的，想靠ES本身的DSL语法也是非常难以描述，指标优化最终极的方式是支持PromQL
（4）支持PromQL
在内部就直接支持了PromQL，下面来看一下相关的实践。
4、Elasticsearch+Prometheus+Grafana 实践
阿里云 Elasticsearch TimeStream 对 Prometheus 支持情况。
首先，TimeStream 支持了 Prometheus 跨越相关的所有API，包括query、query_range以及一些数据的接口。对PromQL的支持度是目前的效果，在语法方面Select operator function以及全部的二元运算符目前都支持了。some quality和join是一个代字词的状态，在aviation operator上面，目前常用的operator都能够支持，还有STDDV和STDVR两个算子支持，function方面也支持，常用的function支持到了40条，其他的也都在支持中，一个目前对 Prometheus 的一个支持情况。比如API支持，所以ES跟Prometheus与Grafana整合方式就可以是下面这张图。
首先，Prometheus采集exporter上的数据，可以通过exporter right的方式直接把数据写到ES，在Gragana上，直接配置source，它的地址选择的是es time 地址，就能像访问Prometheus去访问es，达到整合效果。如下示例图
示例图是在配置source的时候用的是Prometheus，但是在配的时候用的并不是Prometheus的地址，而是一个ES的地址。所以官方实际访问数据是ES的数据，配置了data source
就直接用Prometheus的方式，用Prometheus访问es的指标的数据，访问Exporter导入到数据，也只要直接把exporter对应的导入到大盘直接查看即可
上图可以看到es现在对复杂的Prometheus也是能够很完善的支持的，就是ES跟Prometheus、Grafana与官方整合的一个使用事例。
