opentelemetry、grafana、Prometheus、jaeger、victoria-metrics 介绍、关系与使用

最新推荐文章于 2025-06-25 11:27:35 发布

原创最新推荐文章于 2025-06-25 11:27:35 发布 · 3.5k 阅读

9 ·

CC 4.0 BY-SA版权

文章标签：

#grafana #prometheus

本文介绍了OpenTelemetry，一个CNCF的可观测性项目，关注数据模型、采集与处理。文章详细讲解了Tracing、Metrics和Logging的基本概念，以及如何通过Docker和docker-compose部署OpenTelemetryCollector，以及其与Jaeger、Prometheus、Grafana和VictoriaMetrics的集成应用。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

Opentelemetry

OTEL 是 OpenTelemetry 的简称，是 CNCF 的一个可观测性项目，旨在提供可观测性领域的标准化方案，解决观测数据的数据模型、采集、处理、导出等的标准化问题，提供与三方 vendor 无关的服务。
OpenTelemetry 是一组标准和工具的集合，旨在管理观测类数据，如 Traces、Metrics、Logs 等 (未来可能有新的观测类数据类型出现)。目前已经是业内的标准。
在这里插入图片描述

1. 三个基本概念

1.1 Tracing

opentelemetry可以将trace的数据发送到jaeger去
Tracing 提供了从请求开始接收到处理完毕的整个生命周期的全貌。使用span最为跟踪数据，生成信息（元数据）
在这里插入图片描述

obs-opentelemetry 实现了什么:

- 支持在 hertz 服务端和客户端之间启用 http 链路追踪
- 支持通过设置 http header 以启动自动透明地传输对端服务

使用示例

package main

import (
    "github.com/cloudwego/hertz/pkg/app/server"
    hertztracing "github.com/hertz-contrib/obs-opentelemetry/tracing"
)

func main() {
    tracer, cfg := hertztracing.NewServerTracer()
    h := server.Default(tracer)
    h.Use(hertztracing.ServerMiddleware(cfg))
    // ...
    h.Spin()
}

1.2 Metric

简单说，cpu、内存、运行时候的信息，可以==通过Prometheus+导出器搞定 ==（发过去）

度量指标（Metric）包含了各种各样的方法和实现。

Metric 包括了追踪样本以及自动将指标与产生它们的追踪样本联系起来。手动将指标和追踪联系起来往往是一项繁琐且容易出错的任务。OpenTelemetry 自动执行这项任务将为运维人员节省大量的时间。
在这里插入图片描述

grafana与Prometheus
Grafana是一个开源的可视化平台，用于创建、查询和展示时序数据的仪表盘和图表。它支持多种数据源，其中包括Prometheus。Grafana提供了丰富的可视化选项和灵活的仪表盘配置，可以根据需求创建各种类型的监控指标图表。借助Grafana，用户可以通过图表、面板和警报来监视和分析数据，并以直观和易于理解的方式展示。
因此，Prometheus是一个用于收集和分析时间序列数据的监测系统，而Grafana是一个用于可视化和展示这些数据的工具。两者可以结合使用，使用户能够实时监控系统的性能、状态和指标，并通过仪表盘和图表直观地展示这些数据。
obs-opentelemetry 实现了什么:R.E.D (Rate, Errors, Duration) 定义了架构中的每个微服务测量的三个关键指标。OpenTelemetry 可以根据http.server.duration来计算R.E.D。
Rate：你的服务每秒钟所提供的请求数。
例如: QPS（Queries Per Second）每秒查询率

sum(rate(http_server_duration_count{}[5m])) by (service_name, http_method)

Error：每秒失败的请求数。

例如：错误率

sum(rate(http_server_duration_count{status_code="Error"}[5m])) by (service_name, http_method) / 
sum(rate(http_server_duration_count{}[5m])) by (service_name, http_method)

Duration
例如：P99 Latency

histogram_quantile(0.99, sum(rate(http_server_duration_bucket{}[5m])) by (le, service_name, http_method))

1.3 Logging

opentelemetry 发送到rockeyMQ等
在 logrus 的基础上适配了 hertz 日志工具
实现了链路追踪自动关联日志的功能

三种常用log：Log:语言内置，logrus，zap

2. 实现

2.1 docker-compose 部署依赖 && otel-collector 配置文件

