观测云接收 OpenTelemetry Collector 数据最佳实践

OpenTelemetry 简介

如果你在做系统运维或开发,建设可观测性必然是近年来一个少不了的课题,同时相信你对 OpenTelemetry 也一定不陌生。OpenTelemetry 提供了一个统一、开放且不受特定厂商限制的标准和工具集,使得我们可以一次性集成 OTel SDK,全面采集应用的指标、日志和链路追踪数据,并自由地将数据发送到任何支持 OTel 协议的后端。

观测云

观测云是一个统一实时监测平台,它提供全面的系统可观测性解决方案,可以帮助我们快速实现对云平台、云原生、应用及业务的监控需求。观测云的核心功能包括:基础设施监测,日志采集和分析,用户访问监测(RUM),应用性能监测(APM),服务可用性监测(拨测),安全检测(SIEM),智能监控等等。

更多信息可以访问观测云官网:www.guance.com

DataKit 统一数据采集器

DataKit 是观测云的统一数据采集器,能够全面采集各类可观测数据。通过丰富的插件生态和简单的配置,DataKit 可以灵活部署在各种操作系统和容器环境中,高效地将数据发送至观测云平台,从而快速构建一个统一、完整的可观测性体系。

DataKit 采用了插件化的设计,内置了大量现成的采集插件,包括但不限于:

  • 主流的云平台,操作系统,容器平台(全面采集集群、节点、Pod、容器的性能指标和日志);
  • 主流的数据库(如 MySQL、PostgreSQL)、消息队列(如 Kafka、RabbitMQ)、Web服务器(如 Nginx、Apache)等;
  • 同时也能够接收第三方开源工具的数据,包括 StatsD、Telegraf、Prometheus 等协议,也包括 OpenTelemetry。

DataKit 接收 OpenTelemetry Collector 数据

DataKit 引进了 OpenTelemetry 设计理念,兼容 OTLP 协议,同时,也支持接收 OpenTelemetry Collector 推送的 APM 链路调用数据。在有些场景下,例如你已经通过 OpenTelemetry Collector 实现了尾部采样,这时候就可以将数据发送到 DataKit,统一在观测云中进行查看和分析。

通过 DataKit 接收 OpenTelemetry Collector 链路数据的主要流程如下:

  1. 前提条件:应用服务已经部署,并已配置 OpenTelemetry Exporter 和 Collector,从而将应用服务的链路调用即 APM 数据,通过 OTLP gRPC 或 HTTP 协议,上报到 OpenTelemetry Collector;
  2. 部署 DataKit,开启 OpenTelemetry 采集器,使用 4319 端口接收 OpenTelemetry Collector 的数据;
  3. 配置 OpenTelemetry Collector 的 Exporter config 文件,将链路数据发送到 DataKit。

主要流程如下图所示:

部署 DataKit

以 K8s 中部署为例,可以参考在线文档:docs.guance.com/datakit/dat...

开启 OpenTelemetry 采集器:

  • datakit.yamlDaemonSet 下面新增 volumeMounts
yaml 复制代码
apiVersion: apps/v1
kind: DaemonSet
metadata:
  labels:
    app: daemonset-datakit
  name: datakit
  namespace: datakit
spec:
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      app: daemonset-datakit
  template:
    metadata:
      labels:
        app: daemonset-datakit
    spec:
      hostNetwork: true
      dnsPolicy: ClusterFirstWithHostNet
      containers:
      ...
      volumeMounts:
        - mountPath: /usr/local/datakit/conf.d/opentelemetry/opentelemetry.conf
          name: datakit-conf
          subPath: opentelemetry.conf
      ....
  • datakit.yamlConfigMap data 下新增 opentelemetry.conf
ini 复制代码
apiVersion: v1
kind: ConfigMap
metadata:
  name: datakit-conf
  namespace: datakit
data:
    opentelemetry.conf: |-
        [[inputs.opentelemetry]]
            [inputs.opentelemetry.grpc]
            trace_enable = true
            metric_enable = true
            addr = "0.0.0.0:4319" 
            [inputs.opentelemetry.http]
            enable = false
            http_status_ok = 200
  • 重启 DataKit

更多详细信息,可以参考:docs.guance.com/integration...

部署和配置 Opentelemetry Collector

1. 安装 Collector

可参考 OpenTelemetry 官方文档:opentelemetry.io/docs/collec...

2. config.yaml 配置

/etc/otelcol/config.yaml 配置文件详情:

Opentelemetry Collector 配置文件定义了 Receivers 的来源、Processors 并发数据配置、以及 Exporters 导出的端点。此处主要关注:

  • Receivers:定义接收来自应用服务的 Opentelemetry gRPC/HTTP 服务监听
  • Exporters:定义了数据转发到标准 otlp 的后端,即 DataKit

config.yaml 参考示例:

yaml 复制代码
receivers:
  otlp:
    protocols: # 接收 Java 代理数据的协议和端口,按实际需要配置
      grpc:
        endpoint: 0.0.0.0:4317 
      http:
        endpoint: 0.0.0.0:4318

processors:
  batch:  # 批处理提高性能
    timeout: 1s
    send_batch_size: 1000
  resource:  # 添加额外标签的处理器
    attributes:
      - key: environment
        value: production
        action: insert

exporters:
  otlp:
    endpoint: "127.0.0.1:4319"   # datakit 暴露的 otel-endpoint,端口为 4319
    tls:
      insecure: true
    compression: none # 不开启gzip

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch, resource]
      exporters: [otlp]

重载 systemd 并启动 otelcol 服务:

bash 复制代码
systemctl daemon-reload
systemctl enable otelcol
systemctl restart otelcol

更多详细信息,可以参考:docs.guance.com/best-practi...

3. 安装验证

验证 Collector 是否正常运行:

bash 复制代码
systemctl status otelcol  # 检查服务状态
journalctl -u otelcol -f  # 查看日志

数据正常上报后,在观测云中可以查看应用性能监测的链路数据:

总结

通过 DataKit 接收 OpenTelemetry Collector 的应用链路数据,可以帮助我们快速实现一个灵活的可观测性数据管理体系。我们既可以利用 OpenTelemetry 的标准化能力,统一采集各种可观测数据,又可以利用 DataKit 强大的数据处理和集成功能,将这些数据统一传输到观测云平台,充分利用观测云平台提供的全面分析和可视化能力,并能协同其他维度的可观测数据进行统一查询分析。

相关推荐
OpsEye2 天前
Redis 内存碎片的隐形消耗——如何用 memory purge 命令释放空间?
运维·网络·数据库·redis·缓存·内存·监控
得物技术4 天前
深度实践:得物算法域全景可观测性从 0 到 1 的演进之路
监控
盛世宏博北京5 天前
档案安全守护者:无人值守温湿度自动化管控方案
监控·档案温湿度·库房温湿度
货拉拉技术5 天前
面向可观测数据融合的 Exemplar
后端·监控
闲人编程5 天前
电商平台用户系统API设计
数据库·后端·消息队列·fastapi·监控·容器化·codecapsule
Mintopia6 天前
🤖 Sentry × AI:让系统监控拥有“大脑”的新时代
运维·人工智能·监控
Mintopia6 天前
🚀 现代化系统中的数据跟踪:Sentry 的魔法优势 ✨
前端·监控·全栈
踏浪无痕6 天前
监控不是日志:Prometheus 高基数避坑指南
后端·算法·监控
盛世宏博智慧档案7 天前
档案馆环境安全一体化解决方案 —— 聚焦 “八防十防” 与温湿度管控
监控·档案八防·十防