学习笔记——《运维监控系统实战笔记》 05｜Prometheus中有哪些关键设计？
标准先行，注重生态
统一的标签集表达方式是最通用、最灵活的。虽然标签集很灵活，但是在实际落地时，我强烈建议你在公司推行一个标签定义规范，标签 Key 不能随便起名，该有的标签也不能缺失。既减少了理解成本，也保证了数据的规整完备，便于后续做数据分析。
主要使用拉模式，解耦
如果服务没有部署在 Kubernetes 中，而是部署在传统物理机或虚拟机上，这个时候就需要使用 Consul 之类的服务发现机制。但如果在监控体系建设之前，服务没有接入注册中心，为了满足监控需求而接入注册中心，用户会觉得成本太高。此时推模式就有了用武之地，这就是很多公司的自研服务都使用推模式发送监控数据的原因。
所以结论就来了：中间件类使用拉模式，自研的服务使用推模式，自研的服务如果都接入了注册中心，则也可以使用拉模式。
短周期任务或批处理任务，通常不太可能监听 HTTP 端口，这种大概率也是推模式。
推模式服务端通常比较容易处理，因为数据接收是无状态的。但是拉模式在数据量大的时候要考虑分片的问题，还有就是失联告警问题，拉模式很容易感知到目标失联。推模式就比较复杂了，需要对数据缺失做告警。
可控性问题，拉模式，监控系统是主动的一方，可以控制频率；推模式，客户端是主动的一方，如果代码写“挫”了，就会给监控系统造成很大压力。
监控目标动态发现机制
Prometheus 内置了多种服务发现机制，最常见的有四种：
- 基于配置文件的发现机制
- 基于 Kubernetes 的发现机制
- 基于公有云 API 的发现机制
- 基于注册中心的发现机制
灵活的查询语言
很多老一代监控系统都只能对数据做简单过滤判断阈值，没有 QL 的支持。当我们想要某个数据却发现没有的时候，就天然倾向于在采集侧处理，但是采集侧是无法穷举所有计算场景的，采集侧应该采集原始数据，后续的二次计算还是应该放到中心来搞定。
PromQL 为二次计算提供了能力支持，多个指标的关联计算、多条件联合告警，都可以用 PromQL 来实现，作为现代监控系统，Query Language 已经是必备要求了。
总结
附录
文章内容来源于极客时间《运维监控系统实战笔记》，原文链接为： time.geekbang.org/column/arti…