Prometheus Thanos Design 介绍

Thanos Logo

本文主要内容翻译自 Thanos Design文档

Thanos 以 Prometheus sidecar 的方式运行, 为 Prometheus 提供了全局查询,备份,以及历史数据访问的功能。Thanos 的集群组件有以下3个功能:

一 指标源

Thanos提供了两个组件作为数据来源: Prometheus sidecar 和 rule nodes. 其中 sidecar 部分实现了一个gRPC 服务,是基于 Prometheus 的 HTTP 和 remote-read APIs 的; 而 rule node 部分 直接运行在 Prometheus 存储引擎上。

说说 Prometheus 2.0存储引擎的备份部分: prometheus 拉回来的 metrics 数据以 block 形式存储在本地磁盘, 而一个 block 其实就是一个目录,目录中有3个组成:

  • chunks , 这部分比较大,就是真正的时序 Metrics 存储
  • index, 可以通过 labels 来查询时序 series 数据,靠的就是这个 index文件
  • meta.json , 这个文件存储了本block的 stats, time range, 和 compaction level 这样的信息. 下面有示例

那么 Thanos 是如何进行备份的呢?上面的 meta.json 就是关键, thanos 扩展了这个 json 文件,加入了 Thanos所特有的 metadata 信息。而后上传到块存储上。

二 存储

对于那些存储在远端对象存储的 block 数据, Store Node 充当了网关的功能。实现了跟指标源相同的 gRPC API 接口,来访问对象存储中的指标数据。它会持续不断的更新 bucket 中的 block , 并将对 metrics 的请求翻译为对象存储的请求。为了降低对远端对象存储的访问数量,它采取了一些手段:例如, 通过 metadata (时间区间,lables 之类的) 过滤 block;又或者对于频繁查询的 index,直接cache起来。

Prometheus 2.0 存储层已经对读放大进行了优化。例如,按照时间和指标名字,连续的尽量放在一起。而 store node是感知到存储文件的结构的,因此可以很好的将指标存储的请求翻译为最少的 object storage 请求。对于那种大查询,一次可以拿成百上千个 chunks 数据。

只有 index 数据是放入 cache的,chunk 数据虽然也可以,但是就要大几个数量级了。目前,从对象存储获取 chunk 数据只有很小的延时,因此也没什么动力去将 chunk 数据给 cache起来,毕竟这个对资源的需求很大。

Stores & Data Sources 其实是一回事

因为 data node 和 data source 提供了相同的 gRPC Store API 接口,因此对于 Client 而言可以把他们当成一个东西来对待。 加之,每一种 Store API的实现都对外声明了自己所能提供数据的 meta data,因此 Client 对特定的数据请求,就可以最小化到仅请求必要的 node。

本质上来说, Store API就是通过一组标签匹配器(从PromQL中获得的)和时间范围来查找数据。 它返回在块数据中找到的压缩样本块。 它纯粹是一种数据检索API,不提供复杂的查询执行。

三 查询层 (Query Layer)

查询器是无状态且可以水平可伸缩的实例,它们在Store API 暴露出的接口之上实现了PromQL 这种查询语言。

Compactor 压缩器
压缩器是一个单例进程, 它会将对象存储 Bucket 中的多个小 Block 合并成 大 Block ,它会大大降低对象存储的空间占用,从 Bucket 中获取数据的请求
也会变少。

将来, Compactor 还会承担指标降精度, Retention 等批量任务。

扩展性
Thanos 的所有组件都不包含 Sharding 功能, 真正具有扩展性的组件其实是 Query Node,它是无状态的,可以随意扩展;扩展存储能力依赖外部的对象存储系统。

Store, rule 和 Compactor预期中是运行在一个实例中,或者是HA。就跟 Prometheus 一样, 功能性的 Sharding 其实并不常见。

例如, 规则集( rule sets)可以被分割到多个 规则节点(rule node)上, Store 则可以通过让不同数据中心使用不同 Bucket 。

另外

Prometheus 新版 tsdb 的作者 Fabian Reinartz 设计了 2.0 格式存储 的 tsdb,相较于老版,极大的提升了存储的性能。相信各位从 Prometheus 1.X 版本升级过来的同学一定会对这次升级印象极深(如果你看过磁盘io的数据的话)。这里有篇 slide 介绍: 。同时 Fabian Reinartz 也是 Thanos 的最主要贡献者

