前言
Prometheus/Zabbix告警可以让运维人员知道发生了什么故障？
可观测性平台的建立是让开发/运维人员知道发生了什么故障？ 故障导致的根因？ 进而根据故障根因，采取正确的紧急预案措施；
想要实现以上目标就需要构建1个可观测性平台；
一、可观测性平台概念
可观测性(Observability)是指针对1个复杂的系统；
能够通过监控、日志(Logs)、指标(Metrics)、微服务调用链接追踪(Traces)3类遥测数据，快速地发现故障根因的平台。
如何做到在1个复杂系统中快定位故障根因？
需要通过手动/自动/EBPF无侵入埋点的方式采集到丰富的遥测数据，结合业务需求从不同纬度出发对遥测数据进行Tag打标，使采集到的Metrics、Traces、Logs具有关联性，才能从Traces层面开始不断向下深入分析，最终定位到故障根因。
Opentelemetry
Opentelemetry是一套由CNCF主导的可观测性的标准框架，统一了可观测性数据采集的标准；
Opentelemetry可以实现对遥测数据的生成、采集、处理、传输，但不对遥测数据进行存储；
Opentelemetry的优势在于对遥测数据采集、传输规范的统一；
- 遥测数据数据生成、采集、传输规范的制定
- 遥测数据传输协议的统一
- 多语言遥测数据采集SDK的实现 用户可以使用SDK进行代码自动注入和手动埋点，同时对其他三方库（Log4j、LogBack等）进行集成支持
- 数据收集系统的实现，包括Agent和Collector。
二、OpenTelemetry架构
OpenTelemetry是1个开源的观测框架，用于收集、处理和导出应用程序的指标（Metrics）、分布式追踪（Traces） 和 日志（Logs）。
OpenTelemetry提供了用于采集、传输、接收、处理、导出数据的工具链，并支持在不同的后端系统中进行存储和分析。
它的架构可以分为几层，涵盖了从数据收集到导出的各个环节。以下是 OpenTelemetry 的典型物理架构组
1. Instrumentation层（数据采集）
Instrumentation是OpenTelemetry采集数据的起点，主要包括以下内容：
-
OpenTelemetry API：
- OpenTelemetry 提供了标准化的 API，开发者可以在应用代码中调用这些 API 来生成观测数据。API 定义了如何创建追踪、指标等数据类型，确保应用程序可以在不同语言和框架中一致地生成数据。
-
OpenTelemetry SDK：
- SDK 是 API 的实现部分，它负责采集、处理和发送观测数据。通过使用 OpenTelemetry SDK，开发者可以实现更加细致的配置，例如控制追踪的采样率、指标的刷新频率等。
- SDK 支持多种语言，包括 Java、Python、JavaScript、Go 等，确保不同语言的应用程序都能集成 OpenTelemetry。
-
自动化探针（Auto-instrumentation Probes）：
- OpenTelemetry 提供了一些自动化探针，帮助用户无需修改代码即可为常见的框架和库（例如 HTTP 客户端、数据库连接池等）采集数据。自动化探针会注入到应用的依赖库中，自动捕获请求、响应等信息。
- 这些探针通常与 OpenTelemetry SDK 配合使用，可以动态附加到应用中，从而减少对原始代码的改动。
-
Agent（代理）：
- Agent 在应用所在节点上运行，与 SDK 配合，作为数据采集的辅助工具。Agent 负责将 SDK 采集到的观测数据进一步收集和预处理，并发送给 OpenTelemetry Collector 或直接发送到后端。
Instrumentation 层的工作流程
- 观测数据生成：应用程序在运行过程中，API 和 SDK 采集分布式追踪、指标和日志数据。自动化探针帮助自动捕获特定服务调用的观测数据。
- 数据缓冲和初步处理：SDK 在本地对数据进行缓冲和简单的预处理，例如采样和聚合。
- 数据转发到 Agent：在Instrumentation层完成初步采集后，数据通过SDK传递给 Agent，由 Agent 进一步处理和传输到 Collect
2. OpenTelemetryCollector（数据收集、处理、导出）
OpenTelemetry Collector是整个架构的核心组件，负责在不同的采集源和后端之间传递数据。
OpenTelemetry Collector通常部署为独立服务，可以分布式地运行在多个节点上。Collector 主要分为3个部分：
- Receiver（接收器）：从 SDK、Agent 或其他源接收数据。支持多种协议，如 HTTP、gRPC 等。
- Processor（处理器）：在数据发送到后端之前，处理和增强数据。可以进行聚合、过滤、批量处理等操作。
- Exporter（导出器）：将处理后的数据导出到后端系统，如 Prometheus、Jaeger、Zipkin 或其他存储系统。
Collector 可以运行在多种环境下，比如独立的虚拟机、Kubernetes 集群中的 Pod 或边缘计算节点中。Collector 的灵活性使其能够适应不同的网络拓扑和性能需求。
3. 后端系统（数据存储和分析）
OpenTelemetry 将采集和处理后的数据导出到后端系统，用于存储、分析和可视化。通常，后端系统可以包含以下几个部分：
- 存储：数据可以存储在数据库（如 Elasticsearch）或时序数据库（如 Prometheus）中，以便进行长时间的存储和查询。
- 分析工具：例如 Jaeger 和 Zipkin，可以用于查看分布式追踪信息；Prometheus 和 Grafana，可以用于查看监控指标。
- 日志系统：比如 Loki 或其他日志管理系统，用于集中化存储和查询应用的日志。
OpenTelemetry 的物理架构中，Instrumentation层用于数据采集，Collector 用于数据聚合和处理，最终将数据发送到后端系统用于存储和分析。这种架构支持灵活的部署方式，并能在不同规模和复杂性的系统中运行，有助于实现统一的可观测性。
三、OpenTelemetry部署模式
OpenTelemetry的常见部署模式主要依赖于应用的规模、分布和所需的性能要求。
下面列出了一些常见的OpenTelemetry部署模式，包括在不同环境中的应用和部署方式：
1. 单一应用直接集成模式
在这种模式下，应用程序直接集成 OpenTelemetry SDK 并将数据发送到后端系统或 OpenTelemetry Collector。
适用场景：
- 小型应用或单一服务，不涉及复杂的分布式架构。
- 低延迟和简单的监控需求，应用程序能够直接处理数据的转发。
部署流程：
- 应用集成 OpenTelemetry SDK。
- 应用直接将采集到的数据发送到 OpenTelemetry Collector，或者直接导出到后端（如 Jaeger、Prometheus 等）。
优势：
- 部署最简单，不需要额外的代理或中间层。
- 没有多余的组件，减少了维护成本。
劣势：
- 难以应对大规模、复杂的分布式系统，可能会影响应用性能。
- 缺乏集中管理，所有配置和数据转发都必须在每个应用中处理。
2. Agent + Collector模式
在这种模式下，应用程序通过 OpenTelemetry SDK 生成数据，然后由本地 Agent 收集数据并转发到 OpenTelemetry Collector 或后端存储。
适用场景：
- 大规模分布式应用，尤其适用于 Kubernetes 和云原生环境。
- 集中管理数据和配置，提升可维护性。
部署流程：
- 应用集成 OpenTelemetry SDK。
- 应用通过 SDK 生成的数据发送到本地运行的 Agent（通常部署在与应用相同的节点或容器中）。
- Agent 收集和缓存数据，并将其发送到 OpenTelemetry Collector 或直接转发到后端存储（如 Jaeger、Prometheus、Elasticsearch）。
优势：
- 数据采集与转发解耦，应用程序仅负责生成数据。
- 可以集中管理 Agent 配置，提高可扩展性。
- Agent 可以对数据进行缓冲、批处理和优化，减轻后端负担。
劣势：
- 引入了额外的代理层，增加了系统的复杂性和资源消耗。
- 需要管理和配置 Agent 和 Collector。
3. Sidecar 模式（Kubernetes 环境）
Sidecar 模式 适用于 Kubernetes 等容器化环境，通常在每个应用实例旁边部署一个 Agent，以便在容器或 Pod 内部进行数据采集和转发。
适用场景：
- Kubernetes 或容器化环境，尤其适合微服务架构。
- 每个应用实例都需要独立的监控和数据采集。
部署流程：
- 在 Kubernetes 中，每个 Pod 会运行一个 Sidecar 容器，该容器内包含 OpenTelemetry Agent。
- Sidecar 容器负责收集应用程序数据并将其发送到 OpenTelemetry Collector 或后端。
- 通过 Kubernetes 的 Pod 和 Service 网络模型，Sidecar 容器与主应用容器共享网络资源，可以非常方便地进行数据采集。
优势：
- 解耦应用程序和数据采集逻辑，简化开发过程。
- 每个应用实例都有自己的数据采集和处理代理，灵活性高。
- 可以利用 Kubernetes 的 DaemonSet 或 Pod 模式灵活扩展。
劣势：
- 每个应用实例都需要运行一个代理容器，增加了资源消耗。
- 配置和管理多个 Sidecar 容器可能会带来运维复杂度。
4. DaemonSet 模式（Kubernetes 环境）
在 Kubernetes 中，DaemonSet 模式 部署一个 OpenTelemetry Agent，在每个节点上运行一个代理实例。它可以收集集群中所有 Pod 的数据，并将数据发送到 OpenTelemetry Collector 或后端。
适用场景：
- Kubernetes 集群中需要对所有节点或服务进行统一的监控和数据采集。
- 节点级别的监控和数据收集，而不仅仅是应用级别。
部署流程：
- 使用 DaemonSet 在每个节点上部署一个 OpenTelemetry Agent。
- 每个 Agent 负责收集本节点上运行的所有应用的观测数据，并将其发送到 OpenTelemetry Collector 或后端系统。
优势：
- 集中式监控，适合集群环境中的大规模监控。
- 节点级别的数据收集，无需在每个 Pod 内部运行独立的代理容器。
- 便于集中管理和监控整个集群的健康状况。
劣势：
- 每个节点都需要运行一个 Agent，增加了节点的负担。
- 对于复杂的多租户环境，可能需要额外的隔离和资源管理。
5. OpenTelemetry Collector 集中式模式
在这种模式下，多个应用实例通过本地 Agent 或直接通过 SDK 向一个集中式的 OpenTelemetry Collector 发送数据，Collector 进行集中处理和导出。
适用场景：
- 中央化管理监控数据，适合大规模系统。
- 集中式的数据处理、转换和导出。
部署流程：
- 每个应用实例通过 SDK 或 Agent 发送数据到集中式的 OpenTelemetry Collector。
- Collector 负责接收来自多个应用的观测数据，进行处理、转换、聚合等操作，并将其导出到最终的后端系统（如 Prometheus、Jaeger、ElasticSearch 等）。
优势：
- 中央化管理，易于扩展和维护。
- 可以集中处理数据的采样、转换、合并等操作。
- 降低后端系统负担，减少各应用直接与后端通信的复杂性。
劣势：
- 集中式架构可能成为单点故障（SPOF），需要高可用性和负载均衡策略。
- 收集到的数据量可能较大，Collector 的处理能力需要足够强大。
6. 分布式 OpenTelemetry Collector 模式
分布式 Collector 模式适用于跨多个区域或多个数据中心的环境，在这种模式下，多个 Collector 实例在不同位置运行，并分担数据的接收和处理任务。
适用场景：
- 多区域、大规模分布式系统，尤其适合跨地域的数据采集和传输。
- 提高系统的容错性和数据处理的分布式能力。
部署流程：
- 在不同的地理位置或数据中心部署多个 OpenTelemetry Collector 实例。
- 应用通过 Agent 或直接 SDK 将数据发送到本地的 Collector。
- 本地 Collector 将处理后的数据汇总并最终导出到集中的后端系统。
优势：
- 降低延迟，增强地理分布式系统的数据采集能力。
- 提供更高的可用性和容错性。
- 分担集中 Collector 的负载，适应大规模分布式系统。
劣势：
- 管理和配置更为复杂，可能需要更多的资源。
- 可能需要额外的负载均衡和数据同步策略。
7.总结
常见的OpenTelemetry 部署模式包括：
- 单一应用集成模式：适用于简单、小型应用，直接将数据发送到后端。
- Agent+Collector模式：适合大规模系统，通过 Agent 缓解后端压力，集中管理数据采集。
- Sidecar模式：适合 Kubernetes 环境，解耦应用和监控代理。
- DaemonSet模式：Kubernetes 环境下，集群节点级别的监控。
- 集中式Collector模式：所有数据都发送到集中式 Collector，便于处理和管理。
- 分布式 Collector模式：适用于跨地域的大规模分布式环境，提供高可用性和低延迟的数据采集。
每种模式都有其适用的场景，选择合适的模式能够帮助实现更高效、可扩展的观测体系。
