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
评论