译:一篇博客写作风格指南

经过 Robert 的许可,我翻译他的一篇博客文章 A blogging style guide 。这篇文章中虽然站在英文写作的角度谈博客文章的风格指南,但很多原则依旧适用于中文写作。

下面是翻译的博客正文部分:


这里有 39 种方法,让你的博客文章读起来快乐,写起来舒畅。

自信

  1. 不要告诉读者你为什么写这篇文章,而是告诉他们为什么需要读,然后竭尽所能证明你是对的。
  2.  如果你还对是否应该落笔而存疑,你也许根本就不该写。不,市面上真的不需要对蓝眼岛民谜题 [Blue-Eyed Islanders puzzle] [译者:1,2,3] 再来一种解释了,但到目前为止, 给撒哈拉以南非洲更多防疟疾蚊帐,以及对气候变化采取大规模行动这种事情上区别也不大。
  3.  在下面这3个方面,你需要作出权衡:1. 建立可信度 2. 当你还不是此领域专家的时候保持诚实 3. 听起来就像一个喷子。 例如:“不,我没有去过写作学校,我是在人生这所大学,重锤学院,以及牛津大学圣凯瑟琳学院的物理系,学到了必要的知识“。
  4.  如果你一定需要进行自嘲,那么使用下面这种方式可以给自己留一些自信。例如:“当然,在互联网上有很多其他的,比此篇更好的写作风格指南,并且如果你真的很想找到这样的一篇指南来训练你自己的风格的话,你应该直接读 Strunk 和 White 的 风格的要素 <Elements of Style> ,但是你现在读的可不是 Strunk 和 White 的文章,你读的是 Robert Heaton。你也许已经读过了Strunk 和 White,却依旧充满了疑问,所以那就来看看我怎么说吧。”
  5.  如果你仍然对自己的写作水平有所保留,那么可以在文章开头说明一次,也可以在文章结尾再说一次,但是在它们中间的时候,请忘记它们。

文体构成

  1.  当你有一堆观点需要进行陈述时,使用那些古板但好用的表达技巧并无不妥,即便你没有费尽力气的将它们优雅的组织到一起也没关系。
  2.  很多文章在一开始使用了通用的文体构成方式,即便在那些高科技的主题中。埋好相关的伏笔之后,作者很快开始阐述其中的共通的部分,最后巧妙的回到最初的伏笔之中。
  3.  构建文章的过程中如果你缺乏真实的案例,那么可以考虑编一个。就我而言,我就非常喜欢使用 Steve Steveington Chronicles 和 Hobert Reaton 的职业生涯来讨论在线追踪 (online tracking)这个事情,在我的设定里 Hobert Reaton 是一位狡猾的 adtech (广告技术) 企业家。