docker-compse

version: "3.7"
services:

#  # Collector
  otel-collector:
    image: otel/opentelemetry-collector-contrib-dev:latest
    command: [ "--config=/etc/otel-collector-config.yaml", "${OTELCOL_ARGS}" ]
    volumes:
      - ./otel-collector-config.yaml:/etc/otel-collector-config.yaml
    ports:
      - "1888:1888"   # pprof extension
      - "8888"   # Prometheus metrics exposed by the collector
      - "8889:8889"   # Prometheus exporter metrics
      - "13133:13133" # health_check extension
      - "4317:4317"   # OTLP gRPC receiver
      - "55679" # zpages extension
    depends_on:
      - jaeger-all-in-one

  # Jaeger
  jaeger-all-in-one:
    image: jaegertracing/all-in-one:latest
    environment:
      - COLLECTOR_OTLP_ENABLED=true
    ports:
      - "16686:16686"
      - "14268"
      - "14250:14250"
      - "6831:6831"
    #  - "4317:4317"   # OTLP gRPC receiver

  # Victoriametrics
  victoriametrics:
    container_name: victoriametrics
    image: victoriametrics/victoria-metrics
    ports:
      - "8428:8428"
      - "8089:8089"
      - "8089:8089/udp"
      - "2003:2003"
      - "2003:2003/udp"
      - "4242:4242"
    command:
      - '--storageDataPath=/storage'
      - '--graphiteListenAddr=:2003'
      - '--opentsdbListenAddr=:4242'
      - '--httpListenAddr=:8428'
      - '--influxListenAddr=:8089'
    restart: always

  # Grafana
  grafana:
    image: grafana/grafana:latest
    environment:
      - GF_AUTH_ANONYMOUS_ENABLED=true
      - GF_AUTH_ANONYMOUS_ORG_ROLE=Admin
      - GF_AUTH_DISABLE_LOGIN_FORM=true
    ports:
      - "3000:3000"

otel-collector-config.yml

receivers:
  otlp:
    protocols:
      grpc:

exporters:
  prometheusremotewrite:
    endpoint: "http://victoriametrics:8428/api/v1/write"

  logging:
  
  otlp:
    endpoint: jaeger-all-in-one:4317
    tls:
      insecure: true


processors:
  batch:

extensions:
  health_check:
  pprof:
    endpoint: :1888
  zpages:
    endpoint: :55679

service:
  extensions: [ pprof, zpages, health_check ]
  pipelines:
    traces:
      receivers: [ otlp ]
      processors: [ batch ]
      exporters: [ logging, otlp ]
    metrics:
      receivers: [ otlp ]
      processors: [ batch ]
      exporters: [ logging, prometheusremotewrite ]

2.2 OTLP(OpenTelemetry Protocol )

OTLP（全称 OpenTelemetry Protocol ）是 OpenTelemetry 原生的遥测信号传递协议，虽然在 OpenTelemetry 的项目中组件支持了Zipkin v2或Jaeger Thrift的协议格式的实现，但是都是以第三方贡献库的形式提供的。只有 OTLP 是 OpenTelemetry 官方原生支持的格式。OTLP 的数据模型定义是基于 ProtoBuf 完成的，如果你需要实现一套可以收集 OTLP 遥测数据的后端服务，那就需要了解里面的内容，对应可以参考代码仓库：opentelemetry-proto（https://github.com/open-telemetry/opentelemetry-proto）

otel-collector-config 中指定接收器部分，定义了数据如何被接收。在这里配置了 otlp 接收器，使用 gRPC 协议进行通信。

receivers:
  otlp:
    protocols:
      grpc:

2.3 Opentelemetry-Collector

OpenTelemetry Collector （以下简称“otel-collector”）针对如何接收、处理和导出遥测数据提供了与供应商无关的实现。它消除了运行、操作和维护多个代理/收集器的需要，以支持将开源可观察性数据格式（例如 Jaeger、Prometheus 等）发送到一个或多个开源或商业后端。此外，收集器让最终用户可以控制他们的数据。收集器是默认位置检测库导出其遥测数据。
在这里插入图片描述

docker中的部署

version: "3.7"
services:

