Thanos 是一个基于 Prometheus 实现的监控方案,其主要设计目的是解决原生 Prometheus 上的痛点,并且做进一步的提升,主要的特性有:全局查询,高可用,动态拓展,长期存储。
下图是 Thanos 官方的架构图:
图片
Thanos组件
Thanos是一组组件,可以组合成一个具有无限存储容量的高可用指标系统,Thanos 主要由如下几个特定功能的组件组成:
- 边车组件(Sidecar):连接 Prometheus,并把 Prometheus 暴露给查询网关(Querier/Query),以供实时查询,并且可以上传 Prometheus 数据给云存储,以供长期保存
- 查询网关(Querier/Query):实现了 Prometheus API,与汇集底层组件(如边车组件 Sidecar,或是存储网关 Store Gateway)的数据
- 存储网关(Store Gateway):将云存储中的数据内容暴露出来
- 压缩器(Compactor):将云存储中的数据进行压缩和下采样
- 接收器(Receiver):从 Prometheus 的 remote-write WAL(Prometheus 远程预写式日志)获取数据,暴露出去或者上传到云存储
- 规则组件(Ruler):针对监控数据进行评估和报警
- Bucket:主要用于展示对象存储中历史数据的存储情况,查看每个指标源中数据块的压缩级别,解析度,存储时段和时间长度等信息。
读取指标的流程
- 首先客户端通过 query API 向 query 发起查询,query 将请求转换成 StoreAPI 发送到其他的 query、sidecar、rule 和 store 上。
- sidecar 接收到来自于 query 发起的查询请求后将其转换成 query API 请求,发送给其绑定的 Prometheus,由Prometheus 从本地读取数据并响应,返回短期的本地采集和评估数据。
- rule 接收到来自于 query 发起的查询请求后直接从本地读取数据并响应,返回短期的本地评估数据。
- store 接收到来自于 query 发起的查询请求后首先从对象存储桶中遍历数据块的 meta.json,根据其中记录的时间范围和标签先进行一次过滤。接下来从对象存储桶中读取数据块的 index 和 chunks 进行查询,部分查询频率较高的index 会被缓存下来,下次查询使用到时可以直接读取。最终返回长期的历史采集和评估指标。
对于发送报警的流程如下所示:
- Prometheus 根据自身配置的 alerting 规则定期地对自身采集的指标进行评估,当告警条件满足的情况下发起告警到 Alertmanager 上。
- rule 根据自身配置的 alerting 规则定期的向 query 发起查询请求获取评估所需的指标,当告警条件满足的情况下发起告警到 Alertmanager 上。
- Alertmanager 接收到来自于 Prometheus 和 rule 的告警消息后进行分组合并后发出告警通知。
特性(优势)
Thanos 相比起原生的 Prometheus 具有以下的一些优势:
- 统一查询入口——以 Query 作为统一的查询入口,其自身实现了 Prometheus 的查询接口和StoreAPI,可为其他的 Query 提供查询服务,在查询时会从每个 Prometheus 实例的 Sidecar 和 Store Gateway 获取到指标数据。
- 查询去重——每个数据块都会带有特定的集群标签, Query 在做查询时会去除集群标签,将指标名称和标签一致的序列根据时间排序合并。虽然指标数据来自不同的采集源,但是只会响应一份结果而不是多份重复的结果。
- 高空间利用率——每个 Prometheus 本身不存储长时间的数据,Sidecar 会将 Prometheus 已经持久化的数据块上传到对象存储中。Compactor 会定时将远端对象存储中的长期数据进行压缩,并且根据采样时长做清理,节约存储空间。
- 高可用——Query 是无状态服务,天生支持水平拓展和高可用。Store、Rule 和 Sidecar 是有状态服务,在多副本部署的情况下也支持高可用,不过会产生数据冗余,需要牺牲存储空间。
- 存储长期数据——Prometheus 实例的 Sidecar 会将本地数据上传到远端对象存储中作为长期数据
- 横向拓展——当 Prometheus 的指标采集压力过大时,可以创建新的 Prometheus 实例,将scrape job 拆分给多个 Prometheus,Querier 从多个 Prometheus 查询汇聚结果,降低单个 Prometheus 的压力
- 跨集群查询——需要合并多个集群的查询结果时,仅需要在每个集群的 Querier 之上再添加一层 Querier 即可,这样的层层嵌套,可以使得集群规模无限制拓展。
对象存储
一般来说, 我们将存储分为文件存储, 块存储和对象存储.
- 文件存储: 一般都是POSIX协议的,比如我们的操作系统上的XFS,EXT4
- 块存储: 一般都是有虚拟化层实现的,有可能是kernel自带的模块,如AWS的EBS
- 对象存储: 对象存储通常向外提供API接口,系统通过网络向对象存储的接口传输数据.公有云的代表,AWS的s3,私有云的就是MinIO,案例中我也将用MinIO来作为存储.
部署案例
在了解了Thanos的架构和组件服务之后,下面将进行实战配置安装。准备4台虚拟机,配置如下:
部署Promethues
修改配置文件
system文件
--storage.tsdb.min-block-duratinotallow=5m--storage.tsdb.max-block-duratinotallow=5m 默认为2h, 修改为5分钟, sidecar向store写入数据,方便查看效果.
Node_exporter 安装
创建system文件
vim /usr/lib/systemd/system/node_exporter.service
部署 Thanos
Thanos 只需要两个组件就可以简单形成一个集群,query和sidecar用来抽象数据层,query 来查询抽象出来的数据层,提供查询的接口,
根据Thanos架构图,不考虑高可用的情况下除了sidecar组件外,query,store,Compactor组件只需部署一份
Thanos sidecar
- systemd 文件
Thanos query
node1执行
- systemd文件
部署MinIO
Minio存储架构
- 单主机,单硬盘模式: Minio只在一台服务器上搭建服务,且数据都存在单块磁盘上,该模式存在单点风险
- 单主机,多硬盘模式: Minio在一台服务器上搭建服务,但数据分散在多块(大于4块)磁盘上,提供了数据上的安全保障 (类似于容器模式)
- 多主机,多硬盘模式(分布式): 该模式是Minio服务最常用的架构,通过共享一个access_key和secret_key,在多台(2-32)服务器上搭建服务,且数据分散在多块(大于4块,无上限)磁盘上,提供了较为强大的数据冗余机制
准备工作
这里我们采用分布式存储,在四台服务器上进行安装.
注意: data目录不可以和root目录在同一磁盘,需要另外添加磁盘。错误信息 :ispart of root disk, will not be used (*errors.errorString)
MinIO配置文件
- 用户信息 vim /etc/minio/minio.pw
这里指定了4台minio的地址,通过统一的minio.pw和启动文件,可以让4台minio做到数据互通。minio会依次启动,顺序为参数的先后顺序
- systemd文件vim /etc/systemd/system/minio.service
负载均衡
在node1 配置nginx vim /etc/nginx/conf.d/minio.conf
Thanos Store
- systemd文件vim /etc/systemd/system/thanos-store.service
- 配置对象存储配置文件vim /etc/thanos/thanos-minio.yml
在 node3, node4 ,sidecar的system文件添加
在 node1 query 的system文件添加store的grpc地址
为了展示对象存储的效果,我们把node3和node4, sidecar的地址删除,只查询store的地址,这样我们就可以在grafana看到下图, 可以看到提供的信息并不是实时的,而是store写入对象存储的数据, 这只是为了测试store的可用性,实际环境中,数据的写入默认为2h一次,不符合监控实时性的要求.
Thanos compact
node1执行:
compact的作用是定期把历史数据存入对象存储,其实他就像是一个cronjob, 如果发现满足了条件,就会对对象存储中的数据进行整理
- 初始化
- systemd文件vim /etc/systemd/system/thanos-compact.service
Prometheus自动注册
部署Consul
- node2
创建配置文件 vim /etc/consul/server.json
创建守护进程 vim /etc/systemd/system/consul-server.service
启动consul并测试
浏览器访问 8500端口,提示需要登录
使用 consul acl bootstrap 记录SecretID 作为token
把token添加到配置文件
vim /etc/consul/server.json
重启consul
github 地址: https://github.com/starsliao/ConsulManager
准备工作
添加镜像仓库
yum-``config``-manager--add-repo**https://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.repo
使用docker-compose来部署ConsulManager
- 下载:wget https://starsl.cn/static/img/docker-compose.yml(仓库根目录下docker-compose.yml)
- 编辑:docker-compose.yml,修改3个环境变量:
consul_token:consul的登录token(上文获取的,SecretID)
consul_url:consul的URL(http开头,/v1要保留)
admin_passwd:登录ConsulManager Web的admin密码
启动:docker-compose pull && docker-compose up -d
访问:http://{IP}:1026,使用配置的ConsulManager admin密码登录
添加主机监控
安装完成后,在平台新增监控主机的信息
图片
添加完成后,查看consul;
图片
配置prometheus读取consul信息;
图片
将之前配置好的内容删除,添加生成的配置信息;
图片
查看query, grafana,显示注册完成;
图片
图片
在本文中,我们详细探讨了Thanos监控系统的部署过程,包括系统架构介绍、各个组件的配置和完整的部署案例。Thanos为Prometheus提供了强大的监控解决方案,具备全局查询、高可用性、动态扩展和长期存储等特性。借助Thanos,我们能够高效管理大规模监控数据,并通过丰富的组件和集成功能,构建一个强大而可靠的监控生态系统。我们希望本文能为那些寻求提升监控系统性能和扩展性的用户提供有价值的指导。随着技术的不断进步,Thanos将持续发展,我们期待它在未来带来更多创新与可能性。