云原生技术实践训练营：课时1：云原生可观测最佳实践
云原生可观测最佳实践
内容介绍
一、云原生下的可观测挑战
二、可观测挑战应对策略
三、可观测最佳实践
四、客户案例
五、产品试用
一、云原生下的可观测挑战
在课堂里面的时候，老师可能会更多的教我们怎么样把一个软件给开发出来，但是，针对这个软件它开发出来之后，他可能要在线上，他要跑个3~5年，那怎么样让他能够跑得更加稳定，或者让他跑的更好，这其实就是可观测它专注的一个方向。
所以通过这些章节来分享一下我的一些理解。在现在的一个云原生的时代下，他可能会对于这样一个可观测的一些挑战，以及一些应对策略，一些解决方案，以及是在阿里云内部，服务云上客户的一些最佳实践等，最后会有一些客户案例。
先看一下可观测挑战，除了右边所提到的那些问题之外，针对左边的一些最新的一个关键字来介绍一下，他为什么会对可观测产生一个挑战。
首先从系统架构来讲的话，我们近几年的一些云原生发展带来的变化是什么呢？
最早的可能是做一个单体应用，他可能就是一个进程跑在哪个服务器上，然后逐渐会去对他做一些分层拆解，会对它做一个三层的架构，以及现在可能会通过微服务的架构方式去改造它。随之而来带来就是需要观测的对象变得越来越多，并且微服务他可能会有很多语言开发。那么在这种不同语言开发实现下的一个可观测记录标准是什么？这都是一个问题，可能在单体的时候会通过，如果说它现在发生问题了，我们会通过一个对战、报错，去看到问题出在哪一行。但在微服务的这样一个架构下面的话，这个问题会变得非常复杂。怎么样去定位有问题的那个关键代码，基础设施其实它影响的是一个资源供给的方式。那么最早可能会自己去采购一批服务器，然后会把它放在一个数据中心里边，后面可能会把它放到托管机房，以及现在我们会通过云上的这些云产品来提供计算资源、网络资源和存储资源。那么突然这些资源不再掌握在自己手中了，我针对云上那些产品，我怎么对他去做监控？以及在开发模式这一块，最早可能会通过一个瀑布式的一个方式去做开发，这个在软件工程的这种课堂上课程老师会讲到。那么慢慢的我们会把一个大瀑布把它拆成一个小瀑布，就是敏捷的一个模式。以及是现在会把它拍的更平，会通过一个DevOps这样一个组织架构来实现。那么在部署模式，最早就是会把这个程序直接跑在一个物理服务器上，以及后面会通过一些虚拟化技术，会有各种虚拟机来实现一些资源的弹性的伸缩，那么现在把它跑在容器上，那么容器上就意味着呃这个东西它其实是一个非常敏态的一个东西。也就是很有可能我今天我到了情绪发生问题的时候，我按照传统的方式，我想登到服务器上去看一看问题是什么。结果，容器它可能就重建了，或者它没了，那这个问题怎么去重新定位？
运维模式，它其实本身不是一个问题。他本身是为了解决上面的这些复杂度应运而生的。从最早的通过命令的操作，到现在工具运维，到平台运维，一直到AIOps，他是为了解决上面这些问题的。DevOps也需要提一下，DevOps这种情况，也就意味着业务的迭代更加敏捷了，那么在这种发展节奏情况下，怎么样能够在尽可能在用户发现问题之前，我们就能够去看到问题，并且把问题给修复呢？而且随着DevOps，可能会自己建立一套CICD的流水线。那么，这个CICD流水线，怎么针对他的一些指标。比如构建的成功率、部署的成功率、正常去做监控，也就是所谓的可观测左移的一个问题。这也是现在看到的一些挑战和一个痛点。
那么这边也做了一些行业的调研。在一些行业调研的问题里，其实有三组都是和可观测相关。那么针对用户所关心的在原生化的一个过程当中，有哪一些是他们比较关心的问题呢？可以看到，针对业务的一些痛点。用户提出当微服务化之后，对分布式系统缺乏统一的监控告警和客观测能力，不能提前感觉到业务风险。
对于希望在哪些方面能够对微服务架构进行一个增强，用户提出了一个全链路监控，关于运行态稳定性其实也是跟可观测相关的。
当前基础设施层的一个可观的现状，从这张图里面可以看到，在调研的这些用户受众里，监控的能力建设是比较薄弱的。
二、可观测挑战应对策略
前面提到这些挑战在近几年通过一些基础数据、通过开源数据、自身的一个努力和建设也是慢慢的在提出他们一些思路。
比如现在可以看到针对指标的话，现在在博客上面，在网站上面去搜索关键字，搜索监控或者云原生监控。它可能第一页里面必然会包含普罗米修斯这样一个解决方案，普罗米修斯是属于我们这个在整个数据、一个云原生指标监控告警的一个事实的标准。以及是它提供了一个灵活的服务发现机制能够去处理，现在我们云原生环境里边我需要观测的对象，他稍纵即逝，他非常灵活的发现的问题。以及是它本身这个社区里边提供了很多的已有的开箱即用的Exporter，比如可以常见的一些Exporter、Kafka Exporter等。能够直接来实现对这些组件的监控的接入。以及OT，它是属于一个后起之秀,它其实建立在普罗米修斯的一部分的标准的基础工作之上，比如指标这都是属于普罗米修斯，也就是Open Telemetry规范了一个超级，但它同时也提供了像链路、日志的数据的stack定义、SDK的实现，以及包括提供了很多主流语言的覆盖，比如JAVA、RUST等。它其实还提供了OG collect的工具，这个工具能够在用户如果说有对他这个可观测数据管道有一个灵活的定义的诉求的情况下，可以通过这个工具来实现一些ETO的任务。
也就是Grafara，如果说我们大家去搜索关键字,搜索指标，需要希望有一张大盘的时候，那么必然会出现Grafara的工具，Grafara是属于社区对于那些可观测数据，也就是对于指标log的可视化的事实的标准，它本身提供了很多这个丰富的一些大盘。也就是我本身在工作当中的话，我发现它现有的大盘都是满足我开发使用的需要，不需要再去自己去定制一些插件。
那么它本身就是对于各种可观测数据的一些传统后端，比如ES、普罗米修斯等，这些是提供开箱即用的支持的。
三、可观测最佳实践
在阿里云，会通过哪一些最佳实践来支撑起服务客户可观测的过程？首先来这边有一个引子。在现在云上典型的应用的架构是长什么样？比如说它现在是一个电商网站，这些电商网站把它做一个分层。这个分层，从最下面看到就是基础架构，也就是在IaaS那一层，它提供了常见的一些计算的资源、网络资源和存储的资源。再往上就到Paas这一层，这一层可以看到有很多云产品，会提供一些数据库的服务，中间链的服务、消息队列等。
容器服务ACK、ASK也是在这一层，在往上可以看到有很多通过各种语言开发的这些应用。以及是在往上终端也就是面向用户那一端，会有各种的用户的小程序或者PC Web网站，或者是iOS，安卓的APP等。架构的分层，其实谈到云原生不管引不引入这个容器技术，但它分层思路还是不变的，还是这个结构。
所以，在这样的旗下，可观测整体的一个设计思路是：监控还是可观的标准的基础，需要去梳理一个监控指标体系的原则。需要分层设计，自上而下的去设计。一个运维的体系做的好不好，可以通过告警测来发现。也就是今天如指标体系数据不ok，或者监控告警配的不合理，会造成大量无效的告警，给值班人带来一个很大的困扰。我们也提倡通过聊天工具，钉钉等这些软件来完成整体的运维事件的闭环。效果能够实现对于运维告警体系的数字化管理在后面也会有例子能够体现出来。这个指标，它其实是告诉我们系统有没有问题，但是它不能回答今天系统为什么会有问题。所以必须得引入像链路、日志这一类数据来做一个辅助的定位。为什么主次关系是链路为主，日志为辅？因为在一个微服务系统里面，它很复杂，但是不能通过选举去输入一个比如关键字我就能知道今天问题到底出在哪里。所以，要做一个更新定位的话呢，一般会习惯通过chance数据先去看看问题出现在哪一跳。比如出现在微服务提供的API接口里边，那么就去针对这一跳，去看它提供API的模块的日志，然后去找到跟因，去找到问题的定位的原因。整个云原生的技术是建立在开源社区的基础之上，所以是通过拥抱开源标准的优先的方式来建设的客观测体系。
具体有哪些指标，是通过生命周期的方式来展现，首先在资源层，可以看到所常见的就是CPU内存、使用量等。包括网络IO、磁盘空间。容器这一层会去关注容器里边工作负载资源。
比如会关注Deployment，会去关注Pod的健康度等。那么也会去关注控制面的一些指标。如果今天不是自建的APIS，前面使用的是ACK，使用它的托管板。那么这个APIS的组件属于直接由阿里云托管运维的，也就是不需要对于运行的正常的一些情况去做关注，去担心它今天会不会换掉或者换掉怎么去处理，因为这会通过专家服务把它给兜底。云服务可以看到针对像数据库，中间件等，会提供一些常见的响应时间、使用率等指标。
应用层是一个JVM应用，那么会有一些JVM应用相关的一些慢Sql监控，ingress监控等，包括整体应用的健康度。业务用户体验成绩是靠近终端，会有跟业务相关的一些，比如订单数的这种指标。以及会在客户端可能会去做埋点，比如所谓前端监控或者做APP监控的指标体系。
在阿里云，会通过Prometheus+Grafana完成统一可观测的建设，但是不会直接使用开源社区的系统去做建设，基于它的一套之上，做了很多关于它的采集，存储，查询性能的改造。比如采集能力，在阿里云上，通过Prometheus去做采集的时候，存储和采集架构是分离的，也就是采集的是单独的，获利出来。
不会在采集端去携带它的高级的那些模块。我们对采集组建做了一些优化提升，比如单进程的采集的能力，通过一些技术实现了横向水平扩容，能够实现HPA，当要采集的指标数变多的时候，采集对象变多的时候它会自动的扩容来满足比较大规模的，比如五千，上万的这种节点的一个集群的采集的需要。
在存储能力也是数据的写步进它每一个环节做了自动重复的一个强化，来解决数据丢弃的一些问题，保障数据的完整性和准确性。阿里云的Prometheus就是建在整个阿里云的资源池之上，通过后端服务，后端云服务的提供了SAV，能够实现整体的数据的一个可靠性，完整性的一个保障。
那么在查询这一块，也是做了大量的通过一些算法，通过一些技术手段做了些优化。
比如我今天想要去查询七天的指标，可能会有一个网站到底有多少度访问过这样指标的话，我现在可以查询七天的曲线。也是能够通过秒级的方式，能够展现出这样数据，这个效果。
前面提到需要把日志、XTrace，需要把指标的数据做一个关联。所以当这些数据通过ARMS服务端，也就是可观测的产品和服务单做一个上报的时候，也会兵分几路，会把对应的XTrace会推送到插件的系统里面，然后会把指标推送到Prometheus存储里边，然后又通过一些标签的方式来完成这些数据的关联。
那么做完这些关联之后，它可以产生一些比较有价值的，上次的一些应用场景。比如可以去实现全面的监控，去实现实时的查询和分析，以及可以实现一个服务的上下游，它的拓扑视图等能力。
告警，当把这个数据都收上来之后，因为像这些指标都是统一的一个Prometheus的数据源，所以会通过Prometheus查询Prom QL去做高检规则的配置。那么这些数据进来之后，还会再去做智能降噪，来避免一些高级风暴的这些问题。
当他如果说今天去明确产生告警的事件的时候，会把它分配到对应的通过各种的聊天工具会把它发送给对应的处理人来做处理。我们本身就提供了很多内置的告警规则，以及会有通过一些手段来做正常降噪，以及会通过一些聊天工具来实现一些协同。
如果说所有的这些运维动作，所有的告警的接收跟处理都在一个聊天工具里去完成闭环之后，它效果是能够去跟踪，能够去分析告警运维体系里针对业务系统的维度，针对处理人维度，它的一些MTTR MTTA还有这些指标，通过这种分析复盘能够去提升整体的运维效率。
四、客户案例
这是客户案例，传音科技的话，大家应该也知道传音科技他主要是以做手机的市场为主，那么它的痛点是它本身是一个比较复杂的微服的架构，所以这个微服务引入了这个问题，就是可观测对象很多，以及排查线上的问题比较慢。
他这个团队如果今天在一家公司，他这家公司去做可观测的监控系统的时候，但他这个业务本身是在做快速的推广铺张的，那么这个时候如果说需要让每一个业务都能够有效的去接入到这个监控系统，这里面是有很多的一些联合的工作。那么过去的话，他们可能有的业务为了快速上线，不愿意接入可观测平台，那么这里边那个推广成本就非常高。因为他本身是一个全球化的市场，所以这个数据很分散。他过去每一个地域可能都会有一个独立的一个可观测的系统，那么这种情况如果我站在全局去做观测分析的时候就变得非常困难。所以，通过阿里云可观测的解决方案，完成了统一的指标体系以及是我们实现了全链路的跟踪诊断。在一个微服务架构里边能够方便的去看到他的这些各个服务的进化状态，针对一些线上问题，就可以通过这种链路的跟踪的方式，我们能够快速的去做一个代码级别的定位以及是我们本身链路追踪的这个方案是无侵入似的。对JVM这种应用的话，我们只需要通过一个探针，就是在他运行的时候提前去换下一个探针。而不需要对代码层面有任何的改造，就能实现对于应用的监控以及是技术能力，通过这样一个技术能力的话，我们是能够实现在全球的角度就是能够把他各个地域的那些数据源去做统一的抽取，统一的联邦的查询。通过这些建设，他们的成本就是一个运维技术的全面升级，跟这个业务创建效率的一个提升。
第二个例子是关于友邦人寿的，这个例子比较有意思，前面提到会有一个可观测产品左溢的问题，现在也越来越多了，就关注到左侧，开发流水线左侧，在他研发派,在测试过程当中的一些指标。就是Pipeline监控，可以看到在这个阶段，会去监控它的构建次数，构建频率，构建时长，成功率，部署的成功率等指标，这个是比较有意思的。右边的系统层监控、应用层的监控。这个应用层的监控在前面的指标体系里面有过展现，就不一一介绍了。
在友邦人寿，他们会有三张屏。一张大屏，在大屏会通过业务指标跟通用指标的呈现来实现决策的支撑，在这张屏幕里可以看到比如他们这个Pod的健康度，联通性。我们可以看他们业务的一些实时的情况。那么他们如果说他们这个这个集群是一个双性的，也能够在一张大屏里面去做一个展现。
他们还有一个中屏，中屏也就是在一个具体的，比如关于监控环节，它会有一些仪表盘，在仪表盘里面能够看到他的流水线的指标来度量它的研发效率，以及是在它的性能监控，就是APM的指标能够去做一个观察分析。包括全球债务链、日志，都能够在这个中屏里面去做一个展现。
那么它还有个小屏，小屏就是当如果有问题发生的时候，关于他业务的一些核心的部分发生问题的时候能够通过钉钉、卡片推送的方式告知对应的处理人，让他们来处理问题。
五、产品试用
最后，我们前面也提到我们这边就是现在有一个产品试用的体验，欢迎大家可以来我们阿里云官网，搜索关键字来体验我们这个可观测产品。