#  # Collector
  otel-collector:
    image: otel/opentelemetry-collector-contrib-dev:latest
    command: [ "--config=/etc/otel-collector-config.yaml", "${OTELCOL_ARGS}" ]
    volumes:
      - ./otel-collector-config.yaml:/etc/otel-collector-config.yaml
    ports:
      - "1888:1888"   # pprof extension
      - "8888"   # Prometheus metrics exposed by the collector
      - "8889:8889"   # Prometheus exporter metrics
      - "13133:13133" # health_check extension
      - "4317:4317"   # OTLP gRPC receiver
      - "55679" # zpages extension
    depends_on:
      - jaeger-all-in-one

2.4 otel-exporter、service

exporters:

  prometheusremotewrite:
    endpoint: "http://victoriametrics:8428/api/v1/write"

  logging:

  otlp:
    endpoint: jaeger-all-in-one:4317
    tls:
      insecure: true
...
service:
  extensions: [ pprof, zpages, health_check ]
  pipelines:
    traces:
      receivers: [ otlp ]
      processors: [ batch ]
      exporters: [ logging, otlp ] # 通过otlp导出给jaeger
    metrics:
      receivers: [ otlp ]
      processors: [ batch ]
      exporters: [ logging, prometheusremotewrite ]

exporters:
导出器部分，定义了数据如何被导出。在这里配置了三个导出器，分别是 prometheusremotewrite 、logging、通过otlp导出到jaeger。
prometheusremotewrite 导出器用于将指标数据导出到远程写入的 Prometheus 实例，而 logging 导出器将数据打印到日志中。
OTLP（OpenTelemetry Protocol）导出器，它将数据导出到指定的 endpoint 中。在这里，endpoint 被配置为 jaeger-all-in-one:4317，即使用 jaeger-all-in-one 全部集成的 Jaeger 实例作为终端节点。此外，还配置了一个 tls 字段，表示该导出器是否启用 TLS/SSL 加密传输。
service：
服务部分，定义了整个服务的配置。在这里配置了使用的扩展以及数据的流程。其中 pipelines 部分定义了多个数据流程，包括 traces 和 metrics。每个数据流程都有对应的接收器、处理器和导出器。

2.5 opentelemetry、grafana、Prometheus、jaeger、victoria-metrics 之间关系

OpenTelemetry、Grafana、Prometheus、Jaeger和VictoriaMetrics 是在观测性和监控领域中使用的一些工具，它们可以相互配合使用以提供全面的监控和观测能力。

OpenTelemetry：OpenTelemetry 是一个开源的观测性框架，用于在分布式系统中收集、处理和导出跟踪数据、指标数据和日志数据。它提供了一组库和工具，使开发人员能够在应用程序中插入代码以生成和导出数据，以便进行分析和监控。
Grafana：Grafana 是一个流行的开源数据可视化工具，用于创建、查询和可视化各种数据源中的监控指标、日志和其他数据。Grafana 提供了丰富的可视化选项和仪表板功能，使用户能够根据需要自定义显示和分析数据。
Prometheus：Prometheus 是一个开源的系统监控和警报工具，用于收集和存储时间序列数据。它具有内置的数据模型和查询语言，可对指标进行高效的存储和查询。Prometheus 支持各种数据源的数据采集，并和Grafana配合使用，可以创建实时监控仪表板，并进行数据可视化和警报。
Jaeger：Jaeger 是一个开源的分布式追踪系统，用于收集、存储和查询分布式应用程序的跟踪数据。它可以帮助开发人员理解应用程序中的服务调用关系和性能瓶颈。Jaeger 与 OpenTelemetry 配合使用，提供了对分布式跟踪数据的收集和展示功能。
VictoriaMetrics：VictoriaMetrics 是一个高性能、开源的时间序列数据库和监控系统，在处理大规模时间序列数据时表现出色。它兼容 Prometheus 的数据模型和查询语言，并提供了高度可扩展的存储和查询能力。可以将其作为 Prometheus 的后端存储，用于长期存储和检索时间序列数据。（可以代替Prometheus斜体样式）

综上所述，OpenTelemetry 用于收集、处理和导出观测性数据，Prometheus 和 VictoriaMetrics 用于存储和查询时间序列数据，Grafana 用于将数据进行可视化展示，而 Jaeger 则用于收集和展示分布式追踪数据。这些工具可以相互配合使用，以构建全面的监控和观测解决方案。