标准规范
Prometheus 最重要的规范 : 指标命名方式，数据格式简单易读，用标签集来标识指标
应用层的监控，必要的标签 :
- 指标名 (metric , 即 name) : 当 Counter 类型，单调递增的值，指标名称以
_total结尾 - 服务名 (service) : 全局唯一，如 : n9e-webapi，p8s-alertmanager，一般是系统名称 + 模块名称 = 服务名称
- 实例名称 (instance) : 多个实例，用 ip + 端口标识，如 : 实例 1 : 10.1.2.3:3306，实例2 : 10.1.2.3:3307
- 服务类型 (job) : 如 : 区分服务 , 如 : MySQL 的标签 :
job=mysql，Redis 的标签 :job=redis - 地域可用区 (zone) : 标签 : 地域信息放到里，如 : 当某个 zone 出问题，容易找出区域问题
- 集群名称 (cluster) : 有时一个可用区会部署多个集群
- 环境类型 (env) : 标识 : 生产环境 , 还是测试环境
推拉模式
Prometheus 主要用拉模式获取指标
- Pushgateway : 辅助推模式
推模式的产品 , 如: Datadog、Open-Falcon、Telegraf+InfluxDB 组合
拉模式的特点 :
- 解耦 : 启动监控系统，只要调用中间件的接口就可
- 服务发现 : 当监控服务多 , 无需配置中间件的地址
- 可控性 : 监控系统为主动方，能控制频率
推模式特点 :
- 对中间件中=监控 , 要重新配置 , 并重启中间件，代价较大
- 网络 ACL 限制较严格，很多只能出不可进，该情况下 , 推模式的适配性更好
- 短周期任务或批处理任务，一般不用监听 HTTP 端口，就用推模式
- 客户端为主动方，当代码较拉，容易给监控系统造成压力
动态发现
老监控系统 (Zabbix) 的问题 : 对监控的目标都要在服务端静态注册、配置
- 动态发现机制 : 而现在云原生的流行 , 导致基础设施动态化，监控目标的创建、销毁都较频繁 , 就需要动态发现监控目标
Prometheus 内置了多种服务发现机制 :
- 基于配置文件的发现机制：较常用，只要配合配置管理工具一起使用，让监控系统重新加载一下
- 基于 Kubernetes 的发现机制：Kubernetes 中有很多元信息，通过调用 kube-apiserver，就能拿到 Pod、Node、Endpoint 信息
- 基于公有云 API 的发现机制：基于公有云的 OpenAPI 做个服务发现机制，自动拉取相关账号下所有 RDS 实例列表，降低管理成本
- 基于注册中心 (Consul , Nacos) 发现机制：场景 : PING 监控和 HTTP 监控，将监控目标注册到 Consul 中，再读取 Consul 生成监控对象列表就可
基于配置文件管理
Prometheus 的告警规则管理、记录规则管理、抓取配置管理与发送策略管理，全是基于配置文件
该方式的好处 :
- 简单，用 Yaml 文件
- 便于自动化，配合配置管理工具、Git、Kubernetes 控制
查询
PromQL 为二次计算提供支持，允许多个指标的关联计算、多条件联合告警