背景

随着云原生概念和云原生架构的普及，传统单应用大型系统在成熟的云原生技术下被拆分成很多个职能单一的微服务模块，结合容器技术能实现应用的更快速部署、迭代和交付。但同时也极大的提升了系统的复杂性，对系统的运维也带来了更大的挑战。

在这种情况下，传统的监控方式已经无法满足云原生应用下的运维需求，至此，可观测性概念被引入云原生。

可观测性

"可观测性"源于控制论，上世纪60年代由匈牙利裔工程师鲁道夫·卡尔曼提出的概念；是指系统可以由其外部输出推断内部状态的程度。这个外部输出在IT系统中，通常是由各种应用服务产生，也就是我们常见的 Trace、Metric、Log，这也是我们常说的可观测性的三大支柱。

关于可观测性和三大支柱的关系，Peter Bourgon 在2017年2月的博客 Metrics, tracing, and logging 中有详细介绍，有兴趣的童鞋可以去看看了解下。

在云原生下的可观测性最早出现于 Apple 工程师 Cindy Sridharan 的博客"Monitoring and Observability", 其中阐述了可观测性与云原生监控的关系。

在 Google，其著名的SRE体系中更是很早就奠定了可观测性的理论基础，也就是说在微服务、可观测性等概念或者出现以前，前辈们将这套理论称为监控，其中 Google SRE 特别强调白盒监控的重要性，而将当时技术圈常用的黑盒监控放在了相对次要的位置；而白盒监控正是应和了可观察性中 “主动” 的概念。

而关于监控和可观测性的概念和区别，Baron SchSchwarz 大咖更是给了个明确的定义:

至此，**可观测性 **以新思维、新视角的方式成为云原生运维的解决方案。

OpenTelemetry

目前，主流的可观测性系统都是基于 Trace、Metric、Log 这三个支柱来构建的。这三个支柱的数据结构完全不一致，开源社区也是针对这三种数据类型构建了很多优秀的开源项目，比如: Pinpoint、Prometheus、Fluentd、ELK、Jaeger 等。但是，这些项目都是专注于特定的支柱(数据类型)来解决特定应用场景的可观测性方案，每个项目都是独立的，提供特有的UI和使用方式；而在实际中云原生微服务的应用复杂度下，要定位具体问题往往需要三支柱的联合分析，在现有的方案中就存在多样的问题

系统过多: 针对三支柱，需要至少三个开源系统，每个系统还相对独立，各自维护
数据独立: 数据隔离且独立，无法发挥更大价值；三支柱系统都有自己的独立UI，在实际定位问题过程需要在三个系统中反复横跳
厂商绑定: 每个开源项目基于三支柱都有各自的数据格式，从采集端到展示端完全绑定，后续更换升级成本高

Trace、Metric、Log 三支柱数据标准的不一致，是导致上面诸多问题的根本原因，而 Opentelemetry正是为了统一三支柱数据格式而诞生的，目前在 CNCF 的孵化项目中。

OpenTelemetry是什么

在官方文档了明确定义了 What is OpenTelemetry?

OpenTelemetry is a set of APIs, SDKs, tooling and integrations that are designed for the creation and management of telemetry data such as traces, metrics, and logs.

译: OpenTelemetry 是一组标准和工具的集合，旨在管理观测类数据，如 trace、metrics、logs 等。

OpenTelemetry 是 CNCF 的一个可观测性项目，旨在提供可观测性领域的标准化方案，解决观测数据的数据模型、采集、处理、导出等的标准化问题，提供与三方 Vendor 无关的服务。

Opentelemetry解决了什么

OpenTelemetry 通过 Spec 规范了观测数据的数据模型以及采集、处理、导出方法，包括 Trace、Metrics、Logs 等，详细内容见 Opentelemetry-Specification。

为了多客户端的方便和统一数据格式，提供了具体的 Protobuf 协议，详细内容见 Opentelemetry-Proto。

同时作为一组标准和工具的集合，OpenTelemetry 基于 Spec ，针对三支柱数据提供了更多的便捷功能

提供多语言 SDK，支持主流的 10+ 种开发语言，具体详见官方文档
提供基于配置管理的 Collector 服务，便于对 Trace、Metric、Log 数据的采集、处理、导出等操作
提供对接各大主流厂商的 Collector-Contrib 服务，比如: 阿里云、AWS、Azure 等

