近期我们对两个环境中的OpenTelemetry Collector进行了版本升级，从v0.114.0升级到了v0.121.0。这次升级涉及一些配置变化，本文将记录一些升级过程中的关键点和经验总结。
这两套环境采用了相同的部署架构:首先通过Helm安装opentelemetry-operator，然后利用OpenTelemetry Collector的CRD(自定义资源定义)创建OpenTelemetryCollector资源。opentelemetry-operator会根据这些资源定义，在Kubernetes集群的每个节点上以DaemonSet的形式部署OpenTelemetry Collector Pod，实现分布式的遥测数据采集。
OpenTelemetry Collector提供了多种方法来评估其自身的健康状况以及如何排除故障。
日志对于识别问题非常有帮助。始终从检查日志输出并查找潜在问题开始。日志的级别默认为INFO。
在配置中设置日志级别:
1service:
2 telemetry:
3 logs:
4 level: "debug"
OTEL Collector的Prometheus指标在本地通过端口8888和路径/metrics公开。并可以通过配置文件中的service.telemetry.metrics.address进行配置。
最近将一个项目的可观测性方案从Logs(ElasticSearch,Fuentbit,Kibana), Traces(Jaeger+OpenTracing)迁移到了OpenTelemetry。此项目由多个微服务组成，部署在一个Kubernetes集群中。 OpenTelemetry Collector由OpenTelemetry K8S Operator管理，并以DaemonSet的形式部署在Kubernetes集群的各个节点上。即每个K8S节点上都有一个OTEL Collector Agent进程负责收集并处理本节点上微服务Pod实例的Logs, Traces, Metrics数据，并将Logs, Traces数据发送到后端的日志存储(Loki或ES)、Traces数据存储(Jaeger或Tempo)，同时将Metrics数据暴露给Prometheus。
...