开发者学堂课程【阿里云可观测峰会：开源全场】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/1060/detail/15342
开源全场
内容介绍：
一、基于 OPLG 从0到1一构建统一可观测平台实践
二、Prometheus & Grafana :开放、可组合的可观测
三、阿里云 Grafana 服务的产品演示
四、Observability with Prometheus and beyond
五、基于 eBFF的Kubernetes 可观测最佳实践
六、基于 Elasticsearch 的指标可观测实践
一、基于 OPLG 从0到1一构建统一可观测平台实践
基于 OPLG 从0到1一构建统一可观测平台实践，可观测是近几年比较火的议题，OPLG 就是指包含了OpenTelemetry、Prometheus、Loki 和 Grafana在内的可观测的开源技术合集。
2016年，加入到阿里巴巴中间件EagleEye团队，EagleEye是国内最早的一批自研的链路追踪系统，得益于阿里巴巴内部的中间件微服务框架统一，它在短短的几年之内就接入了阿里内部超过98%的java应用。在开发EagleEye的几年过程中，逐渐的意识到链路追踪的目的是为了保障系统的稳定性，但是保障业务稳定性的手段不仅仅只是依靠链路追踪，还要和其他的可观测技术或者管控系统相结合。因此在2019年就发起了GitHub的稳定性项目，叫做StabilityGuide，希望能够一起沉淀交流在可观测和稳定性领域的一些知识。目前项目已经有了2000多的star。在2021年回归到了arms团队，参与arms的开发与设计。arms是一款为云上用户提供从业务层到应用层再到云组建和基础设施的全站可观测产品，今天分享的议题是围绕着OPLG在arms的落地实践，穿插着自己对观测基础的理解。
1.应用架构与可观测技术演进历程
在软件开发的早期，单体应用架构因为其结构简单，便于测试和部署，得到了广泛应用。而相对应的监控诊断技术主要就是基于日志和日志关键词的指标监控。随着软件复杂度不断的提升，单体应用架构也逐步的向分布式和微服务的架构引进，而整体的调度环境也越来越复杂。日志和指标很难快速定位在复杂环境下的问题，链路追踪技术也就应运而生。但是早期的链路追踪技术，它和日志指标的结合比较简单，更多的是在应用一层以APM软件的形式存在。随着云计算和云原生理念的普及，从业务层到应用层，容器和基础设施，之间的边界在不断的被打破，研发、运维、安全等职责也不断的模糊，全站可观测的诉求越来越强烈，Traces、 Metrics和logs的连接也越来越紧密。
2.一个典型的云原生架构及可观测的诉求
如上图所示，典型的云原生架构可能是一个混合云的形态，出于安全或者是容灾等方面的考虑，可能将一部分的应用部署在公有云，另一部分部署在自建机房。出于软件研发效率和性能的考虑，不同的应用有可能采用多种多样的开发语言，因此整个的可观测诉求可以被归纳为以下四点，第一点是全站的立体化的统一的监控与告警，比如可以像业务层的一些交易量，支付量的一些业务指标和应用的一些黄金三指标，耗时、错误、请求数，包括基础设施的一些CPU利用率，还有网络的一些情况，放在一张大盘上做总体的监控，比如大促等期间也是比较常用的，第二可能需要前后端多语言全链路追踪的能力，用户请求从端上发起，一直到网关到后端的应用和一些云组件之间的调用和轨迹的追踪，可以帮助很快速的去定位用户请求在哪里有异常，在哪里会比较卡顿。第三可能需要将不同类型的数据，不同环境的数据进行统一的可视化，就需要有比较强的可视化的组建。第四是可能出于业务的一些定义的需求，需要有一些arms的加工与分析，如果能够基于开源的数据格式标准，很多工作做起来比较轻松，也可以去复用很多现有的东西。以上四点可观测诉求，其实是过往接触的很多用户反馈提炼出来的共性的需求。
3.为什么要基于OPLG构建统一可观测平台
（1）传统的监控诊断平台的痛点
第一是以前很多买点，插装的实现都是自己去做，闭源的实现会导致的数据格式不统一，而且买点在各系统之间也很难去复用，接入的成本非常高。
其次之前很多指标都是孤立的分散在各监控的子系统，比如有的在网络，有的在应用，有的在容器，分散的指标对于去排查全连读问题，对开发使用人员的经验要求非常高，但是效率非常低。
其次是Traces会由于各子系统之间的一些隔离，可能会无法串联，可能因为买点覆盖度不够，或者协议不统一，就导致经常会出现断裂的情况。
日志或者链路数据的明细数据全量上报到服务端，也会带来非常高的成本，而且查询率比较低，还会引发热点的性能瓶颈。
之前的控制台是自己搭建，它对前端的要求比较高，每一个新的一些视图都需要前端的介入开发，周期很长，灵活性也比较差，很难跟上业务迭代的效率。
最后是各类型的可观测数据，各系统的可观测数据，之间缺乏统一的标签管理能够，他们之间的关联性比较差，很难做综合性的分析。
为了解决上述些问题，在生产环境中逐渐沉淀下一个比较可行的方案，就是基于OPLG去建设的统一观测平台。
方案主要有以下几点优势：
第一是开源开放，因为都是基于全开源的技术，可以借助社区的共建的一些合力，比如可以借助(O)penTelemetry Traces、(P)rometheus Metrics、(L)oki Logs通过(G)rafana Dashboards进行统一展示
,不需要过多的开发，就已经能够保障很多大部分通用组件的数据能够采集、生成、上报，降低了接入的成本。
其次，因为都是开源，基于统一的一套规范，就可以很轻松的实现内部各子系统，甚至是和外部三方系统之间的打通和管理分析。
其次，基于OPLG，特别是Grafana的一些比较好的设计，可以非常灵活的组织可客观测数据，能够灵活的定制出自己在每一个场景想要的一些图表，满足自定义的一些需求。
最后是最近几年逐渐比较火起来的open Telemetry collector的技术，它可以将在可观测很多的数据的计算处理，后包括一些临时的存储，左移到用户集群之内，通过样边缘计算的技术，能够提前去提炼的数据价值，将提炼好的数据再发送到服务端，降低整个公网传输的成本，以及服务端的存储的成本。
4.基于OPLG构建云原生可观测方案平台
主要有以下四模块，第一是端测的数据的生成与上报，通过openTelemetry来完成数据的一些生成，而通过Prometheus来完成很多指标类的数据，比如的note export 、MySQL export等等，而日志采用Loki方案，所有数据采集完成之后，可以通过openTelemetry collector来完成数据的统一的边缘处理和路由转发，服务端建议采用托管的服务端，因为托管的服务端它能够提供一个更好的性能、更稳定的服务，而且也不会绑定的技术站，迁移的自由度、灵活度也会很高。
最后在可视化的选择也比较多，首先可以通过Ｇｒａｆａｎａ完成统一的自定义的灵活监控，也可以采用云服务商，比如arms在一些特定的一些精细化交互场景提供的一些精细化的交互大盘，来提高的查询的体验。最后是如果实在有一些自己的需求，也可以通过开源的数据格式，或者是开放的open API来建设自己的控制台。
5.基于Open Telemetry Collector实现统一数据采集与边缘计算
首先是open Telemetry，它其实是可以首先完成统一的数据采集，无论是哪种数据类型，或者是推拉哪种模式，或者是展自于不同的数据源，都可以先把数据全部采集过来，采集过来之后可以去做一些通用的处理，比如格式、数据的标签打标，其次还可以做一些明细转指标的预计活动作。最常见的比如调用链，可以根据的service IP等力度，先把数据聚合好，再进行采样，就可以保证指标的精准度，而且上传到服务端的明细数据也可以降低成本。最后Open Telemetry Collector，它还可以承载本地存储的能力，如果具备了本地存储，就可以把一部分最近的一批数据先临时缓存处，比如最近全量查询，或者是链路的维采，比如错慢全采，就可以更好的利用的边缘的存储能力。经过处理好的数据，Open Telemetry Collector也支持非常灵活的转发的方式，比如可以支持不同的协议，Prometheus协议等等，也可以支持多数据源的转发，可以将一部分的数据发送到的云服务端，也可以转存到的边缘的存储，就会更加的灵活。
6.基于ARMS托管服务端提供快速、稳定的查询体验
托管服务端是建议采用就是云服务商，比如ARMS，在服务端就针对海量的数据场景，做了很多查询性能优化加速的一些技术，比如指标，通过算子下推的方式，在70%以上的场景下，查询性能相对于开源就提升了十倍以上，而针对七到十天等长周期的查询，通过降采样的技术，又进一步的提升了数量级的查询性能。针对一些URL等发散的一些维度，通过自动收敛的技术，很好的去解决了热点导致的查询卡顿的问题，比如针对链路数据，也做了应用和Traces路由扫描，因为最常用的就是根据一些各种各样的条件过滤出想要的调用链，再根据调用链去进一步查询链路详情，针对一些链路的查询的使用的特征，去做了相应的优化。除了海量数据的查询性能优化之外，在HA也做了体系化的一些建设，比如默认可以支持全球部署多可用区容灾，就避免了单Region或者是AZ不可用带来的一些风险。其次，业务经常会遇到一些突发的流量或者用户快速增长，如果是自建机房，就需要考虑相应一些容量的问题，但是使用arms，就可以根据流量自适应的做扩容，不用担心种突发流量带来的一些性能的瓶颈。如果在一些极端的情况下，也可以通过动态配置，一些下推或者是一些自动的流控降级来去保障核心功能的可能性。最后提供了全链路的SLO的监控和预警的建设，有七*24小时的应急响应，可以及时的发现可用性的一些问题，并且快速的恢复。
7.基于Grafana + ARMS构建灵活、精细的可视化界面
首先基于Grafana的丰富的仪表盘的插件和广泛的数据源支持，就可以将各种各样的数据都集中在的大盘里面，而且通过PromQL，LogQL灵活的查询语法，根本不需要前端来介入，自己的后端的研发、测试、SRE等等，都可以通过低代码的形式快速的去构建自己想要的一些场景的大盘，来提升可观测的效率。最后因为Grafama是开源的，如果想从自建机房迁到云上，或者是想从这个云迁到另外一个人云，整个可视化都能够通过阶层文件或者是其他的方式，能够快速的拷贝，轻松的完成端到端的迁移，不会被特定的厂商去做强绑定。但是Grafana它也有一些缺陷，比如他在交互的场景的体验就做的不够好，因此ARMS就在像调链的一些关联分析，在线诊断，配置管理等强交互的场景，提供了一些更精细化的交互页面。ARMS还会去进一步的增强Grafana一些图表插件，甚至是提供一些新的图表插件来去提升托管版Grafana可视化的能力。
8.基于OPLG + ARMS从0到1构建可观测平台实操演示
（1）基于Open Telemetry+ARMS的全链路追踪与应用诊断
首先如何基于open Telemetry 和arms来实现的全链路的追踪和应用诊断。打开arms的控制台，选择接入中心
在里找到open Telemetry 的接入方式，也可以选择其他的接入方式。
后以Java应用为例
在里可以通过OT java agent，生成数据，修改启动参数，比如接入点或者是健全的一些token。除了直接上报之外，也可以通过OT collector来完成的数据转发，就是可以实现无损统计，就是只需要将enter point改成本地的服务。当安装完成之后，可以通过arms提供的trace Explorer页面来进行调链的分析
因为调练的分析是强交互场景，可以通过左侧的快捷筛选，快速的过滤出异常的链路
选择其中一条链路，就能看到段落端的全链路的轨迹。arms在java场景，还去针对接口力度做了更详细的本地方法站的买点，能够去更好的定位更音，在右侧可以看到当前span相关联的一些附加信息，包括相对应的一些GM和主机的一些监控指标。
最后是跟span相关的一些应用日志也能够很快速的集成，排查一些业务问题，可以结合的日志来更好的去定位。trace explore它除了调用令的查询之外，它也可以去做一实时的、动态的分析，比如可以看异常的链路是否集中在某一特定的IP，是否存在单击故障的可能性，或者是否集中在一些特定的接口，也有可能比如新上线了一个接口，是不是看它集中在一些特定的接口。也可以去把很多的调用链进行全链路的聚合，单一的链路的分支可能看不到，但是多条调用链的就可以看到每一分支的情况。也可以去看到应用维度的更直观的拓扑。
除了链路的查询分析之外，Arms还针对Java提供了一些比较好的交互的图表，比如除了JVM监控，主机监控等基础的监控之外，还可以将容器的pod监控集成进来，也可以将石化监控就是线程池监控，特别是在一些业务高峰期间，很容易就出现tomcat或者数据库连接打满的情况，以往问题都很难排查，但是有了迟化监控，就可以一眼就定位到是否存在连接值打满的问题。
通过上下游的一些分析，也能够很轻松的知道当前应用的一些调用方的情况。
而在数据库调用里面，可以看到SQL的一些明细的统计，以及类似于noSQL缓存的一些操作的情况。ARMS还提供了一些高阶的诊断能力，
比如线程分析，它就可以针对每一类线程池去观察一类线程消耗的一些CPU的耗时以及线程数，还可以去看它的方法站。如果捕获的有blocket等，就可以去重点的去看一下，针对Java应用的一些疑难的问题，还可以通过白屏化的阿尔萨斯诊断去实时的抓取捕获GM运行态的一些数据，比如方法执行号时就可以去查看方法的调用的轨迹，包括它的出入参数。
除了arms提供的预制图表之外，还会将APM的指标数据写到Prometheus
通过Grafana做展示，就可以通过Pro KL去定制自己想要的APM大盘。也可以将APM的数据和其他的指标数据，比如业务的、基础设施的，还有云组件的，比如数据库服务端的，容器的等等放在一起来去定制自己想要的大盘的形态。
可以选择任意的一数据源。
（2）Prometheus+Grafana统一监控与告警
在接入中心首先选择要接入的一些组件，比如有MYSQL、ES等等，可以默认的支持阿里云上的很多的组件。
以MySQL为例，首先要选择接入的实例，比如是K8S的实例，填写export的名称，选择相应的地址，如果是在阿里云环境，就可以直接去勾选，再写入相应的用户密码就可以，同时也可以去看一下当前exporter去采集的一些指标。如果相应实例还没有接入，也可以选择新建实例，比如针对ECS的环境或者自建机房
也可以去通过下载ARMS提供的helm来去安装的Prometheus agent。或者也可以通过remote right的方式直接的上报数据。如果在多地域，把多地域的数据源放在一起
也可以通过global view的种全局聚合实力来去把多部数据进行统一的展示。查看已经安装完成的DEMO的实例，点击进入集成中心之后，可以看到当前实例已经安装的一些组件，比如容器服务，就可以看到组件它采集的一些指标，还可以去更精细化的去选择哪些指标需要采集，哪些指标不需要采集，
在大盘列表里面，Arms也提供了很非常多的预制的Grafana大盘，比如K8s的一些总览的视图，或者是note详情的一些视图
可以看到当前节点各种各样的一些状态，也可以自己去编辑，基于视图自己编辑新的一些图表。
看完监控之后看一下告警，因为数据都写到Prometheus，所以告警也都是可以基于Pro KL扩展，默认提供了很多告警模板
比如节点的CPU使用率，通过Pro KL来修改一下，在这里把阈值调低一点来去观察预览的效果，告警除了可以定制告警的内容，还可以去选择一些通知策略，比如不同的告警发给不同的值班的同学。
看完告警和监控值，再来看一下Grafana。Arms提供了两种类型的Grafana，一个是共享的版本，一个是托管的独占版本，更推荐开通独占的托管版本，因为可以去做一些自己的自定义的账号的管理。因为是独立实力，还可以去更好的，有一个可用性和安全性的保障。基于Prometheus和Granafa就可以很轻松的去完成不同类型的数据指标的统一的监控和管理。
（3）基于loki的日志查询分析
由于ARMS目前还没有提供商业化的服务，以官网的Grafana示例来简单的演示一下loki的接入的效果。
当完成日志的接入之后，可以基于loki提供的logQL去快速的过滤，loki除了全文的grape的查询之外，它还针对一些关键的索引字段去建立了一些索引，基于这些字段，可以进一步的提升检索的速度，基于logQL，还可以定制一些就形态比较丰富的图表，比如官网提供了lock engines的大盘，
统计的一些数值，或者是地域的分布，都可以通过loki的logQL来定制出来，还是比较灵活的。
ARMS特有的一些可观测的能力。
（4）基于RASP的应用安全防护
RASP的应用安全防护，它在里也是两个能力，第一是微型组件的检测
当应用接入RASP之后，就可以去自动的根据CVE的一些标准去扫描出当前应用是否存在一些危险组件，比如之前一段时间比较热门的安全漏洞，就可以快速的去提示当前应用可能有风险
查看有实体详情和漏洞详情，就可以看到它具体的漏洞描述，以及相应的修复方案。
根据修复方案，就可以去自助的完成漏洞的修复，除了已知的危险组件之外，也可以基于一些未知的、还未上报的或者是自己的一些特有的组件，做全量的组件自查。应用安全的攻击的防护。
首先模拟恶意的DNS的查询，模拟一下相应的攻击的状态。
可以看到，自动的识别出当前有恶意攻击行为，并且能看到行为是在哪个节点上发生的，它的请求的一些参数，以及调用的攻击的堆栈的情况。除了攻击的识别之外，还可以去做主动的防护，可以将防护的模式从监控设置为监控并且阻断。修改完成之后，再来模拟一次攻击行为，刷新一下页面
最新的一次攻击行为，不仅仅是监控，并且把它直接进行了阻断，就不会真正的影响业务的一些具体的逻辑，同时抛出了异常
当前风险的一些行为已经被阻断了
（5）用户体验监控
在接入中心，可以针对不同类型的端测设备来进行监控。比如以外部端为例，可以新建站点，选择相应的配置，通过一些CDN或者是NPN包的方式来完成接入。
当接入完成之后，可以看到当前控制台相应的一些PV和UV以及API的一些请求的成功率，并且可以看到请求是分布在哪些地理位置上，或者是运营商或者是浏览器，举一个典型的场景，比如新开发了个功能页面，可以看页面TOP20的一些用户访问的情况，选择具体的用户，还可以看到通过绘画追踪来看用户到底是如何使用产品，就能够去更好观测用户的行为。应用监控前端监控还可以跟播测结合使用，可以通过拨测模拟真实的用户行为，可以对网站的一些网站质量，网页性能，软件下载或者是API的性能去做模拟，可以提前的去发现一些问题，幸运用户去感知到可能存在的一些风险，针对不同的站点，当发现比如可能性出现了一些异常的时候，就可以自动发通知。
查看已经创建的DEMO的任务
在这里能够观测到的一些网站的时延、丢包率，以及每一次播测的状态和结果
通过多维的报告，可以看到时延的问题聚焦在哪些地区等。通过几个DEMO演示了如何通过OPLG和arms来构建可观测平台。虽然OPLG并不能覆盖所有的可观测领域，但是它提供了一个非常良好的底座和规范。在这套体系之下，可以不断地将其他的可观测技术或者产品能力集成起来，来满足在各种场景的一些可观测诉求，从而应对愈加复杂多变的环境的挑战。
9.云原生时代可观测技术的趋势和技术选型
在软件架构层面，软件未来可能会更多的向分布式云和混合云运动方向发展，同时容器化、微服务、DevOps也将逐渐成为主流，而相应的可观测技术趋势有以下几点，第一是标准逐渐成型收敛。首先技术站可能更多地会向openTelemetry、Prometheus等方向去收敛，而基于更加标准的数据使得自动化的成本更低、效率更高，其次分层之间的监控边界被打破之后，监控立体化也越来越成熟。第二点是基于eBPF的网络和内核的无侵入探测也带来更多的可观测技术的可能性。最后是去中心化的趋势，分为两点，第一是数据去中心化，比如基于open Telemetry collector，可以将很多可观测的预处理左移到用户集群之内，降低中心化服务端的压力。第二是协同去中心化，可能不仅仅在统一的控制台去查看可观测数据，可能在及时通讯软件，比如钉钉就完成了整个协作的过程。
