|
|
# 可观测性
|
|
|
|
|
|
在监控章节的[引言](https://course.rs/logs/observe/intro.html)中，我们提到了老板、前端、后端眼中的监控是各不相同的，那么有没有办法将监控模型进行抽象、统一呢？
|
|
|
|
|
|
来简单分析一下：
|
|
|
|
|
|
- 业务指标实时展示，这是一个指标型的数据( metric )
|
|
|
- 手机 APP 上传的数据，包含了日志( log )和指标类型( metric )，如果考虑到 APP 作为一次 HTTP 请求的发起端，那还涉及到请求链路的跟踪( trace)
|
|
|
- 后端链路跟踪是 trace，请求错误率、QPS 是 metric，异常日志是 log
|
|
|
|
|
|
喔，好像线索很明显哎，我们貌似可以把监控模型分为三种：指标 metric、日志 log 和 链路 trace。
|
|
|
|
|
|
先别急，我们对总结出来的三种类型进行下对比，看看彼此之间是否存在关联性( 良好的模型设计，彼此之间应该是无关联的 ):
|
|
|
|
|
|
- 指标：用于表示在某一段时间内，一个行为出现的次数和分布
|
|
|
- 日志：记录在某一个时间点发生的一次事件
|
|
|
- 链路：记录一次请求所经过的完整的服务链路，可能会横跨线程、进程，也可能会横跨服务( 分布式、微服务 )
|
|
|
|
|
|
按照这个定义来看，三种类型几乎没有关联性，是不是意味着我们的监控模型非常成功？
|
|
|
|
|
|
恭喜你，刚才总结出的监控模型正是这几年非常火热的可观测性监控的三大基础：Metrics / Log / Trace。
|
|
|
|
|
|
## 各自为战的三种模型
|
|
|
|
|
|
但是如果按照这个模型，我们将监控分成三个部分开发，彼此没有关联，并且在使用之时，也带着孤立的观点去看待这些数据和功能，那可观测性就失去了其应有的意义。
|
|
|
|
|
|
例如要看指标趋势变化就使用 metrics，查看详细问题使用 log，要看请求链路、链路各部分的耗时、服务依赖都使用 trace，虽然看起来很美好，但是它们都在各自为战。
|
|
|
|
|
|
例如一个很常见的场景，现在我们通过 metrics 获得了一个告警，发现某个服务的 SLA 降低、错误率上升，此时该如何排查错误原因？ 查看日志？你如何确保日志跟错误率上升有内在的联系呢？而且一个大型服务，它的各种类型的日志、错误都是非常频繁的，要大海捞针般地找出特定的日志，非常难。
|
|
|
|
|
|
由于缺乏数据模型上的关联，最后只能各自为战：发现了错误率上升，就人工去找日志和链路，运气好，就能很快地查明原因，运气不好？等待老板和用户的咆哮吧
|
|
|
|
|
|
这个过程很不美好，需要工程师们充分理解每一项数据的底层逻辑，而在大型微服务架构中，没有一个工程师可以清晰的知道所有的底层逻辑，此时就需要分工协作去排查，那问题处理的复杂度和挑战性最终会急剧增加。
|
|
|
|
|
|
## 模型纽带
|
|
|
|
|
|
看来，要解决这个问题，我们需要一个纽带，来把三个模型串联起来，目前来看，trace 是最适合的。
|
|
|
|
|
|
因为问题的跟踪和解决其实就是沿着数据的流向来的，我们只要在 trace 流动的过程中，在沿途把相关的 log 收集上来，然后再针对收到的各种 trace，根据其标签去统计相应的指标。
|
|
|
|
|
|
这一样，是不是就成功地将三个模型关联在了一起？而且还不是强扭的瓜！
|
|
|
|
|
|
再回到之前假设的场景：当我们对某个 Metric 波动发生兴趣时，可以直接将造成此波动的 Trace 关联检索出来，然后查看这些 Trace 在各个微服务中的所有执行细节，最后发现是底层某个微服务在执行请求过程中发生了 Panic，这个错误不断向上传播导致了服务对外 SLA 下降。
|
|
|
|
|
|
如果可观测平台做得更完善一些，将微服务的变更事件数据也呈现出来，那么一个工程师就可以快速完成整个排障和根因定位的过程，甚至不需要人，通过机器就可以自动完成整个排障和根因定位过程。
|
|
|
|
|
|
|
|
|
看到这里，相信大家都已经明白了 trace 的重要性以及可观测性监控到底优秀在哪里。那么问题来了，该如何落地？
|
|
|
|
|
|
## 数据采集
|
|
|
|
|
|
首先，没有数据，就没有一切，因此我们需要先把监控数据采集上来。
|
|
|
|
|
|
除了跨服务的数据统一规范外，由于现在的微服务往往使用多种语言实现，我们的数据采集还要支持不同的语言，选择一个合适的数据采集 SDK 就成了重中之重。
|
|
|
|
|
|
目前来说，我们最推荐大家采用 [OpenTelemetry](https://opentelemetry.io) 作为可观测性解决方案，它提供了完整的数据协议规范、API和多语言采集 SDK，我们将在下个章节进行详细介绍。
|
|
|
|
|
|
## 数据处理和存储
|
|
|
虽然在我们之前的模型设计完善后，数据彼此之间存在内在关联性，但是不代表它们就能够按照同样的格式来存储了，甚至都无法保证使用同一个数据库来存储。
|
|
|
|
|
|
就目前而言，对于三种模型的数据处理和存储推荐如下:
|
|
|
|
|
|
- Trace，使用 jaeger 接收采集上来的 trace 数据，经过处理后存储到一个分布式数据库中，例如 cassandra、scyllaDB 等
|
|
|
- Log，如果对日志的关键词索引有较高的要求，还是建议使用 ElasticeSearch，如果可以提前在日志中通过 kv 的形式打上标签，然后未来也只需要通过标签来索引，那可以考虑使用 loki
|
|
|
- Metrics，啥都不用说了，prometheus 走起，当然还可以使用 influxdb，后者正在使用 Rust 重写，期待未来的一飞冲天
|
|
|
|
|
|
## 数据查询和展示
|
|
|
|
|
|
大家知道可观测性现在为什么很多人搞不清楚吗？就是因为你怎么做都可以，比如之前的存储，就有很多解决方案，而且还都不错。
|
|
|
|
|
|
对于数据展示也是，你可以使用上面的 `jaeger`、`promethes` 自带的 UI，也可以使用 `grafana` 这种统一性的 UI，而从我个人来说，更推荐使用 `grafana`，毕竟 UI 的统一性和内联性对于监控数据的查询是非常重要的。
|
|
|
|
|
|
再说了，`grafana` 的 UI 做的好看啊，没人能拒绝美好的事物吧 :D
|
|
|
|
|
|
|
|
|
好了，一篇口水文终于结束了，在后续章节我们将学习如何使用 `OpenTelemetry + Jaeger + Prometheus + Grafana` 搭建一套可用的监控服务，先来看看如何搭建和使用分布式追踪监控。
|
|
|
|
|
|
> "tracing 呢？你这个监控服务怎么没有它的身影，日志章节口口声声的爱，现在就忘记了吗？"
|
|
|
>
|
|
|
> "别急，我还记得呢，先卖个关子" |
