原文 https://www.chenshaowen.com/blog/manage-multiple-prometheus-using-thanos.html
1. 监控的分层
如上图，在建设监控系统时，会采用两种策略:
- 分层监控。IaaS、MySQL 中间件、App 层监控分开的好处是，系统之间具有高可用性、容错性。当 App 层监控无法工作时，IaaS 层监控立马就会体现出来。
- 长短期指标分离。短期指标用来提供给告警系统高频查询近期数据，长期指标用来提供给人查询时间跨度更大的数据集。
这里将其统称为监控的分层策略，只不过一个是以基础设施维度的分层，一个是以时间维度的分层。
2. 现状与选型
目前的状况是: 没有进行监控的长短期分层，共用一套 Prometheus。查询长周期指标时，Prometheus 所在服务器内存、CPU 使用率飙升，甚至导致监控、告警服务不可用。
原因在于两点:
- 查询长周期数据时，Prometheus 会将大量数据载入内存
- Prometheus 载入的不是降采样数据
查询的范围越大，需要的内存就越多。在另外一个生产的方案中，我们采用 VictoriaMetrics 单机版作为远端存储，部署的内存高达 128 GB 。同时，这种方式下还存在丢数据的情况。
而 Prometheus Federation 的方式，只是解决了将多个 Prometheus 聚合起来，并没有提供抽样的能力，不能加快长期指标的查询，不适用于当前远端存储的场景。
最后看到 Thanos Compact 组件能够对指标数据进行压缩和降采样，决定尝试使用 Thanos 作为目前多个 Prometheus 远端存储使用。
3. Thanos 的几种部署方式
3.1 基础组件
- Query, 实现了 Prometheus API，对外提供与 Prometheus 一致的查询接口
- Sidecar, 用于连接 Prometheus，提供 Query 查询接口、也可以上报数据
- Store Gateway, 访问放在对象存储的指标数据
- Compact, 压缩采样、清理对象存储中的数据
- Receive, 接收 Prometheus Remote Write 的数据
- Ruler, 配置和管理告警规则
3.2 Receive 模式
Receive 模式下，需要在每一个 Prometheus 实例中配置 remote write 将数据上传给 Thanos。此时，由于实时数据全部都存储到了 Thanos Receiver，因此不需要 Sidecar 组件即可完成查询。
优势：
- 数据集中
- Prometheus 无状态
- 只需要暴露 Receiver 给 Prometheus 访问
缺点:
- Receiver 承受大量 Prometheus 的 remote write 写入
3.3 Sidecar 模式
Sidecar 模式下，在每一个 Prometheus 实例旁添加一个 Thanos Sidecar 组件，以此来实现对 Prometheus 的管理。主要有两个功能：
- 接受 Query 组件的查询请求。在 Thanos 查询短期数据时，请求会转到 Sidecar。
- 上传 Prometheus 的短期指标数据。默认每两个小时，创建一个块，上传到对象存储。
优势:
- 集成容易，不需要修改原有配置
缺点:
- 近期数据需要 Query 与 Sidecar 之间网络请求完成，会增加额外耗时
- 需要 Store Gateway 能访问每个 Prometheus 实例
4. 部署 Thanos
4.1 部署一个 Minio
请参考文档: Jenkins 中的构建产物与缓存
安装完成之后，请根据文档中的配置进行测试，确保 Minio 服务正常工作。
4.2 在 Minio 上创建一个名为 thanos 的 Bucket
如下图：
4.3 检查 Prometheus 版本符合 Thanos 要求
目前 Thanos 要求 Prometheus 版本最好不低于 v2.13。
4.4 部署 Thanos
- 确保 Kubernetes 集群上有默认的存储可用
1 2 3 4 5 | kubectl get sc NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE openebs-device openebs.io/local Delete WaitForFirstConsumer false 4d5h openebs-hostpath (default) openebs.io/local Delete WaitForFirstConsumer false 4d5h |
|---|
- 新建一个命名空间 thanos
1 | kubectl create ns thanos |
|---|
- 部署 Thanos
1 | git clone https://github.com/shaowenchen/demo |
|---|
修改 demo/objectstorage.yaml 文件中的 Minio 访问地址。然后创建 Thanos 相关负载:
1 | kubectl apply -f ./demo/thanos-0.25/ |
|---|
- 查看相关负载
1 2 3 4 5 6 7 8 | kubectl -n thanos top pod NAME CPU(cores) MEMORY(bytes) thanos-compact-0 1m 30Mi thanos-query-7c745f5d7-svlgn 2m 76Mi thanos-receive-0 1m 15Mi thanos-rule-0 1m 18Mi thanos-store-0 1m 55Mi |
|---|
部署 Thanos 消耗的资源很少。
4.5 访问 Thanos Query
- 查看 Thanos 相关服务的端口
1 2 3 4 5 6 7 8 | kubectl -n thanos get svc NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE thanos-compact ClusterIP 10.233.47.253 <none> 10902/TCP 11h thanos-query NodePort 10.233.45.138 <none> 10901:32180/TCP,9090:32612/TCP 11h thanos-receive ClusterIP None <none> 10902/TCP,19291/TCP,10901/TCP 11h thanos-rule ClusterIP None <none> 10901/TCP,10902/TCP 11h thanos-store NodePort 10.233.41.159 <none> 10901:30901/TCP,10902:31426/TCP 10h |
|---|
- 访问 Thanos Query 页面
thanos-query 在 9090 端口提供 http 访问入口，因此这里通过主机 IP:32612 端口访问 Query 组件提供的页面。
5. 给 Prometheus 添加 Thanos Sidecar
Sidecar 模式对 Thanos 配置要求更低，而 Receiver 模式需要不停地接受来自众多 Prometheus 的 Remote Write，这里出于成本考虑选择 Sidecar 模式。
5.1 在 Prometheus 所在命名空间新增 S3 访问凭证
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 | cat <<EOF | kubectl apply -f - apiVersion: v1 kind: Secret metadata: name: thanos-objectstorage namespace: minitor type: Opaque stringData: objectstorage.yaml: | type: S3 config: bucket: "thanos" endpoint: "0.0.0.0:9000" insecure: true access_key: "minioadmin" secret_key: "minioadmin" EOF |
|---|
这里直接使用的是管理员账户，如果是生产上，应该单独创建一个账户用于 Thanos 对 Minio 的使用。
5.2 给 Prometheus 添加额外的 Label 标记实例
通过在 Prometheus 中添加 external_labels 可以给每个 Prometheus 实例全局添加一个额外的标签，用于唯一标记一个实例。
- 编辑配置文件
1 | kubectl -n monitor edit cm prometheus-server |
|---|
- 添加如下内容
1 2 3 4 | prometheus.yml: | global: external_labels: cluster: dev |
|---|
这里添加了一个名为 cluster=dev 的标签。所有该 Prometheus 实例上报的指标都会带上此标签，方便查询过滤。
5.3 修改 Prometheus 启动参数关闭压缩
- 编辑 Prometheus 部署文件
有的是用 Deployment，有的是用 StatefulSet 部署，都需要修改 Prometheus 的启动参数
1 | kubectl -n monitor edit deploy prometheus-server |
|---|
- 修改 tsdb 存储块最大、最小值相等
1 2 3 | - --storage.tsdb.max-block-duration=2h - --storage.tsdb.min-block-duration=2h image: quay.io/prometheus/prometheus:v2.31.1 |
|---|
storage.tsdb.min-block-duration 和 storage.tsdb.max-block-duration 相等，才能保障 Prometheus 关闭了本地压缩，避免压缩时，Thanos 上传失败。
5.4 给 Prometheus 添加 Thanos Sidecar
- 编辑 Prometheus 部署文件
1 | kubectl -n monitor edit deploy prometheus-server |
|---|
- 新增如下容器
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 | - args: - sidecar - --log.level=debug - --tsdb.path=/data - --prometheus.url=http://127.0.0.1:9090 - --objstore.config-file=/etc/objectstorage.yaml name: thanos-sidecar image: thanosio/thanos:v0.25.0 env: - name: POD_NAME valueFrom: fieldRef: fieldPath: metadata.name ports: - name: http-sidecar containerPort: 10902 - name: grpc containerPort: 10901 livenessProbe: httpGet: port: 10902 path: /-/healthy readinessProbe: httpGet: port: 10902 path: /-/ready volumeMounts: - mountPath: /data name: storage-volume - name: thanos-objectstorage subPath: objectstorage.yaml mountPath: /etc/objectstorage.yaml |
|---|
- 新增挂载秘钥
1 2 3 | - name: thanos-objectstorage secret: secretName: thanos-objectstorage |
|---|
- 重启 Prometheus
滚动升级会遇到如下错误，因为上一个 Prometheus Pod 没有释放文件目录导致。
1 | ts=2022-03-21T04:06:39.267Z caller=main.go:932 level=error err="opening storage failed: lock DB directory: resource temporarily unavailable" |
|---|
因此需要先将副本数设置为 0，在将其设置为 1，重启 Prometheus。
1 2 | kubectl -n monitor scale deploy prometheus-server --replicas=0 kubectl -n monitor scale deploy prometheus-server --replicas=1 |
|---|
5.5 在 Prometheus Sidecar 添加 Grpc 远程访问端口
- 编辑 Prometheus Service 配置
1 | kubectl -n monitor edit svc prometheus-server |
|---|
- 新增一个 Service 端口暴露 Grpc 服务给 Thanos Store Gateway
1 2 3 4 5 6 7 | ports: - name: sidecar-grpc nodePort: 30901 port: 10901 protocol: TCP targetPort: 10901 type: NodePort |
|---|
5.6 在 Thanos Query 添加 Store Grpc 地址
最后还需要在 Thanos Store Gateway 中添加上面 Prometheus Sidecar 的 Grpc 地址。
- 编辑 Thanos Query
1 | kubectl -n thanos edit deploy thanos-query |
|---|
- 在启动参数中添加
--store=0.0.0.0:30901
1 2 3 4 5 6 7 8 9 10 11 | - args: - query - --log.level=debug - --query.auto-downsampling - --grpc-address=0.0.0.0:10901 - --http-address=0.0.0.0:9090 - --query.partial-response - --query.replica-label=prometheus_replica - --query.replica-label=rule_replica - --store=0.0.0.0:30901 image: thanosio/thanos:v0.25.0 |
|---|
这里的 0.0.0.0:30901 需要替换为上面 Prometheus Sidecar 暴露的 Grpc 访问入口。这样，Thanos Query 提供查询能力时，短期数据就会调用 Grpc 查询，而不是查询对象存储中的数据。
此时，在上面提到 Thanos Query 页面以及可以看到新增的 0.0.0.0:30901 这个 Endpoint 记录，状态应该是 Up。
5.7 在 Minio 中查看同步的数据
一共添加了 6 个集群，每个集群大约 40 个 Pod，半天时间大约用了 2.1 GB 存储、303 个对象。
6. Grafana 配置
6.1 添加数据源
在 Grafana 添加 Thanos Query 数据源的方式和添加 Prometheus 一样。如下图:
6.2 修改 Grafana 面板适配 cluster 标签过滤
这里在基于 Kubernetes 集群查看的面板，稍微进行修改。
- 添加 cluster 过滤的变量
在上面，我在每一个 Prometheus 中都添加了一个全局的 external_labels，通过 cluster 字段来区分不同的集群。
如上图，在面板中添加一个 Cluster 变量，使用指标中的 cluster 标签进行过滤。
- 编辑每个视图的过滤查询条件
如上图，需要在每个视图的表达式中增加一个额外的过滤条件，cluster=~"^$Cluster$"}。当然，也可以将面板导出，在编辑器中批量修改之后再导入 Grafana。
6.3 查看 Thanos 和 Prometheus 数据源
- 使用 Thanos 数据源
- 使用 Prometheus 数据源
对比两个面板的数据，可以发现他们展示的指标一致。因此，我们可以使用一个 Thanos 数据源替代多个 Prometheus 数据源分散管理的场景。
这里数据的时间尺度没有达到 Thanos Compact 组件的参数设置，因此没有体现出降采样的效果。
7. 总结
本篇主要是阐述了监控数据层管理的一些想法。
首先是数据要分层，短期数据直接存储在就近的 Prometheus，长期数据存储在 Thanos 的对象存储中。短期数据提供给告警系统的高频查询，长期数据提供给人用于分析。
选择 Thanos 的主要原因是其降采样。Thanos compact 组件提供了 5 分钟、1 小时的降采样，以 Prometheus 每 15s 采样频率计算，压缩将达到 20 倍、240 倍，能够大大缓解长周期查询压力。采用 Sidecar 模式时，短期的数据会通过 Grpc 调用 Prometheus 的 API 查询。
最后当然是将本地用的 6 个集群都接入了 Thanos。只有亲自尝试过之后，才会真切地体会到其中的一些细节和处理逻辑。虽然架构图、文档、博客看了不少，但是都不如自己亲自尝试一次。
