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