一、背景

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

二 、简介

otle collector是一种供应商无关的接收、处理和导出遥测数据的方式。我们主要将otel-collector部署运行起来。

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

三 、 安装otel-telemetry

提供多种安装方式，例如manifest直接安装，或者通过helm进行定制化安装

1. 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
   

   

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

2. 通过helm安装
   a. 添加helm仓库
   helm repo add open-telemetry https://open-telemetry.github.io/opentelemetry-helm-charts
   b. 用 search 命令来搜索可以安装的 chart 包： helm search repo open-telemetry
   
   c. helm install 进行安装
   helm install my-opentelemetry-collector open-telemetry/opentelemetry-collector --set mode=deployment
   这种情况下采用的默认的安装参数配置，后续修改不方便。如果需要定制化安装，可以使用如下方式：helm show values open-telemetry/opentelemetry-collector
   使用 helm show values 命令来查看一个 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）
按照官方的说法，总共有三种部署形态。

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

   ---

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

   ---

3. 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,提供了指标，调用链跟踪等信息

六、otel配置结构分析

otel-collector遥测数据的采集、处理、转发依赖我们对各内部组件的配置和启动。配置文件的结构由四大部分组成： 详细参考 https://opentelemetry.io/docs/collector/configuration/#basics

● 接收器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
  

·