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來實作監控目的。