写点什么

Google 大规模监控系统 --Monarch

用户头像
俞凡
关注
发布于: 19 小时前
Google大规模监控系统--Monarch

Monarch 是 Google 的大规模监控系统,服务于 Google 全球大规模实时业务监控,其实现为超大规模时序数据库集群,被公认为当今全球最大规模的时序数据库。Monarch 本身没有开源,主要信息来源于 Google 在 2020 年 8 月份发表在 PVLDB 上的一篇论文:Monarch: Google’s Planet-Scale In-Memory Time Series Database。这篇文章是 Medium 上一篇介绍 Google Monarch 的文章的中文翻译,原文链接:Understanding Monarch, Google’s Planet-Scale Monitoring System


以下为正文,斜体字是我加的备注:


Monarch 是 Google 开发的大规模内存时序数据库,用于 Google 的大部分内部系统(如 Spanner, BigTable, Colossus, BlobStore)的可靠监控系统。


与任何其他的 Google 服务一样,它必须被设计为大规模、高可用并且支持区域局域性。但与其他服务不同的是,Monarch 需要尽可能少的依赖其他 Google 服务,这一点非常重要,因为其他服务都在使用 Monarch 对自己进行监控,因此如果有相互依赖关系,任何一方的服务中断都会影响到另一方。


Monarch 是一种必须支持高可用性和分区性的服务,因此在最终一致性有延迟的情况下,它通过向客户服务提供一定的提示来解决低一致性的问题。


这意味着 Monarch 是 AP 系统,支持最终一致性而不是强一致性,这也是大规模分布式系统设计的普遍做法。

Monarch 的数据存储

数据以两种格式存储:

  • Leaves(叶子)组件在内存中存储实际的监控数据

  • Logs(日志)是持久化存储,可用于在组件失败时重放事件

Leaf 是内存中的缓存存储模块,Log 用来做持久化和高可用,在服务失效的时候可用于快速恢复数据。


Monarch 的数据获取

Data Ingestion Pipeline(数据接收管道)遵循如下原则:

  • 将客户端服务的数据存储在距离服务运行的 zone 越近越好,从而减少网络延迟

  • 将客户服务的数据存储在同一个 Leaf 中,因为数据查询很有可能被集中在该 Leaf 上,以获得更快的查询响应

就近原则和内聚原则,从而尽可能提高访问性能。


Monarch 模块架构


以下情况将触发数据传输:

  • Ingestion Router(数据接收路由器)将数据发送给叶子路由器

  • Leaf Router(叶子路由器)将数据发送给叶子

  • Range Assigner(分配器)决定存储数据的叶子


数据接收路由器根据位置字段将时间序列数据分区,叶子路由器根据分配器的决定将数据分布在叶子上。


数据格式模型


接收到的数据包含以下几类:


Targes(目标)用于识别数据生成的节点/服务/组件。以上图为例,目标字符串 ComputeTask::sql-dba::db.server::aa::0876 表示数据库服务器的 Borg 任务。目标字符串的格式对于决定数据在叶子之间的存储位置很重要,因为目标范围用于决定叶子之间的字典分片和负载均衡。


Metrics(指标)以 key-value(键值对)的格式包含指标信息,其中键是目标的指标类型,值是基于时间序列的数据点。支持的度量类型有 boolean、int64、double、string、distribution 或 tuple。度量值可以是 cumulative(累计值),也可以是 gauge(测量值)。使用累计值的优点是偶尔的数据丢失对统计分布的影响不大。


distribution 实际上是一个 double list,由许多个 bucket 组成,每个 bucket 里有一个 double 值,用于表示数据分布范围的统计。举个栗子:有一个访问延迟的 distribution 定义了 4 个 bucket: 0-10ms, 10-20ms, 20-30ms, 30ms 以上,每个 bucket 里的 double 数值定义了在这个延迟范围内的访问次数。

distribution 类型示例


数据可以以 Delta Time Series(增量时间序列)的格式发送,这样只需要发送时间序列数据中的增量,而不是整个指标数据。这减少了数据的连续输入,并且只需要在数据有变化的时候进行处理。


Bucketing 在将数据发送到数据接收管道之前的一段时间内负责聚合数据,从而减少网络处理,并且可以实现批量插入。


Admission windows 用于丢弃在一定时间后接收到的数据,从而避免处理过期数据的压力。


因为 Bucketing 会在一定时间内聚合数据,然后存到叶子并且持久化,这样如果有数据来晚了,对应的 Bucket 已经完成了处理,就需要将迟到的数据丢弃。


数据查询

Monarch 提供了一个全局联合查询引擎,所有查询都可以在全局级别启动,Monarch 负责将查询路由到存储相关数据的叶子,并整合来自叶子的响应。


上面的模块图显示了查询相关的模块:

  • Mixers 将查询分解为子查询,并合并来自子查询的响应。根 Mixer 接收查询并将它们发送到 zone mixer,zone mixer 进一步将其发送到叶子,从而形成查询树。Mixers 还查询索引服务器,将查询限制在数据所在的 zone 或叶子。

  • Index servers(索引服务器)索引每个 zone 和叶子的数据,这些数据可用于确定查询针对哪些叶子。

  • Evaluators 从 standing query 生成响应,并将数据写回叶子。

Standing query 类似 SQL 中的 View(视图)的概念,用户可以自定义 standing query,evaluator 会定期查询 standing query 的结果,并写回对应的叶子,从而可以加快查询速度。


Monarch 支持如下查询语义:

  • Fetch

  • Filter

  • Join

  • Align

  • GroupBy


Ad-hoc queries 是来自系统外部用户的查询。

Standing queries 是类似于其他数据库系统中的视图的查询,定期计算并存储到 Monarch 中,以获得更快的查询响应。根据查询的广度,standing query 可以在 zone 或 root 级别进行评估,将查询空间最小化到特定 zone 的叶子,从而获得更好的性能。

Level analysis 用于对查询进行级别分析,基于不同的级别将查询打破重组,用以进行认证和获得更好的查询局部性。查询级别可以根据上面提到的查询树进行定义。

Replica Resolution 用于找出响应查询的最佳副本。因为查询负载、系统配置、数据完整性等方面可能存在差异,因此某个副本可能更适合响应查询请求。

User Isolation 用来限制任一用户在系统中可以使用的内存量,以便其他遵守规则的用户不受影响。


性能
  • Monarch 分布在横跨五大洲的 38 个 zone,执行大约 400,000 个任务。

  • 截至 2019 年 7 月,Monarch 存储了近 9500 亿时间序列,其高度优化的数据结构消耗了约 750TB 内存。

  • 2019 年 7 月,Monarch 的内部部署每秒接收约 4.4TB 的数据。

  • Monarch 持续指数级增长,截至 2019 年 7 月,每秒服务超过 600 万次查询。

性能


封面图片来自:https://unsplash.com/@seanstratton

用户头像

俞凡

关注

还未添加个人签名 2017.10.18 加入

俞凡,在上海、达拉斯生活的技术人,关注高可用架构、高性能服务、5G、人工智能、区块链、DevOps、Agile等。公众号:DeepNoMind

评论

发布
暂无评论
Google大规模监控系统--Monarch