2022-07-05 23:03:24

promethues系列(一)

谈谈架构

玩具规模

玩具/小项目,用单实例 Prometheus就够了,本身云服务器就有一定的可用性保障,大部分故障都能够热迁移;数据云盘三副本起,可用性6个9,还不够吗?至于监控挂?进程管理工具帮你解决,远比你双实例来得靠谱。

中小规模

  1. prometheus + m3db支撑
  2. prometheus * 2 + thanos支撑

中大规模

prometheus必须考虑分片

一种是基于hashmod的人工分片法,有限扩张的场景,肯定是能满足需求的,就是有些麻烦,必须考虑target是否均衡,采集/计算压力是否均衡。

一种是基于协同分配的自动分片法,比如腾讯开源的kvass项目,引入coordinator,分析采集目标,并预估每个target当前的series数量,然后周期性的检测平衡每个prometheus实例的target数量,并且能够自动扩容。

显然第二种方式优于第一种,但是复杂度也高于第一种;两种模式都必须引入thanos-rule,将record rule以及alert rule都剥离出来,交给thanos-rule统一管理,对表达式计算的稳定性和时延都有一定的挑战。

谈谈使用

这里的使用包括两部分:

  1. 如何暴露指标
  2. 如何查询指标

暴露指标

框架层面统一公共指标;团队注册指定业务指标,满足:

  • 尽可能简短指标名称明确有规范
  • label包含有限少量种类/值
  • 暴露一些原数据指标用于提供信息,方便join查询,也方便做服务关系
  • label只有字符串,能01表示开关的,别傻了吧唧的true/false
  • 正确使用指标类型,无须关心具体指标细节的,直接使用client端的summary或者histogram,别把什么压力都交给server

查询指标

人工查询的其实很少,基本都是展示工具使用,比如grafana,所以最好:

  • 通用指标合理使用record rule 预处理指标,加速查询,降低资源消耗
  • step period refresh时间设置合理的值,最好能强制最小值,防止风暴
  • prometheus的retention尽可能小,比如6h;让6h以前的数据跑thanos-store查去,store支持downsampling,能更快的查询,而prometheus不支持。
  • 很多时候promql结合元数据指标,就可以直接获取你想要的数据结果

本文链接:https://troy.wang/post/prometheus-1.html

-- EOF --