Collector的配置和使用

简介: Collector的配置和使用

目录

Collector配置

collector通过pipeline处理service中启用的数据。pipeline由接收遥测数据的组件构成,包括:

其次还可以通过扩展来为Collector添加功能,但扩展不需要直接访问遥测数据,且不是pipeline的一部分。扩展同样可以在service中启用。

Receivers

receiver定义了数据如何进入OpenTelemetry Collector。必须配置一个或多个receiver,默认不会配置任何receivers。

下面给出了所有可用的receivers的基本例子,更多配置可以参见receiver文档

receivers:
opencensus:
address: "localhost:55678"
zipkin:
address: "localhost:9411"
jaeger:
protocols:
grpc:
thrift_http:
thrift_tchannel:
thrift_compact:
thrift_binary:
prometheus:
config:
scrape_configs:
- job_name: "caching_cluster"
scrape_interval: 5s
static_configs:
- targets: ["localhost:8889"]

Processors

Processors运行在数据的接收和导出之间。虽然Processors是可选的,但有时候会建议使用Processors。

下面给出了所有可用的Processors的基本例子,更多参见Processors文档

processors:
attributes/example:
actions:
- key: db.statement
action: delete
batch:
timeout: 5s
send_batch_size: 1024
probabilistic_sampler:
disabled: true
span:
name:
from_attributes: ["db.svc", "operation"]
separator: "::"
queued_retry: {}
tail_sampling:
policies:
- name: policy1
type: rate_limiting
rate_limiting:
spans_per_second: 100

Exporters

exporter指定了如何将数据发往一个或多个后端/目标。必须配置一个或多个exporter,默认不会配置任何exporter。

下面给出了所有可用的exporters的基本例子,更多参见exporters文档

exporters:
opencensus:
headers: {"X-test-header": "test-header"}
compression: "gzip"
cert_pem_file: "server-ca-public.pem" # optional to enable TLS
endpoint: "localhost:55678"
reconnection_delay: 2s
logging:
loglevel: debug
jaeger_grpc:
endpoint: "http://localhost:14250"
jaeger_thrift_http:
headers: {"X-test-header": "test-header"}
timeout: 5
endpoint: "http://localhost:14268/api/traces"
zipkin:
endpoint: "http://localhost:9411/api/v2/spans"
prometheus:
endpoint: "localhost:8889"
namespace: "default"

Service

Service部分用于配置OpenTelemetry Collector根据receivers, processors, exporters, 和extensions sections的配置会启用那些特性。service分为两部分:

  • extensions
  • pipelines

extensions包含启用的扩展,如:

service:
extensions: [health_check, pprof, zpages]

Pipelines有两类:

  • metrics: 采集和处理metrics数据
  • traces: 采集和处理trace数据

一个pipeline是一组 receivers, processors, 和exporters的集合。必须在service之外定义每个receiver/processor/exporter的配置,然后将其包含到pipeline中。

注:每个receiver/processor/exporter都可以用到多个pipeline中。当多个pipeline引用processor(s)时,每个pipeline都会获得该processor(s)的一个实例,这与多个pipeline中引用receiver(s)/exporter(s)的情况不同(所有pipelines仅能获得receiver/exporter的一个实例)。

下面给出了一个pipeline配置的例子,更多可以参见pipeline文档

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

Extensions

Extensions可以用于监控OpenTelemetry Collector的健康状态。Extensions是可选的,默认不会配置任何Extensions。

下面给出了所有可用的extensions的基本例子,更多参见extensions文档

extensions:
health_check: {}
pprof: {}
zpages: {}

使用环境变量

collector配置中可以使用环境变量,如:

processors:
attributes/example:
actions:
- key: "$DB_KEY"
action: "$OPERATION"

Collector的使用

下面使用官方demo来体验一下Collector的功能

本例展示如何从OpenTelemetry-Go SDK 中导出trace和metric数据,并将其导入OpenTelemetry Collector,最后通过Collector将trace数据传递给Jaeger,将metric数据传递给Prometheus。完整的流程为:

