OpenTelemetry环境搭建和工作原理

举报
可以交个朋友 发表于 2024/02/29 10:20:58 2024/02/29
【摘要】 opentelemetry它作为可观测性的标准实现,尤其是调用链跟踪的实现。如果需要在生产环境上使用,一般都是部署在kubernetes平台上提供服务。本文将指导用户如何搭建otel环境,以及配置重点的分析。

一、背景

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


二 、简介

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

可能大家会有疑问,为什么不直接将数据发送到可观测性后端?而是通过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
    image.png

    image.png

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


  1. 通过helm安装
    a. 添加helm仓库
    helm repo add open-telemetry https://open-telemetry.github.io/opentelemetry-helm-charts
    b. 用 search 命令来搜索可以安装的 chart 包: helm search repo open-telemetry
    image.png
    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
    image.png

    image.png

安装完成✅


四、部署形态介绍

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

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


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


  3. Gateway形态
    image.png
    在一般情况下,使用开箱即用的负载均衡器(比如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
image.png

image.png

访问demo后,可以查看grafana和jaegerUI,提供了指标,调用链跟踪等信息
image.png
image.png
image.png
image.png


六、otel配置结构分析

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

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

·

【版权声明】本文为华为云社区用户原创内容,转载时必须标注文章的来源(华为云社区)、文章链接、文章作者等基本信息, 否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。