系统可观测性解析与其常用套件
一.什么是系统可观测性？为什么需要它？
(一)系统观测性
可观察性（observability）是指系统可以由其外部输出推断其其内部状态的程度。
一个系统如何快速的查找出bug，快速的修复，快速的观察到异常，都取决于其观测性，能不能及时的查到导致异常的数据，再进行日志溯源复现，告警能不能正常的，有效的触发？
现在大多是以容器，微服务来主导的业务，容器繁多，日志乱麻，一个系统的观测性完完全全可以代表这个系统的成熟度，决定其成功于否
(二)为什么需要？
现在大多业务充满着各种远程调用，互相编织成网，急需一种能够将其条理清晰存档的日志，既能方便观察也能方便复盘错误。这也就是系统观测性，就算在以前，这类监控大盘一类的需求也是重点，只是在当今容器化，虚拟化，分布式的业务特点下，对于这种需要的需求被极大的放大了
调用出错了，需要通过链路追踪查到具体是那一次调用，上下游是谁
半夜触发了告警，能第一时间收到消息启动应对措施，最小化损失
这些都是你需要系统观测性的理由！
二.常用套件介绍
(一)数据来源
想要实现观测性那肯定需要数据，这里介绍一下几种数据类型
**链路追踪（Trace）**顾名思义，用于记录方法调用的调用链，包括远程调用
**指标（Martic）**用于记录各种数值，比如成功率，评价返回时间等等
这两类数据是整个可观测性最重要也是最需要关注的数据
如何上报这些数据？一般来说有两种方式
插桩
相当于在你的程序中加了一个插件，比如你的程序中假如引入了OpenTelemetry Agent ，它在编译成class的时候对你的方法进行字节码增强，比如在你的方法外面套一层上报数据的代码，这样来实现无感知无侵入的上报数据
优点很明显：无感知无侵入使用方便，缺点也很明显：自定义度低，且通常难以支持自定义指标类数据的收集
手动上报
一般Java都会引入Micrometer依赖，这是一个十分强大的指标系统，和Spring高度整合，且支持几乎所有的数据中间件，管道等等，同时支持多种协议，OpenTelemetry和Prometheus都支持
你可以用其很方便的来收集链路信息，指标上报到OpenTelemetry （后面会提）
自身集成
很多组件自己都有对应的数据指标上报系统，比如Dubbo就有自己的一套上报系统，可以不需要配置Micrometer自行收集远程调用链信息上报（虽然还是需要Micrometer依赖）
(二)数据管道
众所周知，一门技术的发展，必须伴随着标准规范的建立与实施，比如统一的api格式，统一的通信协议
数据上报也不例外。在以前，每一个组件都有自身独立的信息格式，非常不利于多方协调
想用 Zipkin？在代码里引入 Zipkin Brave SDK。
想用 Prometheus？在代码里引入 Prometheus Client SDK。
想用 SkyWalking？在代码里引入 SkyWalking 探针。
这时候就需要一个管道来将其中和，程序只要将信息全部扔到这个管道，这个管道自己去分流到对应的组件之中
OpenTelemetry
OpenTelemetry是目前运用的最广泛也是最成功的数据管道
它不存储信息，只是起到一个清洗分发的作用：每一个数据产生源都能向他上报数据，OpenTelemetry将其进行收集并推给对应的组件进行进一步处理
它有属于自己的协议：OTLP 性能最好，信息最全，所有的 OTel Agent（包括前面提到的 Java Agent）默认都是输出这个格式
也可以接受Zipkin ，Jaeger，Prometheus 等格式的信息，这意味着你可以不用对代码大换血，直接把原本上传的地址改为OpenTelemetry即可
收集到数据后，他会根据配置，将其处理后发向对应的组件:比如链路信息转为Zipkin格式发往zipkin，指标信息转为Prometheus 格式，发往Prometheus
这样，就很方便的实现了数据的上报，同时保证了业务代码永远不需要因为监控系统的更换而修改
(三)链路跟踪
链路跟踪是分布式系统的生命线，任何业务只要牵涉到分布式就会有一堆麻烦，这就体现出了链路跟踪的必须性
Zipkin 与 Jaeger
目前链路追踪常用的有 Zipkin 与 Jaeger
他们都会对每一次调用进行记录，产生Trace Id（代表一次调用的id）和Span Id（代表当前服务的id），让你有能力定位错误发生在哪个环节之中
还能在上报数据中额外记录下关键信息以快速判断
注意，Zipkin 与 Jaeger更多的是对数据的可视化展示和整合，虽然他们有自己的探针，但一般不会用他们，具体上报什么，怎么上报，取决于程序如何处理，比如Dubbo上报，Micrometer上报等
但现在也不会用Zipkin与Jaeger去可视化展示链路信息，都是将其送往统一的监控组件,比如Grafana
(四)时序数据库
对于指标，很多时候其需要进一步的整合，就比如我们要一分钟之类的请求数，我们的上报数据中通常只有所有请求的数据，需要通过一种方式来对其进行处理来得到我们真正适合展示的数据
Prometheus
这时候就需要时序数据库：Prometheus 登场了
什么是时序数据库？
顾名思义，所有数据由数据和时间组成，同时支持查询语言来进行类似SQL的查询（比如PromQL）
这样就成为了一个能够高度自定义指标的组件，只需要提供原始数据，写好对应的查询语句，就能产出对应的指标以供拉取，观测
Prometheus处理的都是Martic，链路追踪因为自身就有可读性，不会上报到Prometheus，而是直接送到对应的可视化组件之中
(五)展示仪表盘
以上的组件要么各有各的ui，要么ui简陋，非常不适合使用，这时候就需要一个"显示器"来将它们简洁又美观的展现出来：Grafana
Grafana
Grafana支持众多数据来源：Zipkin，Mysql，Redis，Prometheus等等，但用得最多的就是Prometheus和Zipkin类：指标和追踪
Grafana通过向Prometheus执行对应的PromQL来拉取到数据，并绘制到指定的监控上，Grafana的可视化做得非常不错，有十几种展示类型，每条线，每次点击，每个点都可以高度自定义，基本是监控界的top1了
同样的，链路追踪数据也同样能方便的展示，给出对应的TraceId，Grafana便能从Zipkin查询到路径并绘制出来
但值得注意的是，默认上报不会带有TraceId，你需要手动开启Example功能，这会在上报数据中挑选一点比例的数据带有TraceId,这样你就能直接在Grafana看到产生对应指标的TraceId的链路了（需要设置Grafana的Example功能），这也是最常见的使用方法
也可以用Tag直接查询报错的链路来进行分析，官网文档有详细的教程
(六)告警
没有人会一直盯着监控 ，所以告警是必须的，对一些关键的指标规定告警阈值，达到了就通过邮件等方式进行提醒，是高可用系统的必备
主要通过 Prometheus 或是 Grafana 来实现：
Prometheus 可以对一些指标进行设置，比如一分钟内失败率大于1%就把数据推到其他组件（比如Alertmanager ），Alertmanager收到消息后会触发告警（发邮件等等）
Grafana更加简单，因为其本身就是监控大盘，直接设置 **查询 Prometheus 的数据 -> 如果 CPU > 80% 持续 5 分钟 -> 发送邮件/钉钉/企业微信 **即可，且其中内置了很多通知渠道，webhook、Slack、钉钉、飞书等
一般来说，Grafana 适合简单、快速上手 ，对于极致的高可用，用Prometheus + Alertmanager
(七) 全家桶
SkyWalking
对于一些小业务或小公司，不想引入这么多复杂的组件，想最小化代价解决问题，那可以试一下SkyWalking
SkyWalking集成了链路追踪，指标上报，告警系统，监控大盘，非常适合小型业务和小公司采用，同时采用ES作为数据源，查询速度和性能都非常不错
三.总结
一般来说，一套比较完备的观测性套件如下
链路追踪：Java Service -> OpenTelemetry ->Zipkin(Jaeger) ->Grafana
指标数据：Java Service自身上报或Agent 探针 -> OpenTelemetry -> Prometheus -> Grafana
这就是典型观测性套件组合了