前言
在前文中，prometheus基本的用法都简单的描述一遍，最后本文来讨论一下prometheus高可用的问题
环境准备
| 组件 | 版本 |
|---|---|
| 操作系统 | Ubuntu 22.04.4 LTS |
| docker | 24.0.7 |
| thanos | 0.36.1 |
1. 双prometheus架构
- 2个prometheus采集同一份metrics，一旦有一个出问题，另外一个补上去就行了
- 该架构保证了prometheus服务的可用性以及数据的可用性
- 但是会有数据冗余，始终采集了一份数据作为备用，并且prometheus单点压力过大
2. 做横向拆分的多prometheus架构
- 将数据拆分组，并且有不同的prometheus采集，并且prometheus也进行拆分，减少单点的压力
- 该架构既保证了prometheus服务可用性和数据可用性，又减少了prometheus单点压力
- 数据依然有冗余，始终采集了一份数据作为备用，并且数据入口很分散，分组越多，会导致数据入口越分散
3. 多prometheus+数据统一查询架构
- 有了统一的数据查询入口，使得web可以实时查询任一时刻的监控数据，如果数据已经超出了prometheus保留期，那也可以去外部存储上获取历史数据
- 该架构继承了架构2的优点，并且解决了：1）查询入口分散的问题；2）查询历史数据的问题
- 该架构的配置复杂度与日常的维护成本就很高了
4. 更复杂的架构
以下思考纯属个人观点，抛砖引玉而已
监控的本质问题，就在于准确获取metrics，并且对其进行分析，所有的架构都是围绕着这个目标来进行的，小到单点，大到多区域多中心，都不例外
对于获取metrics，比较关注获取速度、数据准确度以及覆盖范围
- 获取速度，需要考虑：内网采集？跨公网vpn隧道采集？直接公共网络采集？
- 数据准确度，需要考虑：多机器的时间是否统一？采集资源是否充足？
- 覆盖范围，需要考虑：所选的exporter是否准确？
对于分析metrics，比较关注数据持久性、数据安全、分析实时性
- 数据持久性，需要考虑：历史数据要保存多久？新鲜数据和老数据分别去什么地方获取？
- 数据安全，需要考虑：数据是否是敏感数据？怎么防止数据泄露？
- 分析实时性，需要考虑：多中心部署下怎么保证数据获取速度？多备份下采用哪一个备份的数据是最合理的？
小结
至此，k8s prometheus监控系列结束，期待下一个系列见，谢谢大家
联系我
- 联系我，做深入的交流
至此，本文结束
在下才疏学浅，有撒汤漏水的，请各位不吝赐教...