-----> Jaeger (trace)
App + SDK ---> OpenTelemtry Collector ---|
-----> Prometheus (metrics)

部署到Kubernetes

k8s目录中包含本demo所需要的所有部署文件。为了简化方便,官方将部署目录集成到了一个makefile文件中。在必要时可以手动执行Makefile中的命令。

部署Prometheus operator

git clone https://github.com/coreos/kube-prometheus.git
cd kube-prometheus
kubectl create -f manifests/setup
# wait for namespaces and CRDs to become available, then
kubectl create -f manifests/

可以使用如下方式清理环境:

kubectl delete --ignore-not-found=true -f manifests/ -f manifests/setup

等待prometheus所有组件变为running状态

# kubectl get pod -n monitoring
NAME                                   READY   STATUS    RESTARTS   AGE
alertmanager-main-0                    2/2     Running   0          16m
alertmanager-main-1                    2/2     Running   0          16m
alertmanager-main-2                    2/2     Running   0          16m
grafana-7f567cccfc-4pmhq               1/1     Running   0          16m
kube-state-metrics-85cb9cfd7c-x6kq6    3/3     Running   0          16m
node-exporter-c4svg                    2/2     Running   0          16m
node-exporter-n6tnv                    2/2     Running   0          16m
prometheus-adapter-557648f58c-vmzr8    1/1     Running   0          16m
prometheus-k8s-0                       3/3     Running   0          16m
prometheus-k8s-1                       3/3     Running   1          16m
prometheus-operator-5b469f4f66-qx2jc   2/2     Running   0          16m

使用Makefile

下面使用makefile部署Jaeger,Prometheus monitor和Collector,依次执行如下命令即可:

# Create the namespace
make namespace-k8s
# Deploy Jaeger operator
make jaeger-operator-k8s
# After the operator is deployed, create the Jaeger instance
make jaeger-k8s
# Then the Prometheus instance. Ensure you have enabled a Prometheus operator
# before executing (see above).
make prometheus-k8s
# Finally, deploy the OpenTelemetry Collector
make otel-collector-k8s

等待observability命名空间下的Jaeger和Collector的Pod变为running状态

# kubectl get pod -n observability
NAME                              READY   STATUS    RESTARTS   AGE
jaeger-7b868df4d6-w4tk8           1/1     Running   0          97s
jaeger-operator-9b4b7bb48-q6k59   1/1     Running   0          110s
otel-collector-7cfdcb7658-ttc8j   1/1     Running   0          14s

可以使用make clean-k8s命令来清理环境,但该命令不会移除命名空间,需要手动删除命名空间:

kubectl delete namespaces observability

配置OpenTelemetry Collector

完成上述步骤之后,就部署好了所需要的所有资源。下面看一下Collector的配置文件

为了使应用发送数据到OpenTelemetry Collector,首先需要配置otlp类型的receiver,它使用gRpc进行通信:

...
otel-collector-config: |
    receivers:
      # Make sure to add the otlp receiver.
      # This will open up the receiver on port 55680.
      otlp:
        endpoint: 0.0.0.0:55680
    processors:
 ...

上述配置会在Collector侧创建receiver,并打开55680端口,用于接收trace。剩下的配置都比较标准,唯一需要注意的是需要创建Jaeger和Prometheus exporters:

...
exporters:
jaeger_grpc:
endpoint: "jaeger-collector.observability.svc.cluster.local:14250"
prometheus:
endpoint: 0.0.0.0:8889
namespace: "testapp"
...
OpenTelemetry Collector service

配置中另外一个值得注意的是用于访问OpenTelemetry Collector的NodePort

apiVersion: v1
kind: Service
metadata:
...
spec:
ports:
- name: otlp # Default endpoint for otlp receiver.
port: 55680
protocol: TCP
targetPort: 55680
nodePort: 30080
- name: metrics # Endpoint for metrics from our app.
port: 8889
protocol: TCP
targetPort: 8889
selector:
component: otel-collector
type:
NodePort

