Bloomberg 监控系统的标准化和扩展

Bloomberg 开发团队采纳 SRE 实践后，一个显著成果体现为监控系统的改进。该系统的后台由团队部署的Metrictank 时序数据库提供支持。

Bloomberg 的基础设施横跨两个自运营数据中心中的近 200 个计算节点，服务于约 32.5 万名客户，以及一个近 5000 人的开发团队。长期以来，开发人员负责对自己构建和部署的产品进行生产监控。这种监控往往是亡羊补牢之举，进而导致缺失标准化。监控系统中存在有多种数据采集器，它们会对同一度量做重复的测量，对系统的整体也缺乏一个完整视图。据 Bloomberg 遥测负责人 Stig Sorensen 介绍，运维负责“从企业商业站点的细枝末节以及各种市场数据来源，到企业的要产品，即 Bloomberg 专业终端（Professional Terminal）。该终端是世界范围内成千上万关键影响人士所仰仗的工具”。各种不同的技术栈构成了系统的复杂性。

Sorensen 自 2016 年开始在 Bloomberg 负责 SRE （站点可靠性工程，Site Reliability Engineering）的实施。他的团队推行 SRE 原则和实践，目标是为整个企业构建监控和报警服务。团队首先推出了一种支持标签的自研StatsD 代理。该代理关注的是如何尽快从中心系统获取度量。一旦完成了度量采集，系统基于Kafka 集群完成大量的验证、聚合、规则和持久化工作。这一系统很快就面对着可扩展性的问题。Bloomberg 软件开发人员 Sean Hanson 在一次演讲中指出：

系统运行两年后，每秒需处理 250 万个数据点、1 亿个时间序列。其中一些高基数度量的值可达 50 万。我们的初始解决方案的确具有很好的可扩展性，能够扩展到每秒处理 2000 万个数据点。但在系统达到这样处理能力时，事实上我们无法从中做任何查询，并且系统在处理高基数度量时表现依然很差。高基数度量十分常见的情况。

团队构建的新系统同样面对着一系列新的需求，包括推导度量计算的函数、可配置的保留期、元数据的查询以及可扩展性。 Metrictank 是 Cassandra 推出的一种多租户时序数据库。它支持 Graphite 监控系统，适合团队的大部分需求。根据 Facebook 发表的 Gorilla 论文，Metrictank 的性能可比 Facebook 前期采用的高基数数据系统高出数个数量级。这为跨组织的度量分析铺平了道路。Bloomberg 团队对其中一些资源敏感区域做了优化，并贡献到Metritank 代码中。其它一些组织也已使用 Cassandra 作为后端，实现对 Graphite 监控系统的扩展。

Bloomberg 团队不仅更新了监控系统，而且为实现工作方式标准化而采纳了 SRE 。Sorensen 详细解释道：

当前，我们事实上不再具有一个集中的 SRE 团队，实现为 SRE 团队向应用团队看齐的方式。 SRE 团队来自于应用团队和核心基础设施团队。无论是运维人员还是系统管理员，都采用了这种方式做编程和人员变动。我们也会让应用工程师对系统和可用性提出更积极的看法，构建不同类型的软件，因为我们将 SRE 视为软件工程师正开展的事情。

随着对标准化监控系统的采纳，随之而来的一个需求是对如何追踪进度。团队正致力于其中的一些工作。Sorensen指出，由于“测定可用性不是一件非黑即白的事情。可用性并非用户在某个网站上经历了多少次失败，这是因为对于市场玩家而言，而是只要实时市场数据稍有延迟，即便是一毫秒或是几百毫秒，结果也可能会大相径庭。”

查看英文原文： Bloomberg’s Standardization and Scaling of Its Monitoring Systems