服务器监控工具 - OpenTelemetry环境搭建和工作原理 - 《DevOps 运维-自动化部署、监控等》

一、背景">一、背景
二、简介">二、简介
- manifest安装">manifest安装
- 通过helm安装">通过helm安装
四、部署形态介绍">四、部署形态介绍
五、运行otel-demo">五、运行otel-demo

opentelemetry它作为可观测性的标准实现，尤其是调用链跟踪的实现。如果需要在生产环境上使用，一般都是部署在kubernetes平台上提供服务。本文将指导用户如何搭建otel环境，以及配置重点的分析。

一、背景

二、简介

otle collector是一种供应商无关的接收、处理和导出遥测数据的方式。主要将otel-collector部署运行起来。
OpenTelemetry环境搭建和工作原理 - 图1

可能大家会有疑问，为什么不直接将数据发送到可观测性后端？而是通过otel-collector处理转发？
对于大多数开发语言都有现成的sdk库可以使用，并将可观测数据导出到可观测性后端，例如jaeger，prometheus，对于小规模集群来说，这是一种快速获得价值体现的方式。但是也不利于统一管理。
所以一般来说，建议使用otel-collector，因为它允许快速卸载数据，并且otel-collector可以进行很多操作，例如重试、批处理、加密甚至敏感数据过滤。 —- ## 三、安装otel-telemetry 提供多种安装方式，例如manifest直接安装，或者通过helm进行定制化安装

manifest安装

以下命令会在k8s集群中以daemonset形式部署otel-agent，以deployment形式部署一个otel-collector

kubectl apply -f https://raw.githubusercontent.com/open-telemetry/opentelemetry-collector/main/examples/k8s/otel-config.yaml

这种安装方式旨在作为一个起点，在实际生产使用之前进行扩展和定制测试。

通过helm安装

a. 添加helm仓库

helm repo add open-telemetry https://open-telemetry.github.io/opentelemetry-helm-charts

b. 用 search 命令来搜索可以安装的 chart 包： <font style="color:rgb(240, 141, 73);background-color:rgb(248, 248, 248);">helm search repo open-telemetry</font>
OpenTelemetry环境搭建和工作原理 - 图4

c. helm install 进行安装

helm install my-opentelemetry-collector open-telemetry/opentelemetry-collector --set mode=deployment

这种情况下采用的默认的安装参数配置，后续修改不方便。如果需要定制化安装，可以使用如下方式：

helm show values open-telemetry/opentelemetry-collector

使用 <font style="color:rgb(37, 43, 58);">helm show values</font> 命令来查看一个 chart 包的所有可配置的参数选项。可以在安装的时候通过 YAML 格式的文件来传递这些参数。

helm install -f xxx.yaml my-opentelemetry-collector open-telemetry/opentelemetry-collector

安装完成✅

四、部署形态介绍

上述安装方式中，manifests方式部署模式有otel-agent模式也有单实例的otel-collector的gateway模式。helm方式部署时mode使用的deployment模式。（可选daemonset｜deployment｜statefulset）
按照官方的说法，总共有三种部署形态。

No Collector形态

最简单的模式是不使用采集器。这种模式主要是指使用 OpenTelemetry SDK 的应用程序，直接向后端输出遥测信号（跟踪、度量、日志）
优缺点:
a. 优点
■ 使用简单，尤其是在开发测试环境中
■ 没有额外的组件需要操作
b. 缺点
■ 如果采集、处理遥测数据发生变化，则需要更改代码。
■ 应用程序和可观测后端的强耦合性
■ 不同语言导出遥测数据的限制

Agent形态

每个客户端 SDK 或下游采集器都配置一个otel-collector。收集器实例与应用程序在同一主机上运行，类似于sidecar或者daemonset方式。
工作方式大概就是，应用程序中的sdk以otlp协议发送遥测数据给otel-collector。然后otel-collector处理遥测数据对接到可观测性后端。
优缺点：
a. 优点
■ 上手简单
■ 架构清晰。应用程序和collector保持1:1的关系
b. 缺点
■ 缺乏灵活性
■ 没有扩展性

Gateway形态

在一般情况下，使用开箱即用的负载均衡器(比如nginx)在otel-collector之间分配负载。
工作方式大概是应用程序中的sdk以otlp协议发送遥测数据给负载均衡器，负载均衡器根据算法选择其中一个otel-collector实例进行处理，然后对接到可观测性后端。
注意: 目前只有trace调用链支持负载均衡
优缺点：
a. 优点
■ 关注点解藕。例如集中管理凭证。
■ 集中策略管理（例如，过滤某些日志或采样）
b. 缺点
■ 增加了维护的复杂性
■ 由于级联了otel-collecor增加了延迟
■ 总体资源使用成本增加

五、运行otel-demo

