泽注：这是一个系列，共分成6部分，这是第1部分。翻译自：https://trstringer.com/otel-part1-intro/
毫无疑问，在过去的几年里，你听到可观测性这个词可能很多次了。很多人很难理解它的真正含义。而且对很多人来说，他们错误地把它等同于 "监控"。虽然可观测性的根本定义，以及它所包含的所有内容，远远超出了这个博文系列的范围，但我强烈建议你去买一本由Charity Majors、Liz Fong-Jones和George Miranda编写的《可观测性工程》。
译注：Observability Engineering，目前还没有出中文版。
不过，本系列博客将介绍一个完整的例子——使用OpenTelemetry实现可观测性。OpenTelemetry是CNCF的一个项目，致力于使可观测性更容易。
什么是OpenTelemetry?
OpenTelemetry是OpenCensus和OpenTracing两个项目合并的结果。这是几年前的事情了。从那时起，OpenTelemetry（也被简称为OTel）被定位为供应商无关的现代软件可观测性实现。很多人会说 OpenTelemetry 是可观测性的未来，根据我的接触和经验，我倾向于同意这种说法。
泽注：OpenTelemetry的简短历史 https://www.cncf.io/blog/2019/05/21/a-brief-history-of-opentelemetry-so-far/
OTel 的组件
典型的OTel解决方案里，进一步将OpenTelemetry划分为多个组件。它们是：API、SDK和Collector（收集器）。
API 和 SDK
当开始使用OpenTelemetry时，最初需要了解的重要事情之一是该项目是如何区分API和SDK的。简而言之，API负责收集遥测数据和作为其一部分的所有数据，而SDK是将这些数据从当前的观测过程中获取到另一个环节进行分析。随着我们对本文案例的深入了解，这将更有意思，但值得理解的是API和SDK之间的关注点分离。
因为它们是分离的，所以它们允许我们把观测到的数据（API）和处理它的方式（SDK）解耦。SDK有各种各样的语言支持，包括（但不限于）： Go、Python、Java、Ruby、JavaScript、.NET，以及更多。关于语言支持的更多信息，请看工具化的文档。我们将在以后的博文中介绍。
Collector
SDK的一部分工作中是从观测中获取数据，但是这些数据又该放到哪呢？放到Collector中。Collector的工作分成三个不同的阶段：
- 接收遥测数据
- 处理遥测数据
- 导出遥测数据
Collector是遥测数据的ETL流水线。虽然你不必使用OTel解决方案，但是OpenTelemetry Collector是非常不错且常用的解决方案。在后面的博客中，我们会更详细介绍此方案。
调用链追踪，指标，日志
遥测和可观测性包含三种数据类型：调用链追踪，指标，日志。虽然日志和指标是我们过去经常处理的传统数据点。但是很多人认为真正释放可观测性能力的是调用链追踪。通过收集高标准的调用链数据，我们可以快速回答（线上）问题，而不需要修改代码。我们可以将异常值和正常操作进行比较，甚至做更多事情。
本系列博客将主要关注调用链追踪，如果你关注其它数据类型的区别，请阅读本文开头提到的《可观测性工程》一书。
应用程序样例
本系列博客的重点是展示如何使用OpenTelemetry观测应用程序。为达到此目的，我创建了一个应用程序样例。它将使用文章中的很多要点。这个应用程序的设计如下图：
image.png
这是一个购物车应用样例，由三个不同的web服务组成的：
- Cart - 处理用户对购物车数据的请求的服务(用Go语言编写)
- User - 处理来自购物车服务的用户验证和查询请求（用Go语言编写）
- Price - 为产品提供更新的价格信息（用Python编写）
后台使用MySQL进行数据持久化。
整个可观测性实现完全使用的是OpenTelemetry的API和SDK。遥测收集是通过OpenTelemetry Collector向Jaeger发送跟踪数据实现的。
以下使用OpenTelemetry采集数据，并在Jaeger中展示分布式跟踪的例子：
image.png
所有的的代码以及如何在本地运行的说明都在这里：https://github.com/trstringer/otel-shopping-cart
总结
希望您已经了解什么是OpenTelemetry，它是由哪些不同部分组成的，以及我们在后续的文章中如何深入研究。这仅仅只是开始。跟随本系统博客的其余部分，了解如何使用OpenTelemetry观测你的应用程序。
网友评论