稳固基石 - Prometheus 与 Alertmanager 运维考量

稳固基石 - Prometheus 与 Alertmanager 运维考量

当我们把 Prometheus 和 Grafana 组合投入实际使用后，很快就会遇到一些现实问题：单个 Prometheus 服务器会不会成为瓶颈或单点故障？指标数据存储久了磁盘会不会爆？Alertmanager 挂了收不到告警怎么办？这一篇，我们就来探讨这些关键的运维问题。

Prometheus Server 运维考量

1. 资源规划 (Resource Planning)

Prometheus Server 在运行时对资源有一定要求：

• CPU 与内存 (CPU & Memory)：

  • 指标抓取 (Scraping)、规则评估 (Rule evaluation)、PromQL 查询以及数据写入都会消耗 CPU。
  • 内存主要用于缓存最近的指标数据 (TSDB head block) 以加速查询和写入。
  • 关键影响因素：监控目标的数量、抓取频率、时间序列的基数 (cardinality - 即不同标签组合的数量)、告警规则和查询的复杂度。
  • 建议：持续监控 Prometheus Server 自身的 CPU 和内存使用率（可以用另一个 Prometheus 实例来监控它，或者使用 node_exporter 暴露的指标），并根据实际情况调整资源分配。

• 磁盘 (Disk - TSDB)：

  • IOPS 与吞吐量: Prometheus 的时序数据库 (TSDB) 会频繁地进行写操作（存储新样本）和读操作（响应查询、评估规则）。为了获得最佳性能，强烈建议为 Prometheus 的数据目录使用高速的本地 SSD。
  • 存储容量与保留策略: 需要根据抓取间隔、时间序列数量以及期望的数据保留时长（通过启动参数 --storage.tsdb.retention.time 配置，默认为 15 天）来规划磁盘容量。Prometheus 的本地 TSDB 主要为近期（数周或数月）的运营监控数据做了优化&