发布在即!企业 AIGC 应用程度测评,3 步定制专属评估报告。抢首批测评权益>>> 了解详情
写点什么

Spotify 的监测框架(上)

  • 2015-12-17
  • 本文字数:2726 字

    阅读完需:约 9 分钟

【编者的话】 Spotify 是全球最大的正版流媒体音乐服务平台。Spotify 提供的服务需要一个巨大的基础设施平台作为支撑,而监测这个平台的运行显得至关重要。Spotify 实验室的 John-John Tedro 近日对 Spotify 的监测进行了一个简单的介绍。作为该系列文章两个部分的第一篇,本文主要介绍了Spotify 的监控的历史,当前面临的挑战,以及Spotify 又是如何解决这些挑战的。

Spotify 的运行监测一开始是作为两个系统的组合,即 Zabbix 和 sitemon,其中 sitemon 是一个支持RRD 的土生土长的图形系统,它采用 Munin 用来进行数据收集。 Zabbix 的所有权属于我们的 SRE 团队,而 sitemon 由我们的后端基础架构团队负责运行。当时,我们的团队很小,身边的很多问题常常都是由自己亲手解决。我们采取了这种方案的原因更多的是因为我们选择这个问题。

从 2013 年年底起,我们开始把更多的注意力放在自助服务和分布式运行监测上。我们想停止监测单个主机,并开始将服务作为一个整体考虑。Zabbix 并不适合,因为它主要关注单个主机。唯一可以操作它的是SRE 团队的成员。随着整个基础设施变得越来越庞大,我们的系统在强大的负载压力下开始产生裂痕。

我们也在试图尽力将目前的工作做一些改进:基于内存的sitemon 方案仅仅能在当前负载压力下保存大约1 个月的指标数据,从而我们的首席架构师提出了一种新的替代方案。在这种方案下,虽然我们还有一些喘息的空间,但我们估计我们最多只能持续一年。出于这样的体验,Spotify 组建了一个新的团队:Hero。他们的目标是改进Spotify 的监测,并为未来做好准备。不惜一切代价。下面是他们采取的主要做法。

报警作为一种服务

报警是我们需要攻克的第一个问题。

我们考虑进一步发展Zabbix。它使用触发器表达式来检查报警条件。我们在系统中观测到大量位衰减,许多正在运行的触发器很难理解、已经损坏或无效。这就引出了我们为下一代警报系统所提出的其中一个要求:它必须使得对触发器的测试变得简单,以使其容易理解。Zabbix 的可扩展性也是一个问题。在接下来两年中,我们不相信我们的系统可以在我们预期的规模上运行。

在参加 Monitorama EU 时,我们偶然发现了 Riemann 。一个分布式监测系统解决方案。Riemann 并没有提供不确定情况下的可扩展性,但对于无状态规则的偏爱很容易地让它可以对负载进行划分和分配。我们为一个服务中的每个主机配对至少两个实例,这些实例运行了相同的规则集。

我们在 Riemann 之上建立了一个库,称为 Lyceum 。这使我们能够建立一个 git 仓库,仓库内部,每一个方格可以将它们的规则放入一个隔离的命名空间中。使用这个配置,我们的工程师可以定义可重复的集成测试。它使得任何人可以打开 repo,并可以在产品中直接部署这些变更。我们的立场发生了改变,如果测试通过,我们便知道它的工作原理。这被证明是非常成功的。Clojure 是一门远远比触发器表达式更易于理解的语言,基于 git 的审查过程更适合我们的开发方法。

制图

在这个方面,我们折腾了好几次。我们初始的堆栈是基于 Munin 的,其中的插件对应着收集到的所有东西。一些指标是标准的,但最重要的那些是服务指标。

切换到基于 push 的方式来降低我们选用工程师的门槛,是值得期待的。使用 Munin 的经历告诉我们,复杂的定义指标的过程会延缓最后指标的采纳。基于 Pull 的方法需要配置读出什么,以及从哪里读出。而用 Push 的方法,你会忘记在最近的 API 中的样本,最好使用一个共同的协议。考虑一个短暂的任务,其中可能没有足够的时间被收集器发现。但对于 Push 来说,这并不是问题,因为是任务本身控制了度量的发送。

如果您想了解更多, sFlow Alan Giles 针对这个问题进行了更深入的分析。

我们最初的实验中,部署了一个基于 collected Graphite 的通用解决方案来积累经验。分析性能测试的结果,我们感觉对这种垂直的可扩展性并不满意,我们不想只有一个 Graphite 节点。

whisper 写入模式涉及到跨众多文件的随机搜寻和写入。文件搜索过程中的向下采样,存在一个很高的成本。

分片和再平衡Graphite 存在的困难也经常让人望而却步。其中的一些可能最近通过使用后端支持的Cyanite 已经得到了解决。但对我们来说,Graphite 仍然遭受了一个重大的理论障碍:分层命名。

数据层次

Graphite 中一个典型的时间序列按照类似下面这种方式命名:

确切的形式分情况不同,但是这可以被视为一个固定的层次结构。在一些情况下这种方式工作得很好,因为它们本质上就是层次结构。但是,如果我们想在一个特定的网站选择所有服务器。我们有两个选择:我们希望服务器名称在不同的基础架构中保持一致,并执行通配符匹配;或者为了解决这个问题,我们可以对命名层次结构进行重新洗牌:

这种类型的重构是很难的。

