Grafana OnCall 服务指标采集兼容性问题分析与解决方案

问题背景

Grafana OnCall 是一款开源的告警管理平台，它提供了 Prometheus 格式的指标导出功能。然而，在实际使用过程中，用户发现当使用 Telegraf 采集 OnCall 服务的 /metrics/ 端点时，会遇到 HTTP 406 Not Acceptable 错误。

问题分析

现象描述

当 Telegraf 尝试采集 OnCall 服务的指标时，服务端返回 406 状态码，表示无法接受客户端请求的内容类型。具体表现为：

1. 使用 Telegraf 默认配置采集时失败
2. 手动使用 curl 模拟 Telegraf 的 Accept 头时同样失败
3. 直接使用 curl 不带特殊头时则能成功获取指标

根本原因

OnCall 服务的 /metrics/ 端点对 Accept 头的处理存在限制。Telegraf 默认会发送包含多种内容类型的 Accept 头，其中包括：

application/vnd.google.protobuf;proto=io.prometheus.client.MetricFamily;encoding=delimited;q=0.7,text/plain;version=0.0.4;q=0.3

而 OnCall 服务端仅接受简单的 text/plain 或 application/json 类型，导致当客户端发送复杂的 Accept 头时，服务端返回 406 错误。

Prometheus 兼容性考虑

虽然 OnCall 的指标端点返回的是标准的 Prometheus 文本格式（Content-Type: text/plain; version=0.0.4），但其对 Accept 头的处理却不如标准 Prometheus 服务灵活。标准的 Prometheus 服务通常能够处理各种 Accept 头组合，而 OnCall 的实现则较为严格。

解决方案

临时解决方案

对于使用 Telegraf 的用户，可以通过修改 Telegraf 配置来解决此问题：

[[inputs.prometheus]]
  urls = ["http://localhost:8080/metrics/"]
  http_headers = {"Accept" = "text/plain,application/json"}

这个配置显式指定了 Accept 头，避免了发送 Telegraf 默认的复杂内容类型组合。

长期建议

从产品完善的角度，建议 Grafana OnCall 服务改进其指标端点的实现：

1. 放宽对 Accept 头的限制，至少接受包含 text/plain 的任何组合
2. 保持与标准 Prometheus 服务的兼容性，正确处理各种常见的内容类型协商
3. 在文档中明确说明指标端点的兼容性要求

技术启示

这个案例展示了在实现监控指标端点时需要注意的几个重要方面：

1. 内容协商：指标端点应该灵活处理各种 Accept 头，特别是当声称兼容某种标准（如 Prometheus）时
2. 兼容性测试：不仅要测试功能本身，还要测试与常见采集工具（如 Telegraf、Prometheus server 等）的交互
3. 配置灵活性：采集工具通常提供覆盖默认行为的选项，了解这些选项能帮助解决兼容性问题

通过这个问题的分析和解决，用户不仅能够临时绕过采集问题，也能更深入地理解监控数据采集过程中内容协商的重要性。