标准规范
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 为二次计算提供支持,允许多个指标的关联计算、多条件联合告警