没有正确的答案。一个团队可能要求将网站作为筛选的主要手段,也可能希望将角色作为筛选的主要手段。这两个要求具有相同的优点。因此,弱点也都在于命名方案。

标签

在解决这个问题中有一个完全不同的方式,即考虑将一个时间序列的标志符由一组标签组成。

看看我们前面的例子,我们将现有层次结构映射到一组标签。

通过一个过滤系统,其能够让工程师将内部组件相互连接的一大片时间序列进行拆分。提高了互操作性。

这样一来,这就没有了我们必须严格遵守的层次结构。按照惯例,他们可能是结构的一部分(“网站”和“主机”总是存在),但它们既没有被要求,也不是严格有序的。

Atlas Prometheus OpenTSDB InfluxDB KairosDB 都是使用标签的数据库。 Atlas 和 Prometheus 被认真考虑过,但在时间上并不可用。我们最终并没有选择 OpenTSDB,因为在使用 HBase 时的糟糕的运行体验。InfluxDB 不成熟,因为它缺乏自助服务的功能,而这正是我们需要推出的。KairosDB 似乎像最好的选择,所以我们进行了广泛的试验。但发现它在性能和稳定性上存在问题,我们试图做一些努力,但均告失败。我们认为该项目由于缺乏社区的参与,并没有朝着我们期待的方向前进。

受 KairosDB 的启发,我们开始了一个新的项目。我们针对这个项目做了一些小的实践,并取得了可喜的成果,所以我们坚持下来了,并给它取了一个名字;Heroic。

请继续关注下一篇文章,我会介绍 Heroic,即我们的可扩展的时间序列数据库。

编后语

《他山之石》是 InfoQ 中文站新推出的一个专栏,精选来自国内外技术社区和个人博客上的技术文章,让更多的读者朋友受益,本栏目转载的内容都经过原作者授权。文章推荐可以发送邮件到 editors@cn.infoq.com。


感谢杜小芳对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作,请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博( @InfoQ @丁晓昀),微信(微信号: InfoQChina )关注我们,并与我们的编辑和其他读者朋友交流(欢迎加入 InfoQ 读者交流群(已满),InfoQ 读者交流群(#2))。

2015-12-17 16:552822
用户头像

发布了 268 篇内容, 共 117.7 次阅读, 收获喜欢 24 次。

关注

评论

发布
暂无评论
发现更多内容

报错:Cannot read properties of undefined (reading ‘$message‘)解决方法

百度搜索:蓝易云

JavaScript typescript 云计算 运维 云服务器

一文了解Validator库

百度搜索:蓝易云

html Linux 运维 Node validator

TiDB in 2023, 一次简单的回顾丨PingCAP 唐刘

PingCAP

数据库 分布式 云原生 TiDB

听 GPT 讲 Deno 源代码 (12)

fliter

关于ERPNext的树形结构研究

麦兜

uniapp的u-album组件自定义删除功能

百度搜索:蓝易云

uni-app Linux 运维 云服务器 album

【组织】读《领导力》

极光一号。

mysql超出最大连接数解决方法

百度搜索:蓝易云

MySQL 云计算 Linux 运维 云服务器

中国比特币矿工的新根据地:埃塞俄比亚

TechubNews

BTC

一篇文章彻底搞懂 TiDB 集群各种容量计算方式

PingCAP

数据库 TiDB

OpenAI 推出的文生视频 Sora,目前 AIGC 视频的天花板,会让多少公司望而生畏?

派大星

Open AI

听 GPT 讲 client-go 源代码 (3)

fliter

听 GPT 讲 client-go 源代码 (4)

fliter

在中国做 DePIN?你需要明白风险与机遇

TechubNews

架构的技巧

agnostic

架构设计原则 架构设计实战

Nop平台的定位和发展规划

canonical

DDD 低代码 可逆计算 Nop平台

听 GPT 讲 client-go 源代码 (1)

fliter

“分布式透明化”在杭州银行核心系统上线之思考

PingCAP

数据库 TiDB 银行业

STL算法大全

百度搜索:蓝易云

c++ 云计算 Linux 运维 云服务器

听 GPT 讲 Deno 源代码 (13)

fliter

TIKV 分布式事务--Prewrite 接口详解

TiDB 社区干货传送门

TiDB 底层架构 TiKV 源码解读 TiKV 底层架构

fastposter v2.18.0 一分钟完成开发海报-云服务来袭

物有本末

海报编辑器 海报生成 海报小程序

黄东旭:“向量数据库”还是“向量搜索插件 + SQL 数据库”?丨我对 2024 年数据库发展趋势的思考

PingCAP

数据库 分布式 TiDB

架构误区系列19:Big API

agnostic

架构设计实战

vue项目中package.json的个人见解

百度搜索:蓝易云

Linux 运维 Vue 云服务器 package.json

苹果Vision Pro与头显新应用

算AI

人工智能 创业 创新

starknet财神开始发红包了

币离海

以太坊 空投 starknet

ConcurrentHashMap是如何保证线程安全的

百度搜索:蓝易云

Java Linux 运维 ConcurrentHashMap 云服务器

JavaScript中exec()方法详解

百度搜索:蓝易云

JavaScript Linux 运维 云服务器 exec

通过 Prometheus 编写 TiDB 巡检脚本(脚本已开源,内附链接)

PingCAP

数据库 TiDB

第二十二周作业

大肚皮狒狒

Spotify的监测框架(上)_语言 & 开发_张天雷_InfoQ精选文章