OpenTelemetry环境搭建和工作原理
一、背景
opentelemetry它作为可观测性的标准实现,尤其是调用链跟踪的实现。如果需要在生产环境上使用,一般都是部署在kubernetes平台上提供服务。本文将指导用户如何搭建otel环境,以及配置重点的分析。
二 、简介
otle collector是一种供应商无关的接收、处理和导出遥测数据的方式。我们主要将otel-collector部署运行起来。
可能大家会有疑问,为什么不直接将数据发送到可观测性后端?而是通过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 包: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)
按照官方的说法,总共有三种部署形态。
-
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,提供了指标,调用链跟踪等信息
六、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
·
- 点赞
- 收藏
- 关注作者
评论(0)