标准先行，注重生态

Prometheus 最重要的规范就是指标命名方式，数据格式简单易读。虽然标签集很灵活，但是对于应用层面的监控，需要具备以下信息：

指标名称 metric
服务名称 service
实例名称 instance
地域可用区 zone(region 就可有可无)
集群名称 cluster
环境类型 env

主要使用拉模式，更好解耦，辅助推模式

对于各类中间件，特别是非常基础的那些，很大概率是先于监控系统部署的。如果是拉模式，部署好监控系统之后，再来调用中间件的接口获取数据即可。如果是推模式，就需要在中间件里重新配置监控数据上报地址，然后重启中间件，这个代价就太高了。

Prometheus 内置了多种服务发现机制，最常见的有四种:

基于配置文件的发现机制
基于 Kubernetes 的发现机制
基于公有云 API 的发现机制
基于注册中心的发现机制

Prometheus 的告警规则管理、记录规则管理、抓取配置管理与发送策略管理，全部是基于配置文件的，这样做有两点好处：

简单: 简单到令人发指，Prometheus直接使用 Yaml 文件保存各类配置，非常直观
便于自动化：可以配合配置管理工具、Git、Kubernetes 等，与 Infrastructure as Code 的管理风潮非常契合。

PromQL（Prometheus Query Language）是Prometheus的查询语言，非常灵活，它为二次计算提供了能力支持，支持多个指标的关联计算、多条件联合告警。

此文章为9月Day 12学习笔记，内容来源于极客时间《运维监控系统实战笔记》。