opentelemetry社区提供一套分布式微服务模拟真实的业务场景。下面部署该demo

helm install my-otel-demo open-telemetry/opentelemetry-demo

访问demo后，可以查看grafana和jaegerUI，提供了指标，调用链跟踪等信息
OpenTelemetry环境搭建和工作原理 - 图12

—- ## 六、otel配置结构分析 otel-collector遥测数据的采集、处理、转发依赖对各内部组件的配置和启动。配置文件的结构由四大部分组成：详细参考 https://opentelemetry.io/docs/collector/configuration/#basics
OpenTelemetry环境搭建和工作原理 - 图16

● 接收器receivers可以通过推送或拉取方式发送数据，是数据进入收集器collector的方式，接收器可以支持一个或多个数据源。接收器在接收器部分进行配置。许多接收器都带有默认设置，因此只需指定接收器名称即可进行配置。如果需要配置接收器或更改默认配置，可在此部分进行。指定的任何设置都会覆盖默认值（如果有的话）。采集器需要有一个或多个接收器。

● 处理器processors在接收器和导出器之间处理数据，处理器是可选的，但有些是推荐的。处理器接收接收器采集的数据，并对其进行修改或转换，然后再发送给导出器。数据处理根据为每个处理器定义的规则或设置进行，其中可能包括过滤、丢弃、重命名或重新计算遥测数据等操作。管道中处理器的顺序决定了collector对信号进行处理操作的顺序。

● 导出器exporters同样可以是基于推或拉的方式，它是将数据发送到一个或多个后端/目的地的方式，导出器可以支持一个或多个数据源。采集器需要有一个或多个导出器。

● 连接器connectors既是输出者又是接收者，顾名思义，连接器连接两个管道：它作为一个管道末端的导出器消耗数据，并作为另一个管道开始处的接收器发送数据。它可以消费和发送相同数据类型或不同数据类型的数据。连接器可以生成并发送数据来汇总所消耗的数据，或者它可以简单地复制或路由数据。

注意：配置每个组件后，必须使用配置文件service部分中的pipelines来启用这些组件。
除管道组件外，还可以配置extensions，extensions组件提供可添加到采集器的功能，如诊断工具。extensions不需要直接访问遥测数据，也需要通过service部分启用。

下面是一个采集器配置示例，包括一个接收器、一个处理器、一个导出器和三个扩展器：

receivers:
  otlp:
    protocols:
      grpc:
      http:
processors:
  batch:
exporters:
  otlp:
    endpoint: otelcol:4317
extensions:
  health_check:
  pprof:
  zpages:
service:
  extensions: [health_check, pprof, zpages]
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlp]
    metrics:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlp]
    logs:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlp]

上面介绍了四大组件。但是实际配置中还需要依赖extensions扩展器和service

● extension扩展器是可选组件，可扩展收集器的功能，以完成与处理遥测数据不直接相关的任务。例如，可以为collector提供健康监控、服务发现或数据转发等扩展。可以通过配置文件的extensions部分来配置扩展。大多数扩展都带有默认设置，因此只需指定扩展名称即可进行配置。指定的任何设置都会覆盖默认值。

extensions:
  health_check:
  pprof:
  zpages:
  memory_ballast:
    size_mib: 512

● service部分用于根据接收器、处理器、导出器和扩展部分中的配置，用于指定在collector中启用哪些组件。如果某个组件已配置，但未在服务部分中定义，则不会启用。service有三部分组成：

extensions: 用于指定启用哪些扩展器功能

service:
  extensions: [health_check, pprof, zpages]

pipelines指定启用哪些遥测数据，包括指标，日志，分布式跟踪。管道pipelines由一组接收器、处理器和输出器组成。在管道中加入接收器、处理器或输出器之前，需要提前定制好相关组件。

service:
  pipelines:
    metrics:
      receivers: [opencensus, prometheus]
      processors: [batch]
      exporters: [opencensus, prometheus]
    traces:
      receivers: [opencensus, jaeger]
      processors: [batch, memory_limiter]
      exporters: [opencensus, zipkin]

telemetry : 可以在service部分的telemetry中为收集器本身配置遥测。collector遥测在排除收集器问题时非常有用。通过logs日志部分，可以配置收集器生成的日志。默认情况下，收集器将日志写入 stderr，日志级别为 INFO,还可以使用 initial_fields 部分向所有日志添加静态键值对。metrics指标部分可配置收集器生成的指标。默认情况下，收集器会生成有关自身的基本指标，并在 http://localhost:8888/metrics 上公开这些指标以供抓取。

service:
  telemetry:
    logs:
      level: debug
      initial_fields:
        service: my-instance
    metrics:
      level: detailed
      address: 0.0.0.0:8888

OpenTelemetry环境搭建和工作原理