Prometheus业务使用规范

Prometheus是目前比较流行的监控系统，广泛的exporter支持，同时可以自己开发exporter满足业务需求

1. kubernetes集群内部服务接入规范

目前prometheus部署在kubernetes内部exporter自动搜集指标，exoporter需要创建service，在service的metadataz中添加annotations:

prometheus.io/scrape: "true" #启用prometheus自动发现

prometheus.io/scheme: "http" #暴露的接口是http还是https

prometheus.io/path: "/metrics" #暴露的指标路径，默认是/metrics

prometheus.io/port: "10054" #暴露的端口，默认是80

prometheus配置自动获取指标

- job_name: 'kubernetes-service-endpoints'
kubernetes_sd_configs:
- role: endpoints
relabel_configs:
- source_labels: [__meta_kubernetes_service_annotation_prometheus_io_scrape]
action: keep
regex: true
- source_labels: [__meta_kubernetes_service_annotation_prometheus_io_scheme]
action: replace
target_label: __scheme__
regex: (https?)
- source_labels: [__meta_kubernetes_service_annotation_prometheus_io_path]
action: replace
target_label: __metrics_path__
regex: (.+)
- source_labels: [__address__, __meta_kubernetes_service_annotation_prometheus_io_port]
action: replace
target_label: __address__
regex: (.+)(?::\d+);(\d+)
replacement: $1:$2
- action: labelmap
regex: __meta_kubernetes_service_label_(.+)
- source_labels: [__meta_kubernetes_namespace]
action: replace
target_label: kubernetes_namespace
- source_labels: [__meta_kubernetes_service_name]
action: replace
target_label: kubernetes_name

2. kubernetes集群外部服务接入规范

kubernetes集群外部服务需要prometheus获取监控指标，需要部署exporter暴露指标完成

1. 部署exporter，本地测试访问url（官方提供），例：curl 127.0.0.1:9090/metrics，确保访问能获取到暴露的指标和正确的值

2. 如果prometheus访问exporter端口有限制，需要添加白名单活放开防火墙解除限制

3. 提供exporter的ip、端口、url（账户或证书）、报警指标和阈值给prometheus维护人员

4. prometheus维护人员添加监控获取配置和配置报警

5. 测试指标搜集和报警

export仓库: https://prometheus.io/docs/instrumenting/exporters/

3. 自开发exporter规范

对于业务系统没有通用的exporter提供服务，需要研发人员自己编写exporter

官方文档: https://prometheus.io/docs/instrumenting/writing_exporters/

3.1. 监控指标命名规范

1. metric前缀是一个singl-word，表示这个metric的归属，可以使用命名空间或者应用的名称命名
   • prometheus_notifications_total (specific to the Prometheus server)
   • process_cpu_seconds_total (exported by many client libraries)
   • http_request_duration_seconds (for all HTTP requests)
2. metric必须要有单位，比如字节，秒
3. 需要有单位名称的后缀，比如bytes、seconds、total(for count)
   • http_request_duration_seconds
   • node_memory_usage_bytes
   • http_requests_total (for a unit-less accumulating count)
   • process_cpu_seconds_total (for an accumulating count with unit)
4. 使用一个metric多lebels代替多metric
   例: http_responses_500_total http_responses_403_total可以使用一个metric代替： http_responses_total{code=500} http_responses_total{code=403}
   这样有利于统计，出图和报警规则的制定
5. labels定义
   使用labels来区分一个事件的特征
   • api_http_requests_total - differentiate request types: type="create|update|delete"
   • api_request_duration_seconds - differentiate request stages:
     stage="extract|transform|load"
     不可将标签名称放在metric名称中，因为这会引入冗余，如果聚合了相应的标签，则会引起混淆。键值标签对的每个独特组合都代表一个新的时间序列，可以显着增加存储的数据量。不要使用标签来存储具有高基数（许多不同标签值）的维度，例如用户ID，电子邮件地址或其他无限制的值集。
6. TYPE中需要添加metric types
   metric type标识了数据的类型，基本数据类型包括
   • Counter 表示收集的数据是按照某个趋势（增加／减少）一直变化的，我们往往用它记录服务请求总量、错误总数等。
   • Gauge 表示搜集的数据是一个瞬时的值，与时间没有关系，可以任意变高变低，往往可以用来记录内存使用率、磁盘使用率等。
   • Histogram 主要用于表示一段时间范围内对数据进行采样（通常是请求持续时间或响应大小），并能够对其指定区间以及总数进行统计，通常它采集的数据展示为直方图。
   • Summary 主要用于表示一段时间内数据采样结果（通常是请求持续时间或响应大小），它直接存储了 quantile 数据，而不是根据统计区间计算出来的。
7. 固定添加标签
   为了区别部门和业务，需要在metric中添加固定的标签进行标识，便于报警处理
   • department: capital
   • service: web|task|timer