- 监控的分层
如上图，在建设监控系统时，会采用两种策略:
- 分层监控。IaaS、MySQL 中间件、App 层监控分开的好处是，系统之间具有高可用性、容错性。当 App 层监控无法工作时，IaaS 层监控立马就会体现出来。
- 长短期指标分离。短期指标用来提供给告警系统高频查询近期数据，长期指标用来提供给人查询时间跨度更大的数据集。
这里将其统称为监控的分层策略，只不过一个是以基础设施维度的分层，一个是以时间维度的分层。
- 现状与选型
目前的状况是: 没有进行监控的长短期分层，共用一套 Prometheus。查询长周期指标时，Prometheus 所在服务器内存、CPU 使用率飙升，甚至导致监控、告警服务不可用。
原因在于两点:
- 查询长周期数据时，Prometheus 会将大量数据载入内存
- Prometheus 载入的不是降采样数据
查询的范围越大，需要的内存就越多。在另外一个生产的方案中，我们采用 VictoriaMetrics 单机版作为远端存储，部署的内存高达 128 GB 。同时，这种方式下还存在丢数据的情况。
而 Prometheus Federation 的方式，只是解决了将多个 Prometheus 聚合起来，并没有提供抽样的能力，不能加快长期指标的查询，不适用于当前远端存储的场景。
最后看到 Thanos Compact 组件能够对指标数据进行压缩和降采样，决定尝试使用 Thanos 作为目前多个 Prometheus 远端存储使用。
- 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 实例
- 部署 Thanos
4.1 部署一个 Minio
请参考文档: Jenkins 中的构建产物与缓存[1]
安装完成之后，请根据文档中的配置进行测试，确保 Minio 服务正常工作。
4.2 在 Minio 上创建一个名为 thanos 的 Bucket
如下图：
4.3 检查 Prometheus 版本符合 Thanos 要求
目前 Thanos 要求 Prometheus 版本最好不低于 v2.13。
4.4 部署 Thanos
- 确保 Kubernetes 集群上有默认的存储可用
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
kubectl create ns thanos
- 部署 Thanos
git clone https://github.com/shaowenchen/demo
修改 demo/objectstorage.yaml 文件中的 Minio 访问地址。然后创建 Thanos 相关负载:
kubectl apply -f ./demo/thanos-0.25/
- 查看相关负载
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 相关服务的端口
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 组件提供的页面。
- 给 Prometheus 添加 Thanos Sidecar
Sidecar 模式对 Thanos 配置要求更低，而 Receiver 模式需要不停地接受来自众多 Prometheus 的 Remote Write，这里出于成本考虑选择 Sidecar 模式。
5.1 在 Prometheus 所在命名空间新增 S3 访问凭证
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 实例全局添加一个额外的标签，用于唯一标记一个实例。
- 编辑配置文件
kubectl -n monitor edit cm prometheus-server
- 添加如下内容
prometheus.yml: |
global:
external\_labels:
cluster: dev
这里添加了一个名为 cluster=dev 的标签。所有该 Prometheus 实例上报的指标都会带上此标签，方便查询过滤。
5.3 修改 Prometheus 启动参数关闭压缩
- 编辑 Prometheus 部署文件
有的是用 Deployment，有的是用 StatefulSet 部署，都需要修改 Prometheus 的启动参数
kubectl -n monitor edit deploy prometheus-server
- 修改 tsdb 存储块最大、最小值相等
- --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 部署文件
kubectl -n monitor edit deploy prometheus-server
- 新增如下容器
- 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
- 新增挂载秘钥
- name: thanos-objectstorage
secret:
secretName: thanos-objectstorage
- 重启 Prometheus
滚动升级会遇到如下错误，因为上一个 Prometheus Pod 没有释放文件目录导致。
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。
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 配置
kubectl -n monitor edit svc prometheus-server
- 新增一个 Service 端口暴露 Grpc 服务给 Thanos Store Gateway
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
kubectl -n thanos edit deploy thanos-query
- 在启动参数中添加
--store=0.0.0.0:30901
- 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 个对象。
- 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 组件的参数设置，因此没有体现出降采样的效果。
- 总结
本篇主要是阐述了监控数据层管理的一些想法。
首先是数据要分层，短期数据直接存储在就近的 Prometheus，长期数据存储在 Thanos 的对象存储中。短期数据提供给告警系统的高频查询，长期数据提供给人用于分析。
选择 Thanos 的主要原因是其降采样。Thanos compact 组件提供了 5 分钟、1 小时的降采样，以 Prometheus 每 15s 采样频率计算，压缩将达到 20 倍、240 倍，能够大大缓解长周期查询压力。采用 Sidecar 模式时，短期的数据会通过 Grpc 调用 Prometheus 的 API 查询。
最后当然是将本地用的 6 个集群都接入了 Thanos。只有亲自尝试过之后，才会真切地体会到其中的一些细节和处理逻辑。虽然架构图、文档、博客看了不少，但是都不如自己亲自尝试一次。
- 参考
- https://thanos.io/tip/thanos/quick-tutorial.md/
- https://artifacthub.io/packages/helm/bitnami/thanos
- https://github.com/shaowenchen/demo
- https://imroc.cc/post/202004/build-cloud-native-large-scale-distributed-monitoring-system-3/
参考资料
[1] Jenkins 中的构建产物与缓存: https://www.chenshaowen.com/blog/artifacts-and-cache-in-jenkins.html#11-部署-minio