在前面的文章中,我们介绍了Prometheus的高可用方案,但就如文中所说,目前官方的方案还存在一些问题,尤其是在大规模的监控环境中并不完美。鉴于Prometheus的火爆,目前市面上已有不少第三方的开源解决方案用于完善高可用、大并发和数据持久化等问题。

Thanos(灭霸)即是其中之一,也是目前较为流行的解决方案,本文将对其进行介绍。


一. 产品介绍

Thanos为英国游戏技术公司Improbable 开源的一套监控解决方案,它通过一组功能组件,可以用无侵入的方式与Prometheus配合部署,实现全局查询 、跨集群存储等能力,较好地的提升了Prometheus的高可用性与扩展性。

源码地址仓库:https://github.com/thanos-io/thanos

Prometheus监控运维实战十九: Thanos介绍_devops

该产品具有以下 特点:

  1. 可实现跨集群的全局查询功能。
  2. 兼容现有的Prometheus API 接口 ,可实现无缝集成。
  3. 提供数据压缩功能和降准采样,提升查询速度。
  4. 重复数据删除和合并,并从Pormetheus HA 集群中收集指标。
  5. 支持多种对象存储系统,包括S3、微软Azure、腾讯COS、Google GCP、Openstack Swift 等,可支持大规模数据的长期存储。


二. 功能组件

Thanos包含以下主要功能组件:

Sidecar(边车组件):Thanos通过该组件实现与Prometheus集成,配置Sidecar连接Prometheus,并读取数据给到Querier进行实时查询,另外,通过Sidecar还可以将Prometheus采集的数据上传到对象存储进行保存。该组件与Prometheus运行在同一台机器或同一个Pod中。

Querier(查询组件):实现与Prometheus兼容的API并支持Prom语法,与其他组件(Sidecar或Store Gateway)一起协同工作,用于查询Prometheus的数据指标和做为Grafana的监控展示数据源。

Store Gateway(存储网关):实现与Sidercar一致的API提供给Querier进行查询,当Sidecar将数据存储到对象存储后,Prometheus会清理掉本地数据保证本地空间可用,当Querier需要调取历史数据库,则会通过Store Gateway读取对象存储中保存的数据。

Comactor(压缩组件)主要用于对采集到的数据进行压缩和降采样,以提升对长期数据的查询效率。

Ruler(规则组件):用于对多个Alertmanager的告警规则进行统一管理 。

Receiver(接收器):接收Promehtus的 remote-write数据,用于Receiver模式下的数据收集。

Thanos有两种运行模式,分别为Sidecar和Receiver,区别在于Sidercar主动获取Prometheus数据,而Receiver则是被动接收remote-write传送的数据,由于Receiver模式很少使用,本文不做介绍,只讲解Sidercar模式。

Sidercar模式架构图:

Prometheus监控运维实战十九: Thanos介绍_prometheus_02

三. Prometheus配置

Thanos本身并不从目标实例处采集指标,监控指标的采集依然通过Prometheus来完成。 Thanos对Prometheus的版本有要求,需要部署2.21版本以上。

在本文示例中,我们部署两个Prometheus节点,分别为prom1和prom2,用于实现高可用的功能。Prometheus相关的安装部署方法可参见前面的文章 ,此处不再过多叙述。

prom1:192.168.214.101
prom2: 192.168.214.102

在高可用的情况下,由于数据会有重复,需要在external_labels的标签集中区分不同的实例。本文通过增加replica标签做区分 ,在不同的实例填不同的值,如0或1。

以上这点非常重要,因为Thanos的数据去重功能依赖external_labels来区分不同的实例。

global:
scrape_interval: 30s
evaluation_interval: 60s
external_labels:
env: dev
replica: 0

启动Prometheus

prometheus  \
--config.file=/etc/prometheus/prometheus.yml \
--storage.tsdb.path=/data/prometheus \
--web.listen-address='0.0.0.0:9090' \
--storage.tsdb.max-block-duration=2h \
--storage.tsdb.min-block-duration=2h \
--storage.tsdb.retention.time=2h \
--web.enable-lifecycle

注释--storage.tsdb.min-block-duration和--storage.tsdb.min-block-duration参数必须添加且配置相同的值,用于关闭Prometheus的本地压缩功能,否则在使用compactor在压缩数据时会出现问题,并且会在Sidecar启动时报错;--storage.tsdb.retention.time配置本地只保留两小时数据,减少空间占用;--web.enable-lifecycle 用于支持Webhook方式重新加载Prometheus配置。Sidercar会关注Prometheus的配置文件,并在出现变化时通过Webhook方式让Prometheus自动更新配置。

打开浏览器,访问http://$IP:9090,可以看到Prometheus已正常启动。

