🎬作者简介：大家好，我是蓝胖子🥇
☁️博客首页：CSDN主页蓝胖子的编程梦
🌄每日一句：人生的烦恼，多在于明白的太多，而做的太少
大家好，我是蓝胖子，随着微服务的流行，服务的可观测性概念被越来越多人提及到，究竟什么是可观测性？我们应该如何构建服务的可观测性？我将会在这篇文章中逐步提及到，并对和可观测性相关的工具 Opentelemetry做一个大致的介绍。
🦋可观测性指的是什么
首先，我们来看看什么是可观测性。
传统的服务监控是资源维度的监控，通常是对cpu，内存，磁盘io这些硬件资源做的监控，但是这种维度的监控往往是结果导向的，也就是由于线上bug才导致这些硬件指标异常，我们从这些异常指标中被动发现问题。这样导致，不容易定位到发生bug的根本原因。
而可观测性的理念则要求不仅要发现问题，还要发现问题的根本原因。讲究从应用维度去做监控设计，上到用户体验，下到基础设施都被囊括进了监控的范畴。
通过日志，指标，链路追踪技术，构建服务的监控体系，覆盖上到用户体验，下到基础设施的监控内容，并将它们相互联系起来，这样当问题发生时，从这些监控内容中寻找联系从而定位到发生问题的根本原因就是可观测性要做的事情，可观测性就是一种理念。
通常很多时候我们也会说APM（应用服务性能监控）,我认为可观测性是对APM中的相关概念和理念的延升。
最初始的APM则脱离于原始的传统服务监控，讲究从应用维度建立监控体系，并将日志，指标，链路追踪技术在应用层互相结合起来建立监控体系，如今提到的APM系统则和可观测性基本一致了，上到用户体验，下到基础设施都被囊括监进了监控的范畴，不仅仅体现在对应用层的监控。
🦋Opentelemetry是什么
在了解了可观测性是什么后，我们来看看一个比较🔥火热的开源工具 Opentelemetry，从上面可以知道，构建可观测性监控体系的时候，通常是通过日志，指标，链路追踪技术，这3个技术可以说是构建服务可观测性的3大基石。
日志数据，指标数据，链路追踪数据也被称为遥测数据(telemetry data)。
但最开始开发者在将这3个手段融入到项目中时没有统一的标准，Opentelemetry 则是为了统一创建和管理这些遥测数据(例如 日志数据，指标数据，链路追踪数据 )而产生的。
Opentelemetry 规范了客户端在创建和使用遥测数据的规范，并且Opentelemetry是和具体的监控组件是无关的，你可以将Opentelemetry的链路追踪数据导入jaeger或者其他链路追踪系统比如skywalking。
也就是说，Opentelemetry只负责创建和管理，导出遥测数据，但是遥测数据的存储和可视化需要其他开源或商业软件去完成。
🦋Opentelemetry 的组成
在了解了Opentelemetry 是什么后，我们来看看Opentelemetry项目包含哪些组件。
Opentelemetry不是一个软件，是一个构建可观测性的工具集。
所以它提供了各种语言的客户端SDK，客户端SDK拥有统一的生成和导出遥测数据的逻辑，所以用上SDK就拥有统一的标准。
同时，Opentelemetry还提供了一个Opentelemetry Collector的代理软件，它能将发往jaeger或者prometheus或者其他的开源组件的遥测数据，预先经过Opentelemetry Collector处理后再发送到对端。Opentelemetry Collector对遥测数据提供了强大的预处理遥测数据的功能。比如jaeger对链路追踪数据只有前置采样功能，但我们能通过Opentelemetry Collector实现对链路追踪的后置采样。
除此以外，在Opentelemetry 项目中，还提供了自动化注入监控功能的机制，例如java的客户端SDK已经有成熟的探针机制，在golang方面，社区正在开发使用ebpf技术来实现golang服务的自动化能力。
另外，Opentelemetry项目中还包含了其他工具项目，比如OpenTelemetry Operator for Kubernetes, OpenTelemetry Helm Charts, and community assets for FaaS 。
Opentelemetry 开维护了一个系统 library ecosystem 查找用于使用和扩展 OpenTelemetry 的库、插件、集成和其他有用工具。我们可以在上面查找到想要的组件并且查看到其用法。