该service 会将用于访问otlp receiver的30080端口与cluster node的55680端口进行绑定,这样就可以通过静态地址<node-ip>:30080来访问Collector。

运行代码

main.go文件中可以看到完整的示例代码。要运行该代码,需要满足Go的版本>=1.13

# go run main.go
2020/10/20 09:19:17 Waiting for connection...
2020/10/20 09:19:17 Doing really hard work (1 / 10)
2020/10/20 09:19:18 Doing really hard work (2 / 10)
2020/10/20 09:19:19 Doing really hard work (3 / 10)
2020/10/20 09:19:20 Doing really hard work (4 / 10)
2020/10/20 09:19:21 Doing really hard work (5 / 10)
2020/10/20 09:19:22 Doing really hard work (6 / 10)
2020/10/20 09:19:23 Doing really hard work (7 / 10)
2020/10/20 09:19:24 Doing really hard work (8 / 10)
2020/10/20 09:19:25 Doing really hard work (9 / 10)
2020/10/20 09:19:26 Doing really hard work (10 / 10)
2020/10/20 09:19:27 Done!
2020/10/20 09:19:27 exporter stopped

该示例模拟了一个正在运行应用程序,计算10秒之后结束。

查看采集到的数据

运行go run main.go的数据流如下:

Jaeger UI

Jaeger上查询trace内容如下:

Prometheus

运行main.go结束之后,可以在Prometheus中查看该metric。其对应的Prometheus target为observability/otel-collector/0

Prometheus上查询metric内容如下:

FAQ:

  • 在运行完部署命令之后,发现Prometheus没有注册如http://10.244.1.33:8889/metrics这样的target。可以查看Prometheus pod的日志,可能是因为Prometheus没有对应的role权限导致的,将Prometheus的clusterrole修改为如下内容即可:
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: prometheus-k8s
namespace: monitoring
rules:
- apiGroups: [""]
resources: ["services","pods","endpoints","nodes/metrics"]
verbs: ["get", "watch", "list"]
- apiGroups: ["extensions"]
resources: ["ingresses"]
verbs: ["get", "watch", "list"]
- nonResourceURLs: ["/metrics"]
verbs: ["get", "watch", "list"]
  • 在运行"go run main.go"时可能会遇到rpc error: code = Internal desc = grpc: error unmarshalling request: unexpected EOF这样的错误,通常因为client和server使用的proto不一致导致的。client端(即main.go)使用的proto文件目录为go.opentelemetry.io/otel/exporters/otlp/internal/opentelemetry-proto-gen,而collector使用proto文件目录为go.opentelemetry.io/collector/internal/data/opentelemetry-proto-gen,需要比较这两个目录下的文件是否一致。如果不一致,则需要根据collector的版本为main.go生成对应的proto文件(或者可以直接更换collector的镜像,注意使用的otel/opentelemetry-collector的镜像版本)。在collector的proto目录下可以看到对应的注释和使用的proto版本,如下:

    collector使用的proto git库为opentelemetry-proto。clone该库,切换到对应版本后,执行make gen-go即可生成对应的文件。
