多kubernetes集群中,Prometheus 负责将监控数据写入 Thanos 存储网关，而 Thanos 查询网关则允许从 Thanos 存储网关中读取和查询数据。这种集成允许 Prometheus 在持久化存储和跨集群查询方面获得扩展性和弹性。

kube-prometheus

原名为prometheus-operator,可参考之前的Prometheus-Operator监控k8s

官方github
https://github.com/prometheus-operator/kube-prometheus.git

整体部署

1
2
3

git clone <https://github.com/prometheus-operator/kube-prometheus.git>

cd kube-prometheus/manifests

执行crd创建，因crd内容比较多，使用apply会提示long错误，此处使用create进行创建

1	kubectl create -f setup/

创建kube-prometheus组件所有服务

1	kubectl apply -f .

创建完毕后会提供如下新增Kind

如何进行对应Kind的创建，官方介绍

thanos

开源、高度可用的 Prometheus 设置具有长期存储功能

全局查询视图

通过跨多个 Prometheus 服务器和集群查询 Prometheus 指标来扩展 Prometheus 设置。

无限保留

使用您选择的对象存储来扩展系统，以无限期地存储您的指标。支持GCP、S3、Azure、Swift和腾讯COS。

普罗米修斯兼容

使用您喜欢的相同工具，例如 Grafana 和其他支持 Prometheus Query API 的工具。

下采样和压缩

在查询大时间范围或配置复杂的保留策略时，对历史数据进行下采样以大幅提高查询速度。

组件服务

thanos-sidecar

prometheus pod会新增一个容器，使用thanos容器镜像，启动时传参为sidecar，代表这是thanos-sidecar服务，sidecar会默认间隔2小时上传Prometheus 数据到对象存储(阿里云oss/S3一类)。
thanos-sidecar会代理prometheus，让thanos-query对prometheus服务的所有数据进行访问

thanos-query

与prometheus管理界面相同功能，实现对多个prometheus进行聚合，同样是使用thnaos容器镜像，指定参数为query，并且指定endpoint使用grpc协议向底层组件(边车thanos-sidecar,存储thanos-store）获取数据
可以对监控数据自动去重

thanos-query-frontend

当查询的数据规模较大的时候，对thanos-query组件也会有很大的压力，thanos-query-frontend组件来提升查询性能，thanos-query-frontend组件连接对象是thanos-query

thanos-store

thanos-sidecar将prometheus数据上传到了对象存储，需要进行查询就需要经过thanos-store的处理提供给thanos-query进行查询
并且thanos-store提供了缓存，加快查询速度的功能

thanos-compactor

将云存储中的数据进行压缩和下采样和保留
管理对象存储中的数据(管理、压缩、删除等)

thanos-ruler

连接对象是thanos-query，经过thanos-query组件定期地获取指标数据，主要是prometheus的记录规则(record)和报警(alert)规则，其本身不会抓取metrics接口数据
可将记录规则(record)上传到对象存储中
可连接alertmanager服务统一将告警信息发送至alertmanager
建议：避免alertmanager服务告警过于复杂，报警(alert)规则还是由各kubernetes集群prometheus进行处理

thanos-receive

存在2个小组件thanos-receive-router和thanos-receive-ingestor
thanos-sidecar上传数据到对象存储，但是数据上传并不是实时的，而是默认2h上传一个数据块，所以对象存储的数据并不是实时的，prometheus需要对数据进行持久化，这也是thanos-sidecar模式的弊端
prometheus使用remote-write协议调用thanos-receive-router的api(/api/v1/receive),thanos-receive-router会将thanos-receive-ingestor的集群节点信息告诉prometheus，prometheus将会往thanos-receive-ingestor进行数据推送
thanos-receive-ingestor则会将数据上传到对象存储中
thanos-query会关联thanos-receive-ingestor，以查询对应kubernetes集群的prometheus数据

架构

架构分为2种模式

sidecar模式
receive模式

sidecar模式

receive模式

kube-prometheus-thanos部署

部署

提供经过我进行优化部署后的kube-prometheus+thanos的部署文件:kube-prometheus-thanos.zip
prometheus仅选择报警规则，thanos-ruler仅选择记录规则，由prometheus负责往alertmanager进行告警发送

1	cd kube-prometheus-thanos

执行crd创建，因crd内容比较多，使用apply会提示long错误，此处使用create进行创建

1	kubectl create -f setup/

创建kube-prometheus组件所有服务

1	kubectl apply -f .

创建优化过的kube-prometheus组件服务

1	kubectl create -f new/

创建thanos组件服务

1	kubectl create -f new/thanos

本次部署是sidecar模式的部署，receive模式的部署在yaml是注释了的

sidecar模式和receive模式配置区别

prometheus-prometheus.yaml分别配置是thanos-sidecar的配置还是remote-write的配置
thanos-query.yaml中配置是连接thanos-receive-ingestor还是连接thanos-sidecar

--endpoint=dnssrv+_grpc._tcp.thanos-receive-ingestor-default.monitoring.svc.cluster.local:10901
or
--endpoint=dnssrv+_grpc._tcp.prometheus-operated.monitoring.svc.cluster.local:10901
of
配置ip的话
--endpoint=ip:10901

部署功能说明

alert-rules.yaml：对kubernetes集群的常用alert告警
alertmanager-temp-configmap.yaml：自定义的企业微信告警模板
alertmanager-secret.yaml：修改alertmanager配置，具体介绍请参考alertmanager告警
prometheus-prometheus.yaml：定义了是sidecar模式的thanos-sidecar还是receive模式的remote-write
thanos-objectstorage-secret.yaml：thanos组件使用的对象存储配置,可参考官方介绍
new目录下的thanos-receive目录是receive模式的部署文件

注意事项

1.level=warn ts=2023-06-26T06:14:54.058940439Z caller=shipper.go:239 msg=”reading meta file failed, will override it” err=”failed to read /prometheus/thanos.shipper.json: open /prometheus/thanos.shipper.json: no such file or directory”

解决方案:
使用thanos sidecar模式时，sidecar 会读取prometheus数据目录下的thanos.shipper.json文件，文件主要作用是当sidecar上传到对象存储时，会更新记录到此文件中。
出现上面的原因是thanos.shipper.json文件的权限是root，sidecar权限不够没法读取和写入，sidecar自身又没有重试读取的机制所以就算进入容器将这个文件重新授权为可写入和读取都不行，只能将prometheus进行持久化后进行这个文件授权777，然后重启prometheus整个pod

2.kube-prometheus支持配置日志等级debug来查看具体错误各组件支持 logLevel: debug

3.企业微信现在申请机器人需要配置可信IP了，不然无法调用机器人