Prometheus监控运维实战十九: Thanos介绍_监控_03


四. 部署Thanos

1. 集群架构

我们在上面的两个Prometheus的节点服务器中部署Sidercar,用于获取监控数据。同时,配置历史数据写入到对象存储中进行持久化保存。部署一个Store Gateway对接对象存储,同时,Compactor组件会定时对存储中数据进行压缩索引及降采样操作。Querier做为面向用户的组件,对接Sidercar和Store Gateway获取数据并进行展示。(另外还有的Receiver和ruler组件由于使用不是很多,本文不做介绍,有需要可自行查阅。)

集群的架构图:

Prometheus监控运维实战十九: Thanos介绍_devops_04


2. 下载安装包

Thnaos虽然有多个功能组件,但都是使用同一个二进制文件进行部署,通过不同的启动命令启用不同的功能,非常方便。

此处我们下载当前最新的v0.23.1版本,并将解压的二进制文件放到bin目录中。

$ wget https://github.com/thanos-io/thanos/releases/download/v0.23.1/thanos-0.23.1.linux-amd64.tar.gz
$ tar -xvf thanos-0.23.1.linux-amd64.tar.gz
$ cd thanos-0.23.1.linux-amd64
$ mv thanos /usr/local/bin/

3.Sidecar部署 

Sidercar为Thanos的关键组件,通过Sidercar实现了与Prometheus的无缝集成。Sidercar对Prometheus的实例几乎没有任何影响,Prometheus依然做为一个独立的实例运行,你不需要对其配置进行修改。Siderca提供了一个数据API,用于我们查询Prometheus中的指标数据,同时默认会将超过两个小时的数据上传到对象存储 ,进行备份保存。

Sidercar组件必须与Prometheus运行在同一台机器或同一个Kubernetes Pod中,启动命令如下所示:

thanos sidecar \
--tsdb.path /data/prometheus \
--prometheus.url http://localhost:9090 \
--objstore.config-file bucket_config.yaml \
--http-address 0.0.0.0:19191 \
--grpc-address 0.0.0.0:19091

注释 :--tsdb.path 用于指定Prometheus 数据存储路径;--prometheus.url 指定Prometheus访问地址;--objstore.config-file 设置上传数据的对象存储信息;--http-address 配置http端口,用于提供Sidercar的metrics信息;--grpc-address 配置grpc端口,用于与其他Thanos组件通信

Thanos支持多种对象存储及本地文件系统,如下列表所示:

Provider

Maturity

Aimed For

Auto-tested on CI

Maintainers

Google Cloud Storage

Stable

Production Usage

yes

@bwplotka

AWS/S3 (and all S3-compatible storages e.g disk-based Minio)

Stable

Production Usage

yes

@bwplotka

Azure Storage Account

Stable

Production Usage

no

@vglafirov

OpenStack Swift

Beta (working PoC)

Production Usage

yes

@FUSAKLA

Tencent COS

Beta

Production Usage

no

@jojohappy,@hanjm

AliYun OSS

Beta

Production Usage

no

@shaulboozhiao,

@wujinhu

Local Filesystem

Stable

Testing and Demo only

yes

@bwplotka

以阿里云的oss为例,如下为bucket.yml配置格式:

type: ALIYUNOSS
config:
endpoint: ""
bucket: ""
access_key_id: ""
access_key_secret: ""

Sidecar默认会每隔两个小时备份数据到对象存储,当Sidercar运行超过两个小时后,我们可以在对象存储中看到备份的数据。

Prometheus监控运维实战十九: Thanos介绍_prometheus_05


4. Store Gateway部署

当Sidercar把监控数据备份到对象存储后,我们只需要在Prometheus中保留短期的数据,如数个小时。这样可以减少Prometheus的压力,也可用于应付大部分的查询 。但当需要查询历史数据时,我们需要通过Store Gateway来查询对象存储中保存的数据。

Store Gateway 主要与对象存储交互,从对象存储获取已经保存的数据。Store Gateway实现与Sidecar一样的数据api,Querier组件可以从 store gateway 查询历史数据。Store Gateway支持横向扩展,可配置多个Store Gateway拉取多个对象存储数据。

启动命令:

thanos store \
--data-dir /data/thanos/store \
--objstore.config-file bucket_config.yaml \
--http-address 0.0.0.0:19194 \
--grpc-address 0.0.0.0:19094

注释 :--data-dir 配置缓存目录地址,Store Gateway会在本地磁盘上保留有关所有远程块的少量信息,并使其与存储桶保持同步;--objstore.config-file 设置对象存储信息,与Sidercar的配置一致;--http-address 配置http端口,用于提供访问界面和metrics信息;--grpc-address 配置grpc端口,用于与其他Thanos组件通信。

