DigitalOcean 的 Prometheus 实践：从 OpenTSDB 迁移到拉取模型

概述

DigitalOcean 是一家提供简化云计算服务的公司，其基础设施规模庞大。在采用 Prometheus 之前，他们面临着传统监控栈（基于推送模型的 OpenTSDB 与 Graphite）带来的运维负担和扩展性挑战。本文根据 Prometheus 官方博客的访谈，总结了 DigitalOcean 将核心监控系统从 OpenTSDB 迁移到 Prometheus 的动因、过程、收益以及未来的思考。这一案例深刻体现了 model-pull 与推送模型在可靠性、可控性和团队自助能力上的差异，是 SRE 实践中可观测性工具选型和演进的经典范例。

核心概念

本次迁移的核心驱动力在于对 控制权 和 可靠性 的重新审视。

  1. 指标风暴：在推送模型中，由应用主动向中央监控系统（如 OpenTSDB）发送指标数据。一个设计不佳或异常的应用可能发送过量数据（“话多”），瞬间耗尽监控系统的容量，导致所有监控数据采集受阻，进而影响 SRE 对全站可靠性的感知和 SLA 保障。
  2. 拉取模型的优势：Prometheus 采用的model-pull将控制权从应用侧转移到了监控系统侧。SRE 团队可以精确控制：
    • 采集目标：决定拉取哪些服务的指标（通过服务发现或静态配置）。
    • 采集频率：根据服务的可靠性和重要性设置不同的抓取间隔。 这种模式从根本上避免了指标风暴的威胁，使 SRE 能够更好地履行其保障 SLA 的职责。
  3. 指标语义与可聚合性：与 Graphite 的点分隔名称（如 servers.web-01.cpu.idle）不同，Prometheus 的指标模型要求预先定义指标名称和标签。这种结构化的数据模型迫使开发者在创建指标时就考虑未来的聚合和查询需求，从而避免了因命名结构混乱导致的后期分析困难。

实践

DigitalOcean 的迁移并非一蹴而就，而是采取了渐进式、工具赋能的策略。

  1. 并行部署与实验：在保持现有 Collectd + OpenTSDB 系统运行的同时，DigitalOcean 并行部署了 node-exporter，开始收集主机级指标到 Prometheus。这使得团队能够在低风险环境下实验和验证 Prometheus 的能力。
  2. 构建自定义 Exporter：为了覆盖其专有 Droplet 服务的指标，DigitalOcean 的团队（主要使用 Go 语言）利用 Prometheus 客户端库创建了自定义 Exporter。由于 Prometheus 指标模型简单，且 Go 生态支持良好，这个过程比维护 OpenTSDB 的集成更高效、更易被开发团队接受。
  3. 功能对等与切换：当 Prometheus 集群具备了原 OpenTSDB 系统的所有关键指标采集功能后，他们开始逐步停用 Collectd，最后完全关闭了 OpenTSDB 集群。
  4. 转向自服务模式：迁移后，Prometheus 的易用性和强大的可视化工具迅速吸引了大量团队使用。为避免指标团队成为瓶颈，他们没有选择集中式托管，而是转向构建工具和文档，赋能各业务团队自行部署和管理自己的 Prometheus 实例，运行公司内部常用的 Exporter。这显著提升了整体的可观测性覆盖速度。

SRE 要点

与可靠性、可观测性、事件响应的关联

  • 可靠性：采用拉取模型是提升监控系统本身可靠性的关键决策。SRE 掌控了数据采集的主动权，消除了外部应用对监控系统稳定性的不可控影响。
  • 可观测性：自服务模式极大扩展了可观测性的边界。各团队能快速、灵活地为自己负责的服务建立监控，使得之前因资源或流程瓶颈无法获得的洞察力得以实现。
  • 事件响应：更丰富、更结构化的指标（尤其是自定义 Exporter 提供的）和更灵活的告警规则（使用 Prometheus 的 PromQL），使得团队能够更精确地定义告警，快速定位问题根源，缩短 MTTR。

最佳实践与常见反模式

  • 最佳实践：
    • 渐进式迁移：并行运行新旧系统，验证功能后再切换，降低风险。
    • 赋能而非集中：为团队提供工具和自助平台，而非成为唯一的监控服务提供方。
    • 投资于 Exporter 生态：鼓励并简化团队创建自定义 Exporter，以获取深度的业务上下文指标。
    • 利用 Prometheus 的原生优势：充分利用 PromQL 的表达能力和 Alertmanager 的能力，而不仅仅是将其作为另一个时序数据库。
  • 反模式：DigitalOcean 早期面临的 OpenTSDB 的指标风暴问题，正是推送模型中“缺乏背压和流量控制”的典型反模式。这提醒 SRE 在设计监控系统时，必须考虑其自身的弹性边界和隔离性。

相关指标（SLI/SLO/SLA）

迁移间接帮助 DigitalOcean 更好地管理其内部 SLA。通过拉取模型，SRE 团队（如 Ian Hansen 所在的平台指标团队）能够：

  • 定义更精细的 SLI：基于自己可控采集的数据，定义更准确的服务水平指标（例如，特定 Hypervisor 的性能指标）。
  • 保障监控系统的 SLO：可以为监控系统本身设定 SLO（如数据采集成功率、查询延迟），并因拉取模型而更容易实现。
  • 间接保障业务 SLA：可靠的监控是保障业务 SLA 的前提。避免指标风暴确保了告警和容量规划系统在最需要它们的时候不会失效。

未来方向与反思

DigitalOcean 的实践展示了 Prometheus 的核心价值：通过简单的架构和强大的数据模型，赋予团队自主权，从而加速整个组织对基础设施的洞察。他们未来的重点是进一步降低使用门槛，让 Prometheus 尽可能“自动化”，使团队能专注于查询和告警逻辑，而非基础设施运维。同时，他们开发了 vulcan（一个基于 Prometheus 的长期存储方案），以解决 Prometheus 本地存储在长期数据保留上的限制，同时保留其强大的查询语言生态。这反映了可观测性栈演进中的一个常见挑战：如何在灵活性、功能和运维复杂度之间取得平衡。