词汇

  1.  可以使用同义词典来查找“聪明”的替代单词,假使在几句话之前你已经使用过了“聪明”这个词。 只是不要弄得“似是而非”。
  2.  给你需要避免使用的词汇做一张列表。对我来说这个列表包括“供参考” (原文:For reference),”交代一些背景” (原文:To give some context),“像那些巨无霸公司一样”(原文 Like some giant ape)。我也不喜欢“伙计”(原文:folks)这个词,除非你文中的其他词汇也是这么随意。 虽然我支持你这么做了,但我仍然坚持使用“人”(原文:people)这个词。
  3.  除非你有极其充分的理由,否则你可能跟我一样想法:我认为所有人都喜欢那些文明用语写出的文章。
  4.  远离Meme (译者: https://baike.baidu.com/item/Meme) – 它们只是以Twitter的速度传播的陈词滥调。 永远不要试图追新所有事情。
  5.  如果你愿意,可以用“ And” 和 “But”开头。

风格指南

  1.  去读 “Style: Towards Clarity and Grace”, 作者Williams and Colomb。书很棒。但是如果你只有时间读一种风格指南,那么,你现在就正在读呢,它更短。
  2.  选择几个风格你很喜欢的人,尽力去模仿,但是不要抄袭。我的目标是《经济学人》(Economist)的 Paul Krugman 和 Terry Pratchett.
  3.  如果你不去练习,风格指南毫无意义。

包容性和多样性

  1.  包容性和多样性的入门非常容易,你几乎什么都不用做。
  2.  如果你需要立刻给虚构角色起一个名字,考虑使用一个通常你不会使用的文化和性别。即使你不相信媒体中的代表性很重要,但你肯定会承认它仍有可能存在,有时你想都不想,就给虚构的计算机程序员起名为 Julianna。
  3.  “They”是一个很好的词,用来指代那些性别未名人士。
  4.  或者你也可以在“He他”和“She她”之间交替,然后掷硬币来决定。
  5.  不要对穷人,无家可归的人和未受过教育的人太刻薄,《南方公园》虽然总能避开诉讼,但我不太相信你如果按照他们的路线走的话,不会掉入歧视的陷阱中去。
  6.  我对自己这种虽然有些粗野但是不失温和的写作风格还算满意。

幽默

  1.  不要让文中的笑话妨碍你的观点。当你在阐述英国脱欧这件事中的观点时候,你可不是正在站起来表演。我怀疑如果你真的在进行表演的时候,我这条原则实际上依旧适用。
  2.  如果你的幽默听起来像在汽车保险广告上看到的那种,或是假笑话,那就重新考虑一下吧。
  3.  清晰的表达优于有趣的表达。
  4.  你完全可以嘲笑资本主义的缺点和狂野,这种写作风格是挺有趣的,但没必要否认资本主义加强了产权这件事,这几乎是人类在上个世纪或上两个世纪真正开始进步的原因。

隐喻

  1.  不要让自己的假想的隐喻妨碍你表达观点,至少听起来不要。
  2.  一个轻松而合适的隐喻可以帮助你的读者记住这个想法,即使他们不需要这个隐喻来理解它。

杂项

  1.  技术写作中使用代词需要慎重,当多次使用“它”会造成困扰的时候,最好重复使用它所指代的那个名词。
  2.  理想情况下, 你的文章应该没有超链接。虽然将它们放在特定的颜色和上下文中会很比较有用,但是如果依赖它们就是懒惰的表现,而且就不一定有用了。
  3.  如果你的作品可以让使用屏幕阅读器的人轻松访问,为什么不那么做呢,Github上就有一些我试图遵循的建议指南。
  4.  通过重新组织句子中的单词,你通常可以让自己的文章更加清晰易懂。
  5.  不要隐藏线索,你又不是写恐怖小说,你应该为读者清晰的指引出线索。多做陈述结论,然后阐明为什么是这样。

过程

  1.  在你计划写作的日子,即便花上10,20,30分钟盯着天花板看都是可以的。
  2.  毫无疑问,能这样做是很不错的:花上30分钟胡乱写下一些无意义的话,它们日后可供你重新组织使用,这至少可以帮你走出思绪上的死胡同。
  3.  但如果你花上10,20,30分钟盯着天花板之后却感觉很糟糕,这样就不好了。
  4.  如果感觉不太对,那么就将你要写作的范围减小。也许你的前三个观点就已经足够吸引人了呢。
  5.  如果你一定需要写第二部分的话,尽量让其可以作为独立内容存在而不突兀。
  6.  不要让自己觉得你正在写终稿。这样你会因为害怕犯错,而让落笔和修改变得格外艰难。

在学小提琴

有阵子了,本意是激励一下女儿的钢琴学习——学习本身是有感染力的,一家三口都在学音乐,可以有个氛围在,不至于彼此掉队。

小提琴的新手入门曲线有些陡峭,第一节课的时候就被告知了,但是没想到居然这么陡:我这个超级新手,新到五线谱都要从头学那种,上手都在探索中。不过迄今为止热情未失,算是一个好的开端。

Screenshot from 2018-08-27 00-31-26.png

身边的朋友都开始经历中年生活,各有各的烦恼;聚的时间越加少,偶尔一次话题总归逃不脱工作和家庭。技术宅的生活圈子,技术类话题还是占上挺高比重,摸摸发福的肚子,聊聊最新的开源技术。也在慢慢为自己的晚年生活积攒一些爱好,我这个小提琴就是。