从传统时序数据库迁移至 Prometheus：Compose 的实践

概述

Compose 是一家为开发者提供生产级数据库集群服务的公司，其业务遍布多个云平台和区域。随着业务增长，其监控系统面临了性能与可靠性的双重挑战。在尝试了 Graphite 和 InfluxDB 后，Compose 选择迁移到 Prometheus，最终实现了一个更可靠、更易管理且具有高扩展潜力的监控系统。本文基于 Prometheus 官方博客对 Compose 的访谈，详细阐述了其监控系统的演进历程与迁移实践，为 SRE 团队在选择和迁移监控基础设施时提供了宝贵的参考。

核心概念

在 Compose 的案例中，有几个关键概念对于理解其迁移决策和架构至关重要：

  • 拉取式（Pull-based）指标收集：Prometheus 的核心范式之一。由监控服务器主动从目标端点（Targets）拉取（Scrape）指标数据，而非由应用主动推送。这种方式简化了应用配置，使得监控基础设施的拓扑更易于理解和管理。Compose 最初对此感到困惑，但很快认识到了其优势。
  • Telegraf 聚合：为了优化在高度容器化环境下的监控，Compose 使用了 Telegraf 作为指标聚合代理。每个主机上的 Telegraf 负责收集该主机自身以及其上运行的所有容器的指标，并将其统一暴露为一个 Prometheus 抓取目标（Scrape Target）。这极大地减少了 Prometheus 需要管理的抓取目标数量。
  • 基于文件的服务发现（file_sd_config）：Prometheus 的动态服务发现机制。Compose 编写了一个 Ruby 脚本，通过 Chef API 获取所有主机列表并写入配置文件。Prometheus 则通过 file_sd_config 机制自动发现并抓取这些新加入或变更的主机，实现了与配置管理工具的无缝集成。
  • 高可用性（HA）与故障转移：为了消除单点故障，Compose 采用了双活冗余架构。部署两个完全相同的 Prometheus 实例抓取相同的目标，并通过 Keepalived 配合 DNS 更新实现简单的故障转移。这比他们之前使用的 InfluxDB 集群更为可靠。

实践

Compose 的迁移过程是分步进行、逐步验证的，展示了如何将一个成熟的监控理念落地到复杂的生产环境中。

1. 初始部署与动态发现

作为一家 Chef 晋级的公司，他们首先利用社区 Chef Cookbook 快速部署了一个带有大容量 EBS 存储的 Prometheus 实例。接着，他们编写了一个小型 Ruby 脚本，利用 Chef API 获取所有主机信息，并动态生成 Prometheus 的目标配置文件。通过配置 file_sd_config，Prometheus 能够自动发现并开始抓取所有已注册到 Chef 的主机，无需手动维护静态目标列表。

2. 利用 Telegraf 解决容器监控问题

每个主机上运行着数百个容器，为每个容器单独配置抓取目标不切实际。Compose 采用的策略是，在每个主机上部署 Telegraf。Telegraf 被配置为导出该主机的整体资源指标以及所有容器的内存使用等指标。最终，Prometheus 只需抓取每个主机上的一个 Telegraf 端点，即可获得所有必要数据，架构简洁高效。

3. 验证单实例的扩展能力

在正式切换前，他们有意让单个 Prometheus 实例承载了整个基础设施的负载进行压力测试。令人惊讶的是，这个 m4.xlarge 规格的实例以 15 秒的抓取间隔，稳定地监控了约 450 台主机、40，000 个容器产生的超过 400，000 个不同指标，且资源消耗很低。磁盘 I/O（1TB gp2 EBS）被认为是长期的潜在瓶颈。这次验证给予了团队极大的信心。

4. 实现高可用并切换流量

确认 Prometheus 的稳定性和性能远超原 InfluxDB 集群后，他们增加了第二个相同的 Prometheus 实例，抓取相同的目标集。通过 Keepalived 和 DNS 更新实现主备故障转移，构建了比之前更可靠的高可用架构。随后，他们将客户面向的图表系统切换到 Prometheus 数据源，并下线了旧的监控系统。

SRE 要点

从 SRE 的视角审视 Compose 的案例，可以提炼出以下关键经验与实践：

  • 可靠性提升：从存在数据损坏风险、需要定期清理的 InfluxDB，迁移到更稳定的 Prometheus，监控系统本身的可靠性得到了质的飞跃。双实例 HA 架构进一步保障了监控数据的连续性，这对于依赖监控进行故障判断和决策的 SRE 团队至关重要。
  • 可观测性增强：迁移不仅解决了稳定性问题，还为增强系统可观测性打开了大门。Compose 计划未来集成数据库内部指标和 Mesos 集群组件指标，目标是构建从负载均衡器到应用指标的中央化全景仪表盘。这体现了监控从“能看”到“看清全貌”的演进。
  • 事件响应与团队文化：一个稳定可靠的监控系统能够提升团队信心。Compose 提到，团队成员从“小心翼翼地对待旧系统”变为“兴奋地探索新用法”。这种积极的文化转变直接有利于事件的快速发现、诊断和复盘。
  • 最佳实践：
    • 小范围验证，逐步扩展：先用单实例验证核心功能与性能，确认可行后再考虑 HA 和分片。
    • 利用聚合降低复杂度：通过 Telegraf 等代理聚合主机上的所有容器指标，是大规模容器环境下的一种高效模式。
    • 与现有工具链集成：利用 Chef 和 file_sd_config 实现自动化发现，减少了配置漂移和运维负担。
  • 常见反模式与规避：Compose 的经历警示我们，在选择监控工具时，不能只关注功能承诺，必须重视其长期稳定性与运维成本。他们因 InfluxDB 的不稳定和功能承诺未兑现而迁移，这是一个典型的反模式案例。
  • 相关指标：此次迁移的规模和成效可通过具体指标体现：监控目标从不稳定变为由单实例稳定承载 450 台主机、40，000 个容器、400，000+ 个不同指标；抓取频率为 15 秒；硬件成本控制在 单台 m4.xlarge 实例加 1TB EBS。这些量化数据为评估 Prometheus 的性能容量提供了重要参考。

展望未来，Compose 需要规划的 SRE 工作是 Prometheus 的分片（Sharding）。他们计划按集群部署独立的 Prometheus 实例，并可能保留一个全局集群，通过 recording-rules 对来自各集群的降采样聚合指标进行长期存储和跨集群查询，以平衡查询灵活性和系统可扩展性。