Component Maturity
Binary Protobuf Encoding
collector/metrics/* Alpha
collector/trace/* Stable
common/* Stable
metrics/* Alpha
resource/* Stable
trace/trace.proto Stable
trace/trace_config.proto Alpha
JSON encoding
All messages Alpha

相关实践学习
深入解析Docker容器化技术
Docker是一个开源的应用容器引擎,让开发者可以打包他们的应用以及依赖包到一个可移植的容器中,然后发布到任何流行的Linux机器上,也可以实现虚拟化,容器是完全使用沙箱机制,相互之间不会有任何接口。Docker是世界领先的软件容器平台。开发人员利用Docker可以消除协作编码时“在我的机器上可正常工作”的问题。运维人员利用Docker可以在隔离容器中并行运行和管理应用,获得更好的计算密度。企业利用Docker可以构建敏捷的软件交付管道,以更快的速度、更高的安全性和可靠的信誉为Linux和Windows Server应用发布新功能。 在本套课程中,我们将全面的讲解Docker技术栈,从环境安装到容器、镜像操作以及生产环境如何部署开发的微服务应用。本课程由黑马程序员提供。 &nbsp; &nbsp; 相关的阿里云产品:容器服务 ACK 容器服务 Kubernetes 版(简称 ACK)提供高性能可伸缩的容器应用管理能力,支持企业级容器化应用的全生命周期管理。整合阿里云虚拟化、存储、网络和安全能力,打造云端最佳容器化应用运行环境。 了解产品详情: https://www.aliyun.com/product/kubernetes
目录
相关文章
|
2月前
|
存储 运维 安全
别再把 Collector 当黑箱:OpenTelemetry Collector 拓展与自定义处理器实战指南
别再把 Collector 当黑箱:OpenTelemetry Collector 拓展与自定义处理器实战指南
205 14
|
存储 Web App开发 JSON
OpenTelemetry Log规范解读
本文主要介绍OpenTelemetry Log规范,这一规范来自于Google、Microsoft、AWS、Splunk、DataDog、ES、Fluntd等众多优秀的公司和项目成员,其中有很多点是我们在平时开发、运维需要关注的知识和经验,值得大家一观。
7441 0
OpenTelemetry Log规范解读
|
Prometheus Kubernetes 负载均衡
Opentelemetry collector用法
本文详细介绍了Opentelemetry Collector的使用方法及其各个组件(receiver、processor、exporter、connector和服务配置)的功能与配置。Collector的核心组件通过官方仓库提供丰富的实现,涵盖了认证、健康监控等功能。
2146 63
Opentelemetry collector用法
|
3月前
|
运维 Prometheus 监控
监控体系大一统:OpenTelemetry 就是运维人的“鸿蒙”
监控体系大一统:OpenTelemetry 就是运维人的“鸿蒙”
434 10
|
Arthas 监控 Java
拥抱 OpenTelemetry:阿里云 Java Agent 演进实践
本文介绍了阿里云 Java Agent 4.x 版本在基于 OTel Java Agent 二次开发过程中的实践与思考,并重点从功能、性能、稳定性、兼容性四个方面介绍了所做的工作。同时也介绍了阿里云可观测团队积极参与开源建设取得的丰厚成果。
1295 109
拥抱 OpenTelemetry:阿里云 Java Agent 演进实践
|
9月前
|
JSON 监控 Java
日志与追踪的完美融合:OpenTelemetry MDC 实践指南
日志与追踪的完美融合:OpenTelemetry MDC 实践指南
761 24
|
数据采集 Prometheus 运维
基于LoongCollector构建全新可观测Pipeline
LoongCollector是阿里云推出的下一代可观测数据管道,旨在融合多种采集技术,构建统一的可观测数据代理。它具备高性能、可靠性和灵活性,支持日志、指标和追踪等多类型数据采集。通过模块化设计和SPL处理引擎,LoongCollector实现了高效的数据处理与传输,并大幅简化了配置管理。此外,集成eBPF技术,提供无侵入、高性能的应用性能监控,适用于复杂异构环境。未来,LoongCollector将继续优化性能、探索AI赋能的智能化采集。
|
11月前
|
Arthas 监控 Java
拥抱 OpenTelemetry:阿里云 Java Agent 演进实践
拥抱 OpenTelemetry:阿里云 Java Agent 演进实践
549 0
|
Prometheus 监控 Cloud Native
Prometheus中的Exporter详解
【10月更文挑战第25天】Prometheus Exporter分为直接采集(如cAdvisor, Kubernetes)和间接采集(如Node Exporter)两类。
|
Prometheus Cloud Native Java
OpenTelemetry: 经得起考验的工具
OpenTelemetry: 经得起考验的工具
2231 2

热门文章

最新文章