prometheus运维指南

 线上使用prometheus主要使用如下组件：

• prometheus
• alertmanager
• blackbox
• node_exporter

自我感觉prometheus这一套学习成本有点高。主要原因可能是太抽象了，有一些地方可能还有一部分开发工作，不过当你完全掌握了这一套报警架构的时候，相信你会觉得这一切都是值得的。

prometheus使用

 prometheus，直接官网下载二进制文件，这里只分享一个线上的启动命令：

./prometheus --config.file=./prometheus.yml --storage.tsdb.retention=60d --web.enable-lifecycle --storage.tsdb.path=./tsdb_data/ --web.enable-admin-api

prometheus入门的主要难点可能是对如何监控指标有些摸不到头脑，还有就是不太理解label的含义以及内部一些处理逻辑。
在这里先分享一个配置文件,这里以node_exporter为例。

# my global config
global:
  scrape_interval:     15s # Set the scrape interval to every 15 seconds. Default is every 1 minute.
  evaluation_interval: 15s # Evaluate rules every 15 seconds. The default is every 1 minute.
  # scrape_timeout is set to the global default (10s).

# Alertmanager configuration
alerting:
  alertmanagers:
  - static_configs:
    - targets:
       - localhost:9093

# Load rules once and periodically evaluate them according to the global 'evaluation_interval'.
rule_files:
   - "rules/*.yml"

# A scrape configuration containing exactly one endpoint to scrape:
# Here it's Prometheus itself.
scrape_configs:

  # The job name is added as a label `job=<job_name>` to any timeseries scraped from this config.
  - job_name: 'prometheus'
  - 
    # metrics_path defaults to '/metrics'
    # scheme defaults to 'http'.

    static_configs:
    - targets: ['localhost:9090']

  - job_name: 'node_exporter_alert'
    scrape_interval: 10s
    metrics_path: /metrics
    file_sd_configs:
    - files: ['./file_sd_conf/*.json']
    relabel_configs:
      - source_labels: [__address__]
        regex: (.*):.*
        target_label: instance
      - source_labels: [__address__]
        regex: (.*)
        target_label: __address__
        replacement: $1:9100
        
  - job_name: 'blackbox-http'
    scrape_interval: 5s
    metrics_path: /probe
    params:
      module: [http_2xx]
    file_sd_configs:
    - files: ['./file_sd_conf/http-*.json']
    relabel_configs:
      - source_labels: [__address__]
        target_label: __param_target
      - source_labels: [__param_target]
        target_label: instance
      - target_label: __address__
        replacement: 10.41.144.153:9115
        

该配置分为四部分:

1. global:
   抓取(pull)时间间隔，默认是1m，抓取的是下面配置的scrape_configs内的对应配置项。

设置rules评估时间间隔，默认是1m,后面会新建rules目录存放对应报警规则使用。

1. alerting：
   告警管理配置，默认配置，只需要修改对应alertmanager的地址即可。
2. rule_files：
   新增目录rules来存放对应报警规则，后续会有rules的样例。
3. scrap_configs:
   这里配置的指标采集的配置项，一般靠job_name来区分，新增目录file_sd_configs存放所有的主机信息。

介绍设计思路

 想要打造一个监控平台，必须要考虑到需要监控的指标在哪，如何获取其次就是数据怎么发现，如何更好的把信息准确切详细的通知出来。
 相信大家都会有一个cmdb系统用于存放主机信息，如果没有自己cmdb信息肯定也会有阿里云提供给用户的API用来获取实时的主机数据，这些数据在业务侧需要提供一个定时脚本来把接口的主机信息序列化成prometheus可以识别的json或者yaml格式的数据。线上业务建议每个模块或者每个应用生成一个独立的json文件，该文件格式如下：

