Prometheus Thanos快速指南

Thanos系统构建于Prometheus之上，用于扩展Prometheus功能，提供了全局查询、高可用支持、历史数据备份到对象存储等核心能力。Prometheus在架构中扮演数据收集角色，告警功能仍然推荐使用各个Prometheus节点的本地数据及告警能力。

Thanos组件

• Sidecar：连接到Prometheus，读取其数据上传到对象存储，并提供查询API。
• Store-gateway：提供对象存储中指标的查询能力。
• Compactor：对对象存储的数据进行压缩、降采样及配置保留时长。
• Receiver：从Prometheus remote-write WAL接收数据，上传到对象存储，并提供查询API。
• Ruler/Rule：计算Thanos数据的recording rules和alerting rules，上传到对象存储。
• Querier/Query：实现Prometheus v1 API来聚合底层组件的数据。
• Query Frontend：作为查询代理，将查询按天拆分，并将请求分发给Querier，同时缓存响应结果。

使用Sidecar时架构如下：

使用Receiver时架构如下：

Sidecar

Thanos通过Sidecar进程与已有的Promerheus集成，Sidecar与Prometheus运行在同一个主机或Pod中。Sidecar的作用是将Prometheus的本地数据备份到对象存储中，并通过gRPC API为其他Thanos组件提供指标查询能力。Sidecar使用了Prometheus的reload功能，因此Prometheus启动时需添加参数-web.enable-lifecycle。

外部存储

如下配置，配置Sidecar将Prometheus的数据备份到对象存储中：

thanos sidecar \
    --tsdb.path            /var/prometheus \          # TSDB data directory of Prometheus
    --prometheus.url       "http://localhost:9090" \  # Be sure that the sidecar can use this url!
    --objstore.config-file bucket_config.yaml \       # Storage configuration for uploading data

存储配置文件bucket_config.yaml的编写示例可参看Thanos - Highly available Prometheus setup with long term storage capabilities

此组件对Prometheus的影响可忽略不计，如果仅希望把Sidecar作为查询聚合组件，则可以去掉--objstore.config-file。

Store API

Sidecar提供了一个gRPC Store API，可用来查询Prometheus中的指标数据。以下配置，将Sidecar连接到Prometheus，并暴露了Store API。

thanos sidecar \
    --tsdb.path                 /var/prometheus \
    --objstore.config-file      bucket_config.yaml \       # Bucket config file to send data to
    --prometheus.url            http://localhost:9090 \    # Location of the Prometheus HTTP server
    --http-address              0.0.0.0:19191 \            # HTTP endpoint for collecting metrics on the Sidecar
    --grpc-address              0.0.0.0:19090              # GRPC endpoint for StoreAPI

上传历史数据

当Sidecar使用参数--shipper.upload-compacted启动时，将扫描Prometheus本地存储的blcok并上传到对象存储。

注意：不能再已运行Sidecar且已有block上传到存储的节点上运行此参数，这样会造成存储中存在重复block，必须手动删除，否则会报错。

External Labels

Prometheus可以配置external_labels，用来标识一个Prometheus实例。由于Thanos跨多实例聚合数据的特点，因此提供一组一致的标签至关重要。

在Thanos中，每个Prometheus都必须拥有一组全局唯一的标识标签，例如：

# Prometheus A
global:
  external_labels:
    region: eu-west
    monitor: infrastructure
    replica: A


# Prometheus B
global:
  external_labels:
    region: eu-west
    monitor: infrastructure
    replica: B

Querier/Query

按照上述配置为所有Prometheus配置好Sidecar后，我们希望使用Thanos的全局查询层来一次性查询多个Prometheus的数据。

Query组件是无状态的，可以任意拓展副本数。Query在连接到Sidecar后，会自动检测某个PromQL查询需要使用哪些Prometheus。

Thanos Querier还实现了Prometheus的官方HTTP API，因此可以直接作为Gafana的数据源使用。

thanos query \
    --http-address 0.0.0.0:19192 \                                # HTTP Endpoint for Thanos Querier UI
    --store        1.2.3.4:19090 \                                # Static gRPC Store API Address for the query node to query
    --store        1.2.3.5:19090 \                                # Also repeatable
    --store        dnssrv+_grpc._tcp.thanos-store.monitoring.svc  # Supports DNS A & SRV records
    --store        Thanos_Store_IP:port                           # 连接Thnaos Store组件，后文进一步介绍

其中1.2.3.4:19090、1.2.3.5:19090为两个Sidecar的gRPC地址。Query会定期调用该API以获取最新的元数据信息并检查API的健康状态。元数据包括每个节点的时间窗口及external labels。

现在访问HTTP 19192，就会看到一个类似Prometheus的UI界面，如果组件均配置正确，则可以查询到所有Prometheus的数据了。

查询去重

Query组件可以在查询时对来自Prometheus HA对的数据进行去重，这要求我们在配置prometheus时添加global.external_labels来标识每个Prometheus的身份，例如使用上文的配置，replica标签用来区分一个Prometheus HA对中的不同实例。Query可按如下配置：

thanos query \
    --http-address        0.0.0.0:19192 \
    --store               1.2.3.4:19090 \
    --store               1.2.3.5:19090 \
    --query.replica-label replica  # Replica label for de-duplication
    --query.replica-label replicaX # 支持配置多个标签

Store Gateway

因为Sidecar会将数据备份到对象存储中，因此我们将Prometheus的本地数据保留时长设置得短一些以减少磁盘空间占用。所以我们还需要一个组件来查询对象存储中的历史数据，这个组件就是Store Gateway，同Sidecar一样，它也提供了StoreAPI接口，并且需要被Query组件调用。

thanos store \
    --data-dir             /var/thanos/store \   # Disk space for local caches
    --objstore.config-file bucket_config.yaml \  # Bucket to fetch data from
    --http-address         0.0.0.0:19191 \       # HTTP endpoint for collecting metrics on the Store Gateway
    --grpc-address         0.0.0.0:19090         # GRPC endpoint for StoreAPI

Store Gateway会占用少量的磁盘空间来缓存对象存储中数据的基本信息，通常不会超过几GB，缓存可以提供Store Gateway的重启速度，但并不是必须的，在重启前删除缓存信息也是没问题的。

Compactor

Prometheus会定期压缩（compact，也可译为合并）历史数据以提高查询速度，Thanos同样需要一个组件来执行相同的过程，这个组件就是compactor。Compactor会扫描对象存储并对需要的block执行compact操作。同时，Compactor也可以创建降采样数据，并配置数据的保留时长。

thanos compact \
    --data-dir             /var/thanos/compact \  # Temporary workspace for data processing
    --objstore.config-file bucket_config.yaml \   # Bucket where to apply the compacting
    --http-address         0.0.0.0:19191          # HTTP endpoint for collecting metrics on the Compactor

Compactor组件不在查询及数据备份路径上，它既可以被当成一个定时任务执行，也可以常驻后台以便及时处理数据。推荐提供100-300GB的本地空间给Compactor来处理数据。

Compactor组件只能运行一个，并且如果手动修改了存储中的数据，则不能再运行此程序。

详见：Thanos Compactor组件使用_洒满阳光的午后的博客-CSDN博客

Ruler/Rule

如果你需要全局视图的alerting rules和recording rules，则可以使用该组件。否则不推荐，扔建议使用Prometheus自带的alert功能。

该组件的配置方法见：Rule