共计 1328 个字符，预计需要花费 4 分钟才能阅读完成。
前言
之前一直在思考对于一家互联网公司如何实战落地 AIOPS，曾经在某厂践行过一些关于融合监控，日志和 trace 三个领域，然后结合算法实现 AIOPS 的工作。冥冥之中，总感觉国外某些大厂，会折腾出一个标准，至于这个标准是什么，却不能特别清晰地说出来。
直到看到 OpenTelemetry 这个项目，结合自己之前的经历，感觉这个项目对于运维，对于服务治理，对于 AIOPS，至关重要。
OpenTelemetry 是什么？
两个有助于为云原生操作提供指标的开源项目已合并为一个项目。Google 的 OpenCensus 和 Cloud Native Computing Foundation 的 OpenTracing 的融合将被称为 OpenTelemetry，并将由 CNCF 管理。
聚合背后的想法是创建一个完整的遥测系统，用于监控微服务和其他分布式系统，前两个项目的组织者说。它还将使最终用户的仪表服务过程更容易一些，特别是在已经非常丰富的云原生场景中。
遥测数据有多种形式，用户在进行整合时不想考虑多个品牌。他们应该只与一个项目集成，以获得他们想要的遥测。
最终 OpenTelemetry 由一组集成的 API 和库以及通过代理和收集器的收集机制组成。这些组件用于生成，收集和描述有关分布式系统的遥测。该数据包括将来的基本上下文传播，分布式跟踪，度量和其他信号。OpenTelemetry 旨在使您可以轻松地从您的服务和您选择的后端获取关键的遥测数据。对于每种受支持的语言，它提供了一组 API，库和数据规范，开发人员可以利用他们认为合适的任何组件。
PS:
- 不过 OpenTelemetry 目前还处于设计阶段，差不多要等 2020 年，才可以生产可用。
- 看规划第一阶段并不包含 logging 的实现。
OpenTelemetry 对于服务治理的可观察性的意义
术语“可观察性”源于控制理论学科，指的是系统在其产生的遥测基础上的理解程度。
在软件中，可观察性通常是指由服务产生的遥测，并分为三个主要的垂直：
- 跟踪（又称分布式跟踪）提供对系统请求的完整生命周期（即跟踪）的深入了解，使您可以查明故障和性能问题。
- 监控（度量标准）提供有关系统内部运行的进程的定量信息，包括计数器，仪表和直方图。
- 日志记录可以深入了解进程发出的特定于应用程序的消息。
这些垂直方向紧密相连。度量标准可用于精确定位，例如，行为不当行为的子集。与这些跟踪关联的日志可能有助于找到此行为的根本原因。然后，可以根据此发现配置新指标，以便下次更早地发现此问题。
OpenTelemetry 旨在将所有三个垂直组合成一组系统组件和特定于语言的遥测库。它旨在取代专注于跟踪的 OpenTracing 项目和专注于跟踪和指标的 OpenCensus 项目。
结语
结合同为 cncf 项目的 prometheus(metrics 领域)，jaeger(trace), fluentd(log)，OpenTelemetry 的愿景基本上具备很好的实战基础。融合 merics 和 trace 和 log 三大领域，至少在以下两个方向是有非常大的意义：
- 根因分析
- 故障预测
而对于一个互联网公司也有很大的启发，应该提前准备，在选型和实战 merics 和 trace 和 log 技术方案的时候，考虑到 OpenTelemetry 标准。
