重剑无锋--从零开始建设k8s监控之总结（八）

前言

在前文中，prometheus基本的用法都简单的描述一遍，最后本文来讨论一下prometheus高可用的问题
环境准备

组件版本操作系统Ubuntu 22.04.4 LTSdocker24.0.7thanos0.36.11. 双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监控系列结束，期待下一个系列见，谢谢大家
联系我

• 联系我，做深入的交流
  
  
  
  

至此，本文结束
在下才疏学浅，有撒汤漏水的，请各位不吝赐教...

来源：豆瓜网用户自行投稿发布，如果侵权，请联系站长删除