可观测性(Observability)并不是一个新词,而在几十年前被广泛地用于控制理论,用它来描述和理解⾃我调节系统。随着容器技术、微服务、⽆服务器迅速流行,使得系统间的访问越来越复杂,在云上、本地或两者上可能会运⾏数千个进程, 使用传统的监控技术和⼯具很难跟踪这些分布式架构中的通信路径和相互依赖关系。系统内部的可见性就变得非常重要。
那可观测性到底在说什么呢?
上述 3 个问题如果你都能出”Yes”回答,那么作者建议直接滑走不用看下文。
如果你脱口而出,不就是日志平台跟监控系统能解决吗?
对,其实也不对
好,首先来说明一下可观测性跟监控系统的一些区别
可观测性跟监控系统确实很像,可观测性跟监控系统本质上是一样的,都是在解决一个问题,:度量你的基础设施、平台和应用程序,以了解它是如何运行。
但两者的问题域却完全不同,监控告诉我们系统的哪些部分是工作的,可观测性告诉我们那里为什么不工作了.
度量,是个程度
可深可浅的词,比如回到问题一: 你的应用是可观测的吗,很多人会给出肯定的回答,在某些人的理解中,不就是监控应用的状态吗?对于 k8s 应用来讲,prometheus 就可以开箱即用地监控它,没错,状态是能够被监控的,通过监控系统我们可以知道某个时刻it works
但是这个应用是可观测的吗?当然不是,因它在出现问题的时候,通过监控系统可能没办法判断它在哪个函数中 crash 了
如果要知道它哪里出了问题,那么就需要在应用内部实现可见性,通过埋点或者是字节码注入的方式,让应用暴露它的业务、性能指标,比如函数的时延、调用次数、调用错误等,借助这些指标再结合旁路分析系统就可以很清晰地展现应用的全貌。
这就属于可观测性
logging、trace、metrics 是实现可观测性的三板斧,每一个都有很多的解决方案可选,
Logging 中使用较多的有 EFK、loki
Trace 中有 Jaeger、Tempo
Metrics 中有 Prometheus,Netdata
通过这些工具收集的数据统称为遥测数据
这些工具基本开箱即用的特性,作者相信给很多企业带来了便利性。
想用好这三个工具业界还是有一些指导思想的,对于 logging 跟 metrics 很多人会相对熟悉一些,作者在这里想简单说一说 trace,trace 一般为全链路追踪,表示请求通过分布式系统的端到端的过程, trace 有两个很重要的属性:
由于篇幅有限,trace 将做为后续文章介绍的重点,不在这里展开
为什么要实现可观测性呢?
可能有些人会提出: 我没有做任何可观测性方面的工作,系统也一直work fine
呢
确实,在小公司或者系统不那么复杂的情况下,落地可观测性是有成本的,毕竟需要花人力物力去搭建那么些系统同时需要有可运维能力
但是如果业务链路足够长、逻辑足够复杂,长远来看,可观测性的落地是非常有必要的,有以下几点原因:
同时,也会发现一个很痛苦的问题:这些开源项目大多是孤立的,之间没有多大的关联性,大公司可能有能力研发自己的可观测平台实现大一统,对于小公司来说,需要在多个平台之前进行切换,如果有架构调整,那切换的成本相信是巨大的。
观测性能否做到一统呢?
这也其实也是【思考】中第 2 个问题,简单地说,能不能通过日志系统中的关键字,跳转到 trace 系统中看这条日志所处的请求的所有链路。
答案是肯定的,grafana 就做的非常不错,统一了 agent,从 logging、trace、metrics 三个纬度进行采集,loki 实现了日志的存储,新贵 tempo 实现 trace 的追踪,metrics 则原生支持 prometheus,grafana 则提供了统一的可视化界面,从 agent 到 view 集成度非常高。
但 grafana 不是作者要介绍的主角,client 端的实现才是作者要深入调研实践的主角,这就是 CNCF 牵头开源的新项目: OpenTelemetry
总结一下,以上主要介绍了可观性测是什么以及为什么需要可观测性,但没有回答一个很重要的问题:如何实现可观测性,这其实是接下来要分享的内容,会详细介绍借用 OpenTelemetry 如何实现可观测性
[1]
https://cloud.tencent.com/developer/article/1801643: https://cloud.tencent.com/developer/article/1801643
[2]
https://opentelemetry.io: https://opentelemetry.io
[3]
https://grafana.com: https://grafana.com
原文链接:https://izsk.me/2021/10/19/OpenTelemetry-what-is-observability/