可观测性(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有两个很重要的属性:
- TraceID: 一次请求中的所有路径都会共用一个唯一的TraceID，这个TraceID一般由初始节点产生，然后传递到所有节点
- SpanID: TraceID只能够串起所有节点，但节点之间的调用顺序需要由SpanID来产生
由于篇幅有限，trace将做为后续文章介绍的重点，不在这里展开
为什么
为什么要实现可观测性呢?
可能有些人会提出: 我没有做任何可观测性方面的工作，系统也一直work fine呢
确实，在小公司或者系统不那么复杂的情况下，落地可观测性是有成本的，毕竟需要花人力物力去搭建那么些系统同时需要有可运维能力
但是如果业务链路足够长、逻辑足够复杂，长远来看，可观测性的落地是非常有必要的，有以下几点原因:
- 现在到处吹捧云原生，从纯技术角度上来说，实现可观测性是趋势，也是技术追求
- 整个架构的可观测性对开发⼈员和运维⼯程师更友好、定位问题更快
- 可以更好地提供业务属性数据
痛苦
同时，也会发现一个很痛苦的问题:这些开源项目大多是孤立的，之间没有多大的关联性，大公司可能有能力研发自己的可观测平台实现大一统，对于小公司来说，需要在多个平台之前进行切换，如果有架构调整，那切换的成本相信是巨大的。
观测性能否做到一统呢?
这也其实也是【思考】中第2个问题，简单地说，能不能通过日志系统中的关键字，跳转到trace系统中看这条日志所处的请求的所有链路。
答案是肯定的，grafana就做的非常不错，统一了agent，从logging、trace、metrics三个纬度进行采集，loki实现了日志的存储，新贵tempo实现trace的追踪，metrics则原生支持prometheus，grafana则提供了统一的可视化界面，从agent到view集成度非常高。
但grafana不是作者要介绍的主角，client端的实现才是作者要深入调研实践的主角，这就是CNCF牵头开源的新项目: OpenTelemetry
总结一下，以上主要介绍了可观性测是什么以及为什么需要可观测性，但没有回答一个很重要的问题:如何实现可观测性，这其实是接下来要分享的内容，会详细介绍借用OpenTelemetry如何实现可观测性