基于这些标准和工具集，开发人员能够很简单快速的实现观测数据的结构统一，并将数据发送到 Collector 服务，在该服务中再进行数据的额外处理(比如：TraceId 关联、K8s 属性数据打标等)，同时数据的导出功能既兼容现有的各种开源项目也支持自定义的存储方案。

OpenTelemetry 提供的可观测性标准方案为云原生应用带来了革命性的进步:

统一数据协议: 通过 Opentelemetry-Specification 规范了 Metric、Trace、Log 的统一标准，让三支柱数据有了相同的数据格式，可以轻松实现数据互相关联，提升数据价值。
统一Agent: 通过 Collecote 的 Agent 模式，可以轻松完成所有可观测数据的采集、处理和传输。减少了原各自数据采集的多种 Agent，既降低了系统资源的占用，也让系统架构更加简单易维护
云原生友好: 孵化于 CNCF ，对各类云原生下系统的支持更加友好，同时有越来越多的云厂商已经宣布支持Opentelemetry，包括但不限于阿里云、AWS、Azure，未来在云上的使用会更加便捷。
厂商无关: 基于数据的统一标准，从数据采集到导出，不依赖任何特定的厂商，完全中立。可随意选择/更换服务商。
兼容性良好: 无论是数据采集还是数据的导出上，都无缝兼容现有的主流可观测性系统，包括但不限于 Prometheus、OpenTracing、OpenCensus、Fluntd、Jaeger 等。

OpenTelemetry前景如何

OpenTelemetry 最早是由 Opentracing 和 OpenCensus 两个开源项目合并而来，其中后者是来自 Google 贡献的。

2019年5月，两个开源项目合并，官方随即宣布开源 Opentelemetry 项目。不久后 CNCF 技术监督委员会（TOC）投票同意将 OpenTelemetry 作为 CNCF 的孵化项目。

2021年2月，Trace Spec 达到1.0 Release！其他的也在稳步推进中，详情可见官方 Status。

截止目前，各数据的统一指标进展如下

	Api	Sdk	Protocol
Tracing	stable	stable	stable
Metrics	stable	feature-freeze	stable
Logging	draft	draft	beta
Baggage	stable	stable	N/A

同时有越来越多的云厂商关注和贡献，从他们的贡献代码中可以看出部分云服务商提供了数据采集Receiver部分，更多的是关注数据导出Exporter部分，便于将标准化的数据导入到自身的服务中，比如阿里云的SLS。

目前项目已经处于 CNCF 的孵化阶段，社区非常活跃，背靠 Google 大爹，同时有众多主流云厂商的加入和贡献，相信在略微有点久的未来就能从 CNCF 毕业，成为云原生下可观测性方案的事实标准。

OpenTelemetry的局限

OpenTelemetry 规范了观测数据的统一标准，定位成为可观测性的基础设施，解决了三支柱数据的采集、传输、处理、收集的问题。但在这之后的诸多工作(数据存储、数据计算、数据关联、数据展示)暂时还是依赖各个Vender 平台自己去实现，目前开源界也没有一个统一的解决方案。

政采云运维团队基于公司业务快速发展下运维工作的复杂度和定制化需求，提出了构建云原生可观测性平台的目标，用于帮助研发和运维提效降本。

我们采用 OpenTelemetry 作为可观测性平台的底层数据底座，充分发挥其统一标准化数据的优势，有效的将三支柱数据聚合关联，提升数据的价值；同时针对其局限性也给出了具体的解决方案：政采云Otel平台

政采云Otel

政采云Otel 是一个基于 OpenTelemetry 监控运维可观测性的完整解决方案，主要由数据采集、数据分析、数据展示三个组件构成。标准化的观测数据在这三个组件中能简单、高效的关联聚合，为可观测性下的各类业务场景提供了更加丰富的接口数据。

数据采集

得益于 OpenTelemetry 提供的可观测性数据标准化和一系列的工具集，我们能够快速构建一个统一标准下可观测数据的采集、处理、导出服务。

在具体实现方案上，我们采用了 Agent + Collector 部署的方式。

