声明：本文根据阿里云开发者社群直播整理而来。
讲师：垆皓

本次分享主要围绕以下四个方面展开：
1、可观测性
2、基本原理
3、产品介绍
4、实战演示

一、可观测性

首先我们从监控谈起：监控主要解决应用在线上运行遇到的一些问题，如图所示：

在云原生背景下，由单机服务变为分布式服务之后给监控带来的挑战：

在传统的单应用只关注单机应用的状态，各应用之间的依赖性不是很复杂；在微服务架构下，客户端的请求先通过网关转发给之后对应的具体的应用，每个应用完成不同的功能，各应用的依赖性变的很复杂，这样就会导致问题的排查以及故障的定位难度也会变的很复杂。

接下来看容器化的部署：

K8S的对于运维的发布带来了许多方便之处，但实际上也引入了一些问题：比如某一个应用pod的resourse限制设置的存在不合理之处，导致整个应用的状态非正常状态。

这样的话，在K8S的状态之下，监控不但要关注应用的状态，同时也要关注整体所依赖的底层资源的状态。

比如：一个pod在某一个load中运行，受其他pod的影响，发生了漂移，那么就要关注发生漂移的原因。

二、基本原理

那么到底什么是云原生的可观测性？

在云原生的大背景下，可观测性是依赖于之前介绍的三种数据，在依赖的基础之上获取更多、更复杂的数据，不仅仅收集某个应用的Traces数据，而且会收集许多数据：包括主机，应用以及K8S等相关数据，再由这些指标数据相互关联来发现一些问题。Trace数据之前可能是某一类应用调用的堆栈，现在可能变成上下游窜的几百个应用，之后通过某一次调用把相互涉及到的几百个应用都串联起来，事件数据可能就会引入一些类似于K8s的pod生命周期的事件或者一些别的事件。

可观测系统基于Metrics、Traces、Logs这三种数据构造，不仅可以获得应用的每个接口执行效率，也可以获得底层资源，比如K8S的底层资源的运行状态，从某一个前端到它的后端开始处理，处理完成之后到转发、应用，整个链路都需要完整的被追踪，相当于可观测性对比与传统的监控来说，可观测性更强调的是分布式系统发生的所有事件都能够被观测，给出合理的解释。

如果可观测系统出现问题之后，该如何解决？

目前来说，最出名的方法是普罗米修斯，普罗米修斯侧重于Metrics数据的系统。

它是通过API暴露Metrics指标，被暴露的指标通过普罗米修斯去拉的方式写入到一个数据库，在数据库处理分析之后通过一个大盘展示。

接下来来看对于Tracing数据的解决方案：

OpenTracing解决方案是一种标准，它定义了整个Trace，比如过来一个请求，我们该如何记录它？记录这个请求的哪些属性？然后把这个请求往下串联起来，把它的相关数据，比如请求的标识，通过什么方式往下传，传下去的时候包括数据的格式，它的数据库的目标地址是什么，此时可以往这个请求上加一个“ke”和“y6”的值，打上标签，通过上述操作，记录了请求的相关数据。这样的话形成了统一的一个Tracing的规范，在云原生的背景下OpenTracing的解决方案是一个比较流行的解决方案。

三、产品介绍

1.ARMS ARMS是一款应用性能监控的工具，涵盖了前端监控、应用监控和普罗米修斯的各类子产品，涵盖了从浏览器端到小程序端、手机APP、和KYS容器环境的监控，可以将全栈式的请求串联起来，方便了问题的排查。

2.前端监控 前端监控可以把请求发出到后面处理全部串联起来。

3.APP监控 提供了安卓和ios端的相关情况。

4.业务监控 ：如图所示

某一个请求进入，做标记为商品购买，继续下传到应用B，这个标记可以持续下传，这样相当于给整个链路打上了标记，可以统计某类请求对应的数目，响应时间等，通过业务的寓意的耗时是不是比其他的耗时长，可以做出更精准的判断。

四、实战演示

左图：核心在于某次请求进入之后，生成一个Trace Id，继续调用，发送一个ATP请求，在ATP请求把TraceId带上，这样的话下游应用在收到解析ATP之后也会把TraceId的在整个链路都记录上。在整个分布式应用中把TraceId会沿着调用一直传下去，调用的相关数据记录下来，就可以把所有的链路串起来。

右图：整个Trace的生成方式。调用不是同步的，是分开的。：整个Trace的生成方式。调用不是顺序调用，某一个调用请求完成之
后，下一个应用就继续开始。调用不是同步的，是分开的。这样的话需要我们用TraceId将其串联起来。

本文由社区志愿者整理而成，设区内容志愿者火热招募中，有好礼相赠哦。欢迎加入！戳我了解详情加入！