Grafana与外部AlertManager连接泄漏问题分析与缓解

概述

本文档详细阐述了一个在 Grafana（特别是 9.x 版本）使用统一告警（Unified Alerting）功能向外部 Prometheus AlertManager 发送通知时出现的严重资源泄漏问题。该问题导致 Grafana 与 AlertManager 之间建立的 TCP 连接未被正确关闭，随着告警通知的持续发送，连接数不断累积，最终耗尽操作系统或 Grafana 服务设定的文件描述符（file descriptor）上限，导致 Grafana 服务崩溃，告警通知失败。此问题对监控系统的可靠性构成了直接威胁，是 SRE 在运维 Grafana 和 Prometheus 告警栈时需要高度关注并掌握缓解方法的关键场景。

核心概念

连接泄漏（Connection Leak）：指应用程序（如 Grafana）打开了网络连接（例如 HTTP 请求），但在使用完毕后没有正确关闭（close）该连接，导致其占用的系统资源（如文件描述符、内存）未被释放。泄漏的连接会持续存在于系统的 TCP 连接表中，直至被操作系统回收（通常需要很长时间）。
TCP 连接状态 ESTABLISHED：表示连接已成功建立并正在传输数据或等待应用层协议操作。在本案中，泄漏的连接会一直保持此状态。
文件描述符（File Descriptor）：在 Unix/Linux 系统中，所有 I/O 操作（网络套接字、文件等）都通过文件描述符进行。每个打开的网络连接都占用一个文件描述符。当文件描述符使用量达到系统（ulimit）或服务（如 Grafana 的 LimitNOFILE）设定的上限时，新的 I/O 操作将失败，表现为 “too many open files” 错误。
HTTP 连接池：HTTP 客户端（如 Grafana 使用的）通常会维护一个连接池，以复用已建立的 TCP 连接，避免为每次请求都重新进行 TCP 握手，从而提升性能。此问题可能源于 Grafana 的特定 HTTP 客户端配置或实现缺陷，导致连接未被有效复用或归还到连接池。

实践

问题现象确认

观察连接数：使用 netstat 或 ss 命令持续监控 Grafana 进程与 AlertManager（默认端口 9093）之间的连接数。
```
watch -n 10 'netstat -antp | grep grafana | grep 9093 | wc -l'
```
问题环境下，该数字会随时间（特别是有告警通知时）持续增长，直至数千甚至上万。
检查系统日志与 Grafana 日志：关注 Grafana 日志中出现的 “too many open files” 错误。这些错误通常在连接数接近上限时开始出现，并导致告警发送失败和 Grafana 功能异常。

缓解与排查步骤

虽然此问题被确认为 Grafana 9.x 的缺陷，但在等待官方修复的同时，可采取以下措施进行缓解：

临时提高系统限制：作为紧急措施，可以临时提高 Grafana 服务进程的文件描述符限制。
- 编辑 Grafana 的 systemd 服务文件（通常位于 /etc/systemd/system/grafana-server.service 或 /usr/lib/systemd/system/grafana.service）。
- 找到 [Service] 部分下的 LimitNOFILE 参数，将其值调大（例如设为 65536）。
- 重载 systemd 配置并重启 Grafana 服务：
```
sudo systemctl daemon-reload
sudo systemctl restart grafana-server
```
注意：这只是一个临时的缓解措施，无法从根本上解决连接泄漏问题，但能为系统争取更多恢复时间。
（高级）尝试配置连接池参数：有社区成员报告，通过在 Grafana 的数据源配置文件 datasource.yml 或 UI 中，为告警管理器（AlertManager）数据源的 JSON 数据字段添加以下配置，有助于控制连接行为：
```
jsonData:
  handleGrafanaManagedAlerts: true
  implementation: prometheus
  # 尝试添加以下参数，以控制连接池和超时
  httpMethod: POST
  timeoutSeconds: 30
```
此配置并非官方推荐解决方案，效果可能因环境而异，但值得尝试。
监控与告警：建立对 Grafana 服务文件描述符使用情况的监控。可以配置一个简单的告警规则，当 Grafana 进程的打开文件描述符数量超过某个阈值（如总限制的 70%）时告警，以便在问题发生前介入。

SRE 要点

可靠性关联：此问题直接导致核心监控组件 Grafana 的不可用，进而影响整个告警通道的畅通，是典型的由资源泄漏引发的可靠性事件。SRE 必须将其视为高优先级问题。
可观测性与事件响应：
- 可观测性：需要同时观测 Grafana 应用日志（错误信息）、操作系统指标（文件描述符使用率、TCP 连接状态）以及网络流量。
- 事件响应：当因 too many open files 导致 Grafana 告警或服务故障时，响应步骤应包括：1) 确认问题（查看日志和连接数）；2) 实施临时缓解（提高 LimitNOFILE）；3) 排查并确认根本原因（连接泄漏）；4) 制定长期修复计划（如升级 Grafana 到已修复版本）。
最佳实践与反模式：
- 最佳实践：定期升级 Grafana 至稳定版，以获取安全补丁和缺陷修复；对关键服务（如 Grafana、Prometheus）进行资源使用基线建模和告警。
- 反模式：仅通过无限提高系统限制（ulimit）来“解决”资源耗尽问题，而忽略根本原因；对监控工具本身的可靠性缺乏监控（盲区）。
相关指标（SLI/SLO）：
- SLI：可以定义 “Grafana 告警通知成功率” 或 “Grafana 服务 HTTP 请求成功率（不包括 5xx 错误）” 作为可靠性指标。当发生此类连接泄漏导致通知失败时，这些 SLI 会显著恶化。
- SLO：基于上述 SLI 设定目标，例如 “月度告警通知成功率 > 99.9%”。此故障会导致 SLO 亏损。
- Error Budget：此事件应计入 Error Budget 的消耗。通过分析此类事件，可以驱动对 Grafana 架构或运维流程的改进，如建立更完善的预发布测试用例以覆盖长时间运行下的连接稳定性。