程序启动过,打开浏览器访问http://$IP:19191,可以看到对象存储中已存储的块信息。

Prometheus监控运维实战十九: Thanos介绍_监控_06


5. Querier部署

前面我们已经配置好Sidercar和Store Gateway组件,接下来我们为Thanos配置一个全局查询界面,即Querier组件。Querier连接Sidercar后,会根据给定的PromQL查询自动检测需要联系哪些Prometheus服务器,当要查询历史数据时,则是通过Store Gateway查询对象存储内容。Querier还提供与Prometheus官方一致的HTTP API,可以接入Grafana进行监控展示,并支持PromQL语法。

启动命令如下所示:

thanos query \
--http-address 0.0.0.0:19192 \
--grpc-address 0.0.0.0:19092 \
--query.replica-label replica \
--store 192.168.214.101:19091 \ #prom1实例Sidercar地址
--store 192.168.214.102:19091 \ #prom2实例Sidercar地址
--store 192.168.214.102:19094 #Store Gateway地址

注释 :--query.replica-label 指定重复数据删除的标记label,query在查询数据时,将根据此label评估是否重复数据;--store 用于指定Sidercar和Store Gateway的连接地址,此示例前两个store配置了prom1和prom2的Sidercar地址,第三个则是连接到store gateway;--http-address 指定Querier的UI界面访问地址;


启动完成后,打开浏览器,访问http://$IP:19192 即可查看Querier的UI界面。“Use Deduplication”项默认已勾选,Querier会根据指定的扩展标签进行数据去重,这保证了在用户层面不会因为高可用模式而出现重复数据的问题。“Use Partial Response”选项用于允许部分响应的情况,这要求用户在一致性与可用性之间做选择。当某个store出现故障而无法响应时,此时是否还需要返回其他正常store的数据。如果对可用性要求更高的场景,可以勾选此项。

Prometheus监控运维实战十九: Thanos介绍_云原生_07

Querier兼容Prometheus的API接口,因此,Grafana可直接添加Querier组件地址做为Prometheus数据源。

Prometheus监控运维实战十九: Thanos介绍_监控_08

Prometheus监控运维实战十九: Thanos介绍_监控_09


6. Compactor 部署

在默认情况下,Prometheus会定期压缩旧数据以提升查询效率,但在前面的操作中,我们关闭了此功能。因此,我们需要使用Compactor对对象存储中的数据进行类似操作。

Compactor会为以下数据进行降采样操作,降采样有利于对大时间范围的提供快速获取结果的能力:1. 为大于 40 小时 (2d, 2w) 的块创建 5m 降采样;2. 为大于 10 天 (2w) 的块创建 1 小时降采样。

同时,compact也将对索引进行压缩,包括将来自同个Prometheus实例的多个块压缩为一个,这有利于对提升数据的查询效率。compact通过扩展标签集来区分不同的Prometheus实例,所以,在Thanos集群中不同实例的Prometheus 扩展标签集必须是唯一的,否则会导致compact出现错误。

启动命令如下所示:

thanos compact \
--data-dir /var/thanos/compact \
--objstore.config-file bucket_config.yaml \
--http-address 0.0.0.0:19191

注释:--data-dir 指定用于数据处理的临时工作空间,为保证compact正常工作,建议提供100-300G的容量;--objstore.config-file 指定对象存储的信息,Thanos的其他组件如Sdiercar、Store Gateway只需要提供对象存储的读写权限即可,但compact还需要提供删除权限,因为它会对数据进行操作;--http-address compact的http地址,用于提供metrics指标。

目前,Thanos还不支持多个compact对单个存储对象存储并发进行操作的功能,必须以单实例的方式运行compact。在任务完成后,compact的程序会退出,我们可将其做为定时任务的方式来运行。如果需要程序保持运行,可使用--wait和--wait-interval 参数实现。

由于对象存储本身对于数据是永久保留,如果希望只保留指定时间内的数据,可以通过配置Compactor 的--retention.resolution-raw 、--retention.resolution-5m 和 --retention.resolution-1h 三个参数来实现,分别为原始数据的保留时间、5m分钟降采样数据的保留时间和1小时降采样数据保留时间,其中--retention.resolution-raw 不能小于其他两个时间段,否则会影响compact的降采样操作。


结语:

当前中文网上对于Thanos产品组件介绍的相关资料较少,并且由于产品还在快速迭代中,原有的文档往往已经不再适用。在研究的过程中笔者也只能依赖于官网的英文资料,并在实际使用中做验证。本文应该算是目前比较系统性介绍产品的一份资料,按照文中的操作介绍,可以搭建出满足实际需要的集群架构。

目前产品依然处于快速迭代中,更多的使用内容,读者可自行参见官方文档学习 :https://thanos.io/tip/thanos/getting-started.md/。