Agent 以 Daemonset 的方式运行在 Node 上，主要负责该 Node 上数据的采集( Receiver )和处理(Processor)工作，包括但不限于应用、主机、集群等资源的可观测数据(Trace、Log、Metric)；
Collector 作为一个数据中心服务，主要负责收集 Agent 处理后的数据，支持在该数据上再做处理工作(数据打标、分组等)，最后将处理后的数据导出到对应的服务即可。Collector 服务可独立部署且支持高可用，能与Agent通信即可。

数据的采集架构和实现方案主要由 OpenTelemetry 提供的工具集完成，通过配置的方式可以很轻松的部署。同时我们对这个方案做了以下优化和改动:

添加 Processor 配置，为所有数据添加认证信息，用于支持数据的多租户功能

processors:
resource: attributes: - key: zcy.tenement.token value: "a1c191dd3b084b09cb8c3c473e58be06" action: upsert

Filebeat的 Outputs 插件官方只有(Es、Kafka、Logstash等)，暂不支持 OpenTelemetry

基于官方接口，我们实现了一个 Telemetry Outputs 插件，用于 Filebeat 将日志数据标准化后直接上传至Agent

至此，OpenTelemetry 完成了目前它所期望解决的可观测性标准方案的全部内容，在 Collector 之后关于数据的分析、存储、展示等功能并不是它所要解决的问题(至少短期内不是)。针对这个问题大家目前都还是依赖各自的 Vendor 平台去实现，开源界暂时也没有一个成熟统一的解决方案。

尽管 Collector 很友好的支持导出数据至阿里云SLS，但基于公司内运维可视化需求的定制性和运营成本等多方面因素，我们决定在这基础上自己实现一个完整的可观测性解决方案，用于解决之后数据分析、存储、展示的问题。

数据分析

如何处理 Collector 上传的海量数据，是该可观测性方案的核心内容。这些数据作为元数据主要用于实现以下两个服务:

业务可视化

应用可视化，包括应用拓扑、应用性能、应用链路、应用资源等
集群可视化，包括集群健康、集群资源、集群状态等
日志可视化，包括日志查询、日志分析等
 ...
复制代码

监控告警

 应用业务监控
 基础运维监控
 异常根因分析和定位
  ...
复制代码

这些服务在及时性、关联性上都有较强的需求，那么数据处理的吞吐率、准确性和灵活度也就显示十分重要。基于这些因素，我们采用了 Flink 作为数据处理分析的基础平台，同时针对特殊需求做了对应改进

配置的动态更新，采用 Flink 的 Broadcast 机制，实现各类配置的近实时获取、更新
规则引擎，以配置的形式自定义 Flink 的 Task 算子规则，支持 Jobmanger 动态管理(Update、Start、Cancel) Task
SQL API，在数据计算上封装 Flink 最上层的 SQL API，通过常见的 Sql 语法定义计算逻辑，简单、通用、学习成本低
K8s 云原生部署，Jobmanger 能根据 Task 动态管理(Apply、Destroy) Resource 资源

数据展示

数据经由 Flink 实时计算处理完成后，通过 Flink 的 Sink 对外输出并存储。这些数据的存储分为三部分:

Elasticsearch，主要用于存储前端业务可视化常用的聚合数据，起到数据缓存的效果
Cassandra，超高的写性能和高效的压缩策略适合存储原数据，这部分数据数据量庞大且使用频率超低，仅需支持简单查询即可
Kafka，主要用于存储告警事件和新增计算聚合数据，前者作为告警通知服务的原数据，后者作为流计算的原数据

Elasticsearch 作为一个分布式的搜索引擎，其特有的全文搜索、快速查询、复杂聚合、高可用等优点，让我们选择它作为数据展示的底座，在其上面构建一个 OpenAPI 服务 Otel-Dashboard，用于读取和再聚合 Elasticsearch 数据提供给各业务前端使用。

总结

政采云Otel作为一个完整的云原生监控运维可观测性方案，采用 Opentelemetry 作为数据基础设施，利用其提供的丰富工具集快速构建数据采集服务；同时在解决 OpenTelemetry 的局限性时，充分发挥了其提供的标准化统一数据模型规范的优势。

所有服务组件都实现了容器化部署并提供了相应的 Helm Charts 包，之后我们将提供 Otel 的完整部署方案以及简单快捷的接入方式。

【参考文献】

微信公众号

文章同步发布，政采云技术团队公众号，欢迎关注

基于OpenTelemetry构建云原生可观测性平台

背景