将OpenTelemetry跟踪与Prometheus连接

操作跟踪提供深入了解在 graph 中的各种执行点所发生的性能问题。但是，单个跟踪不能提供对您 graph 更广博性能的看法。

便于的是，您可以将 操作跟踪转换为聚合度量，而不需要手动配置。为了实现这一点，我们将使用 spanmetricsprocessor 中的 OpenTelemetry Collector 实例来自动生成我们现有的跟踪跨度指标。

OpenTelemetry Collector 配置

OpenTelemetry 为其 OpenTelemetry Collector 提供两个不同的仓库

• 以下为 核心库
• 以下为 贡献者库

这两个仓库在范围上相似，但贡献者库包括核心库中不适合的扩展功能。要从一个现有的跨度中提取性能度量，我们将使用贡献者库利用 spanmetricsprocessor 通过相关的 Docker 镜像。

当您的 OpenTelemetry Collector 准备运行时，您可以开始通过以下裸骨示例配置它

1
receivers:
2
  otlp:
3
    protocols:
4
      grpc:
5
      http:
6
        cors:
7
          allowed_origins:
8
            - http://*
9
            - https://*
10
  otlp/spanmetrics:
11
    protocols:
12
      grpc:
13
        endpoint: 0.0.0.0:12346
14

15
exporters:
16
  prometheus:
17
    endpoint: '0.0.0.0:9464'
18

19
processors:
20
  batch:
21
  spanmetrics:
22
    metrics_exporter: prometheus
23

24
service:
25
  pipelines:
26
    traces:
27
      receivers: [otlp]
28
      processors: [spanmetrics, batch]
29
    metrics:
30
      receivers: [otlp/spanmetrics]
31
      exporters: [prometheus]
32
      processors: [batch]

Apollo 服务器配置

按照 Apollo Server 和 OpenTelemetry 文档中所示的指导，添加 OTLP 导出器（@opentelemetry/exporter-trace-otlp-http Node 软件包）。

GraphOS 路由器配置

要将图OS可路由器中的跟踪发送到OpenTelemetry收集器，请参阅这篇文章。

设置 Prometheus

最后，我们需要将OpenTelemetry收集器作为Prometheus中的一个目标。它将使用Prometheus指标的标准端口（9464）。

这样就对了 - 你应该可以使用相同的操作名称访问跨度度量！

示例查询

以下是几个样本查询，以帮助探索报告的数据结构：

• P95按服务：histogram_quantile(.95, sum(rate(latency_bucket[5m])) by (le, service_name))
• 按服务和操作（例如router / graphql.validate）平均延迟：sum by (operation, service_name)(rate(latency_sum{}[1m])) / sum by (operation, service_name)(rate(latency_count{}[1m]))
• 按服务查询率：sum(rate(calls_total{operation="HTTP POST"}[1m])) by (service_name)

完整演示

要看到实际操作效果，请查看使用具有OpenTelemetry-Collector特定Docker Compose镜像的Supergraph演示存储库。