谈谈架构
玩具规模
玩具/小项目，用单实例 Prometheus就够了，本身云服务器就有一定的可用性保障，大部分故障都能够热迁移；数据云盘三副本起，可用性6个9，还不够吗？至于监控挂？进程管理工具帮你解决，远比你双实例来得靠谱。
中小规模
- prometheus + m3db支撑
- prometheus * 2 + thanos支撑
中大规模
prometheus必须考虑分片
一种是基于hashmod的人工分片法，有限扩张的场景，肯定是能满足需求的，就是有些麻烦，必须考虑target是否均衡，采集/计算压力是否均衡。
一种是基于协同分配的自动分片法，比如腾讯开源的kvass项目，引入coordinator，分析采集目标，并预估每个target当前的series数量，然后周期性的检测平衡每个prometheus实例的target数量，并且能够自动扩容。
显然第二种方式优于第一种，但是复杂度也高于第一种；两种模式都必须引入thanos-rule，将record rule以及alert rule都剥离出来，交给thanos-rule统一管理，对表达式计算的稳定性和时延都有一定的挑战。
谈谈使用
这里的使用包括两部分：
- 如何暴露指标
- 如何查询指标
暴露指标
框架层面统一公共指标；团队注册指定业务指标，满足：
- 尽可能简短指标名称明确有规范
- 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结合元数据指标，就可以直接获取你想要的数据结果
问题
- 针对大查询，没有很好的保护，内存容易爆
- prometheus pod异常重启后，会偶现compaction问题，只能重启自愈（删除校验失败的数据）
- thanos 针对 histgram 类的查询，没啥优化，消耗thanos query 较多内存资源，容易oom