共计 3764 个字符，预计需要花费 10 分钟才能阅读完成。
作者：博睿数据产品经理 - 刘亚辉
本文分两局部，共 3400 字，浏览大概 5 分钟
l 介绍可观测性
l 介绍 Opentelemetry 的外围概念
重新认识可观测性
管理学巨匠彼得德鲁克有一句话：“如果你无奈掂量它，你就无奈治理它”。在企业中，无论是治理人，还是治理事，抑或是管理系统，首先都须要掂量。掂量的过程其实是收集信息的过程，有了足够的信息能力做出正确的判断，有了正确的判断能力做出无效的治理和口头计划。
上面我用一个简略模型来阐明我对可观测性的了解：
图释：通过观测看到表象，通过判断定位问题，通过优化解决问题。
可观测性形容的就是“观测 - 判断 - 优化 - 再观测”这个闭环的连续性、高效性。如果只有观测而无奈基于观测做出判断，则不能称其具备可观测性。如果只有教训判断而没有数据撑持，也不能称其具备可观测性，这样会导致组织高度依赖集体能力会带来治理危险。如果优化之后无奈反馈到观测上，或者因优化引入新的技术而导致无奈观测，则其可观测性不可继续。如果在观测、判断、优化的闭环中须要付出很高的老本和承当很大危险，则其可观测性的价值为负。
所以，当咱们在谈可观测性的时候，其实更多思考的是观测者、管理者的感触，也就是说在咱们遇到问题的时候，是否轻而易举地在观测平台找到答案，没有阻力也没有困惑，这就是可观测性。随着企业的倒退，组织架构（角色、观测者）和治理对象（零碎、被观测者）都会随之倒退变动，当应用了一堆传统的观测工具，却依然无奈满足观测者、管理者新的需要的时候，咱们不禁要问：“可观测性何在？”。
“可观测”不等于“可观测性”
上面，咱们来看一下咱们司空见惯的观测形式。
图释：传统的观测工具是垂直的，观测者须要从多个工具中进行问题判断。
通常咱们会基于本人想要的数据去搭建观测工具。当咱们想理解把握基础设施的健康状况的时候，咱们会很天然的想到搭建一个仪表盘，实时监测各项指标。当咱们想理解业务是如何出问题的，咱们会很天然的想到搭建一个日志平台，随时过滤排查业务日志。当咱们想理解事务为什么高提早，咱们会很天然的想到搭建一个链路监测平台，查问拓扑依赖和各节点的响应工夫。这种模式很好，帮忙咱们解决了很多问题，以至于咱们从不狐疑可观测性，咱们信念满满。偶然遇到大难题，把咱们的仪表盘、日志平台、链路平台关上，所有的数据都在这里，咱们深信肯定能到找问题的根因。即便破费了很长时间，咱们也只是通知本人要多学习，多理解把握本人负责的零碎，下一次我肯定能更快找到根因。是的，当咱们想要的数据都摆在面前的时候，咱们还有什么理由怪罪观测工具。
图释：人脑像一把尺子，依据教训比对多个指标来发现它们的相关性。
图释：当发现指标有毛刺的时候，往往须要在大脑中构建简单的日志查问条件，费时不说还容易出错。
咱们会不辞劳苦地在各种指标数据中寻找可能的关联性，失去要害线索后，咱们会在大脑中结构出一堆简单的日志查问条件来验证本人的猜测。就这样比对、猜测、验证，同时还要在各种工具中切换，不可否认很空虚。
图释：零碎规模宏大的时候，人曾经无奈去定位问题了。
传统的零碎绝对简略，上述形式卓有成效。古代 IT 零碎的关键词是分布式、池化、大数据、零信赖、弹性、容错、云原生等，越来越宏大，越来越精密，越来越动静，同时也越来越简单。通过人去寻找各种信息的关联性，再依据教训判断和优化，显然是不可行的，耗时耗力还无奈找到问题根因。
传统的工具是垂直向的，引入一个新的组件的同时也会引入一个与之对应的观测工具，这样是保障了数据的全面性，但失落了数据的关联性和剖析排查的连贯性（换句话说，咱们方方面面都监控到了，但遇到问题，还是不能很好地发现和定位）。此时咱们很天然的想到做一个对立的数据平台，设想中把所有数据放在一个平台就能解决关联性的问题，但往往理论状况是咱们只是把数据堆在一个中央，用的时候还是按传统的形式各看各的。咱们只是把无数根柱子（工具），交融成了三根柱子：一个观测指标、日志、链路的对立平台，数据对立了，但关联性还得靠人的常识和教训。
这里边最要害的其实是解决数据关联的问题，把之前须要人去比对、过滤的事交给程序去解决，程序最善于此类事同时也最牢靠，人的工夫更多的用在判断和决策上。这在简单零碎中，节俭的工夫会被放大很多倍，就这点小事就是可观测性看得见的将来。
图释：将来观测工具须要通过工夫和上下文来关联数据
那么，如何做数据关联呢？说起来很容易，那就是做工夫 + 空间的关联。在咱们的对立数据平台上，因为数据是来自于各种观测工具的，尽管咱们在数据格式上对立成了 metric、log、trace，但不同工具的 metric、log、trace 的元数据截然不同，而如果咱们在这个对立数据平台下来梳理和映射这些元数据的话，这将是庞杂、难保护、不可继续的。那该如何做呢？答案就是标准化。只有将标准化、结构化的数据喂给观测平台，观测平台能力从中发现微小价值。对立数据平台只是在数据格式上进行了标准化，而要想将 trace、metric、log 关联还必须建设 context 的标准化，context 就是数据的空间信息，再叠加上工夫信息的关联就能够施展真正的观测价值。
Opentelemetry 做了什么？
Opentelemetry（以下简称：OTel）就是解决数据标准化问题的一个我的项目，OTel 由以下几局部组成：
l 跨语言的标准规范（Specification）：定义了数据、上下文、API、概念术语等的标准。这是 OTel 的外围，它使得所有观测数据有机地对立起来，这样观测平台能力主动比对、主动过滤，同时也为 AI 提供了高质量的数据。
l 接管、解决、输入观测数据的工具（Collector）：一个用于接管 OTel 观测数据的工具，并反对通过配置 pipeline 对观测数据进行解决，输入给指定的后端。
l 各种语言的 SDK（SDK）：基于 OTel 规范的 API 实现的各种语言的 SDK，用来反对自定义开发观测数据采集器。
l 采集器（Instrumentation）：开箱即用的观测数据采集器。
OTel 是开源我的项目，所有内容都能够在 Github 找到，上面我介绍几个要害的概念：
属性
从数据的角度看属性是一个键值对，实质上属性形容了空间信息，不便从空间上做数据关联。OTel 定义了很多通用的属性，如果定义不明确或数据不统一时，是没法主动关联剖析的。上面是 Otel 定义的 K8S 的 Pod 属性：
资源
从数据的角度看资源是一个键值对汇合，实质上资源形容的是观测对象。雷同观测对象的 Metric、log、trace 都有雷同的资源数据（或称：雷同上下文），这样就能够主动发现相关性。
事件
从数据的角度看事件是一个工夫戳和一组属性组成的，用来形容某个工夫产生了某件事。实质上事件是一个工夫 + 空间的组合。
指标
从数据的角度看指标是事件的聚合，在一个沉闷的零碎中，雷同的事件会一直产生，指标提供了一个跨工夫和空间的总览。沉迷在细节不肯定有见解，跳进去，从更高的维度鸟瞰可能寻找到灵感。
跨度
从数据的角度看跨度由：操作名称、开始工夫、持续时间、一组属性组成。跨度（又称：span）形容的是一个过程，如果说事件是在一个工夫点构建了工夫和空间的相关性，那么跨度就是在一个时间段上构建了工夫和空间的相关性。
信号
信号是对规范遥测数据的形象，雷同数据模型的数据被归为一个信号。如：一个 Metric 是一个信号，所有 Metric 都具备统一标准的数据模型。一个 Trace 是一个信号，所有 Trace 都具备统一标准的数据模型。信号有一个重要的个性就是供应商无关，任何可观测零碎供应商要反对 OTel，都必须要按 OTel 的信号模型收集、上报、解决数据，这是保障高效数据关联的要害。
上下文
所有信号都基于雷同的上下文，如：在同一个服务中采集的 Metric、log、trace 具备雷同的上下文（如：service.id 和 service.name）。这其实就是在空间上建设的数据的关联。
敬畏工程
OTel 在数据层面提供了标准规范和许多拿来即用的工具，大大不便了构建可观测平台，然而真正落地去构建适宜本人的、全面可扩大的、稳固牢靠的、低成本高效益的可观测平台是一个大工程，不是简略引入就能够的。这其中波及到大数据引擎、高基数剖析引擎、关系引擎、AI 引擎等零碎难题。此外，如何设计一个简略、高效、精确、协同、业余的平台也不是一撮而就的，须要懂数据也要懂技术还要懂设计。
我把可观测平台分以下档次：
- 数据展现 + 人工关联比对 + 人工判断：大多数传统观测平台在这一层。
- 信息关联展现 + 人工判断：局部观测平台通过梳理映射能够做一些相关性展现，缩小人工发现的工夫老本。
- 信息判断 x 人工判断：极少局部观测平台做了数据的高度标准化，能够依据相关性给出见解和倡议。
- 信息判断 + 口头：没有观测工具能只依附工具做判断。
博睿在数据采集层有十多年的技术积攒，探针稳固牢靠，部署简略。在数据处理方面也禁受住了大业务量的客户考验，技术上不断创新造成了极具劣势的架构。在数据标准化、结构化设计方面也造成了本人的体系。能够说咱们刚逾越了第 2 层来到第 3 层，咱们将从观测广度和深度两个方面丰盛标准化的数据，基于此同时一直深入数据相关性，加上咱们自研的 SwiftAI 中台赋能，将来将给出更多更精准的信息判断，帮忙客户疾速落地高效可继续的观测 – 判断 – 优化闭环。