cat demo.json
[
  {
    "targets": [
      "192.168.0.1:18718/monitor/health"
    ],
    "labels": {
      "app": "demo-api",
      "hostname": "demo-01",
      "port": "18718",
      "product": "product-A",
      "region": "beijing",
      "url": "/monitor/health"
    }
  },
  {
    "targets": [
      "192.168.0.2:18718/monitor/health"
    ],
    "labels": {
      "app": "demo-api",
      "hostname": "demo-02",
      "port": "18718",
      "product": "product-A",
      "region": "wuhan",
      "url": "/monitor/health"
    }
  }
  ]

 在此要着重说明几个配置项,也是难点,很多人如果没看过官方文档只是随便搜了一下如何配置在这里肯定摸不到头脑了官方说明
 __address__标签本身是以IP:port的内置标签，不同监控有不同的内置标签，如consul有consul的内置标签，k8s有k8s的内置的meta标签，具体内部标签可以在status里的discover-labels里面查看，在此不做赘述。targets其实就是prometheus最终要去哪里获取对应的数据的endpoint，以node_exporter为例uri就是metrics，blackbox为例就是probe等等。也就是说你需要在通过json文件以及之前在主配置文件里面配置的相关处理方法让prometheus最终识别到你想让他去请求的地址。labels里面的数据都是可以从cmdb或者阿里云api里面获取到的数据。这些数据后面会以key名为labels的body发送给你的alertmanager，所以这里尽可能把你想要的数据都打上label。
 此处就是将targets的 "192.168.0.1:18718/monitor/health" 通过(.*):.*分组正则拿到ip地址，赋值给instance标签。然后还把__address__标签重通过正则分组变成$1:9100用于去获取node_exporter的数据。
 blackbox的监控数据需要修改__address__标签为整个的url。在此不用进行处理直接使用。9115端口服务会根据你的targets拿到的__address__标签去请求对应http接口。prometheus只需要从9115端口拿返回的结果就可以了。

规则配置

 下面介绍一下具体的报警规则的配置，以node_exporter为例所有的监控指标和说明直接请求对应服务的 9100/metrics 即可展示出来所以可以根据此来配置对应的报警规则。下面内存报警为例：

groups:
- name: "cpu检测"
  rules:
  - alert: "cpu负载告警"
    expr:  (100-(avg(irate(node_cpu_seconds_total{mode="idle",job="node_exporter_alert"}[5m]))by (instance,hostname,region,app,product)) * 100)   > 95
    for: 1m
    labels:
      severity: warning
    annotations:
      value: " {{ $value }} "
      summary: "{{ $labels.job}} - {{ $labels.instance }}  CPU使用率高于95%"
      description: "Prometheus 报警: cpu负载使用率超过95%\n 主机名: {{ $labels.hostname }}\n ip: {{ $labels.instance }}\n  当前值: {{ $value }}  \n 应用: {{ $labels.app }} \n 可用区: {{$labels.region}} \n 产品线: {{ $labels.product }} \n"

这里面要搞清楚2件事情，第一就是可以用job来筛选出来所有的targets也就是要监控的主机组信息，
第二就是通过自定义键值对用来，后面用alerts 来把所需要的值取出来，并发送报警。键值对类似如下：

{'receiver': 'webhook', 'status': 'firing', 'alerts': [{'status': 'firing', 'labels':

可以依靠status==firing来判断是报警还是恢复了。大家可以在测试的时候用web.py启动一个小型的web服务器来查看具体post的数据。

设计报警请求

首先去官网下载alertmanager的二进制文件。修改主配置文件如下:

global:
  resolve_timeout: 10s

route:
  group_by: ['alertname', 'app']
  group_wait: 30s
  group_interval: 10s
  repeat_interval: 1m
  receiver: 'webhook'

receivers:
- name: 'webhook'
  webhook_configs:
  - url: 'http://127.0.0.1:9347/'
    send_resolved: True

inhibit_rules:
  - source_match:
      severity: 'critical'
    target_match:
      severity: 'warning'
    equal: ['instance']    

 可以看到最终是否报警取决于instance维度，所以在prometheus主配置文件配置时，一定要把instance的label统一赋值。

 不同其他文件此处需要你自行开发一个接口来实现发送报警消息。此处采用python的小型web应用web.py实现。通过拿到post过来的数据里面的alerts的值来实现很多逻辑，如根据之前设置的product label发送给不同的人，根据主机，根据报警类型都可以区分开来，此处不再赘述。
线上启动alertmanager命令如下：

nohup ./alertmanager --config.file=./alertmanager.yml --storage.path=./data/ --log.level=debug --web.listen-address=0.0.0.0:9093 --data.retention=3h  >> logs/alertmanager.log 2>&1 &

总结

 prometheus的监控性能十分强大，单机跑到1500节点一点问题没有结合简单的开发可以实现足够多的定制化报警需求。也可以自己开发一些简单的程序甚至是脚本把数据push给gateway来实现监控目的。