写点什么

Thanos 升级顺序分析

作者:耳东@Erdong
  • 2023-01-02
    北京
  • 本文字数:2053 字

    阅读完需:约 7 分钟

Thanos 升级顺序分析

Thanos 作为 Prometheus 高可用的集群方案,功能强大,在使用上也是非常方便。当 Thanos 运行的时间长了以后,我们比如会遇到一个问题,那就是 Thanos 版本升级。接下来我们来看看如何安排 Thanos 的升级顺序和过程。

升级前的准备

Thanos 作为 Prometheus 的无侵入高可用解决方案,本身的运行状态对 Prometheus 没有任何影响,所以我们的整个升级过程对监控数据的采集、Prometheus 的运行,Prometheus 的本地数据存储都没有任何影响。


Thanos 在版本升级之前一定要仔细查看升级跨越的所以版本的发行注记,主要关注 2 个方面。


  • 1、是否有破坏性,不兼容的版本。

  • 2、是否有遗弃、废用的特性功能。


如果有上边两个方面的内容,一定要制定好对应的解决方案。


除了这两个方面以外,还可以关注一下,是否有新增的一些特性或者功能,升级以后这些新功能都可以带来新的改变,提升效率。

升级过程分析

一般按照之前的经验,Thanos 版本跨度在 5 个小版本之前一般不会出现不兼容的问题。

简单快速的升级顺序

所以如果追求快速升级的话,在准备好新版本程序包的情况下,只要先停掉 Thanos Compact 组件,然后依次重启各个组件就可以,因为重启的时间很快,基本任何一个组件一分钟就可以重启完成,对数据基本没有任何影响。

严谨的升级顺序

当然如果对升级过程比较严谨,那么我们一起来分析各个组件的情况,来确定一个升级顺序。这个升级过程有一个要求,那就是各个版本之间数据是兼容,如果出现不兼容的情况,请依照官方文档的指引进行升级。


Thanos 目前一共有这个几个组件,从前到后依次是 :


  • Query Frontend

  • Query

  • Rule

  • Sidecar / Receiver

  • Store

  • Compactor

  • Tools


这些组件里只有 Sidecar / Receiver 和 Compactor 会对数据进行写入操作,而且写入频率很低。


Sidecar 的写入时间间隔和 Prometheus 生成的数据块大小有关,比如 Prometheus 每两小时写一个块,那么 Sidecar 就每两小时写入一次。


Compactor 会定期检测对象存储里的数据是否需要降采样或者压缩,这个检测间隔是在配置文件里通过参数配置的。这个组件在升级过程中停掉就好,数据短时间不压缩以及降采样没有任何问题。


剩下的组件都是读数据,没有写的操作。


Query Frontend 和 Query 都是查询组件,Rule 是告警组件,Store 是核心的存储网关,但是也只起网关作用,并不会对数据进行读写。那么我们只要停掉写操作的组件,然后一次升级读操作的组件,就可以完成了。


特别提醒:1、按照该升级顺序,升级过程中可以提供数据查询功能,但是只能提供历史数据查询功能,无法提供实时数据查询。2、告警计算基本不受影响。3、数据写入没有影响。


接下来升级顺序如下:


  • 1、准备要升级的镜像或者二进制运行文件。

  • 2、修改 Query 的配置文件,将所有 Sidecar 节点下线,然后重启组件,使配置生效。

  • 3、停止 Sidecar / Receiver、Compactor、Tools 这三个组件。前两个是解决大家数据写入的担忧,Tools 这个组件在升级过程中没什么作用,防止大家对这个组件不知道到该干嘛,先停掉减少疑问。

  • 4、先升级核心组件 Store 。

  • 5、接下来依次升级 Query 和 Query Frontend ,如果这两个组件是单节点部署,那么可能会出现闪断的问题,如果是高可用部署,那么没有任何影响。

  • 6、升级 Rule 组件。

  • 7、接下来依次升级所有的 Sidercar。

  • 8、将升级好的 Sidecar 节点上线到 Query 组件的配置里。

  • 9、升级 Compactor 组件 并启动。

  • 10、升级 Tools 组件。

  • 11、验证所有组件正常工作,升级结束。

影响比较大的升级顺序

上边我们说了 2 种升级过程,其实还有一种,那就是停掉全部组件,然后在依次启动。这种方案需要中断对数据的查询,一般不到需要的时候不会选这种方案。当然,如果你遇到了,那么我们就一起看看怎么在这种情况下进行升级。


  • 1、准备要升级的镜像或者二进制运行文件。

  • 2、停止 Sidecar / Receiver、Compactor、Tools 这三个组件。

  • 3、停止 Rule

  • 4、停止 Query Frontend

  • 5、停止 Query

  • 6、停止 Store

  • 7、检查是否所有组件都停止成功

  • 8、开始依次升级启动。先升级 Store 并且启动

  • 9、升级 Sidecar 并且启动

  • 10、升级 Query 并且启动,进行简单的验证

  • 11、升级 Query Frontend 并且启动。

  • 12、升级 Rule 并且启动

  • 13、升级 Compactor 并且启动

  • 14、升级 Tools 并且启动

  • 15、验证所有的组件都已经启动,并且正常运行。


这样按照顺序就升级结束了。

升级过程后验证

升级过去都要验证,其中第一条就是所有组件的日志都是正常的,没有异常输出。


另外进行数据的查询,查询实时数据可以验证 Query 、Query Frontend 、对应的 Sidecar 的查询功能正常工作。


查询历史数据可以验证 Query 、Query Frontend 、Store 正常工作。


告警可以正常发送,说明 Rule 组件正常工作。


其他的功能验证可能需要时间长一些,比如等待 Prometheus 生成下一个数据块的时候,看看 Sidecar 的上传功能是否正常。


Thanos 的验证需要的时间可能更长一些,建议持续观察一天,看看数据压缩和数据降采样是否有问题。


如果发现问题,可以在官方仓库的 Issue 里看看有没有其他人遇到类似的问题,看看是否已经解决。

小结

到这里,Thanos 的升级过程就分析完了,祝大家的升级过程顺利。

发布于: 2023-01-02阅读数: 25
用户头像

耳东@Erdong

关注

🏆InfoQ写作平台-签约作者🏆 2020-05-24 加入

主要研究分享运维技术,专注于监控、CICD、操作系统、云原生领域,公众号【耳东学堂】,坚持原创,希望能和大家在运维路上结伴而行 邮箱:erdong@mail.erdong.site

评论

发布
暂无评论
Thanos 升级顺序分析_Prometheus_耳东@Erdong_InfoQ写作社区