Alertmanager 告警詳解

監控告警

• 部署Alertmanager

• 配置Prometheus與Alertmanager通信

• 在Prometheus中建立告警規則

• 告警狀态

Alertmanager如何工作

Alertmanager處理從用戶端發來的警報，用戶端通常是Prometheus伺服器（如圖所示）。它還可以接收來自其他工具的警報。Alertmanager對警報進行去重、分組，然後路由到不同的接收器，如電子郵件、短信或SaaS服務（PagerDuty等）。

我們将在

Prometheus

伺服器上編寫警報規則

，這些規則将使用我們收集的名額并在指定的門檻值或标準上觸發警報。我們還将看到如何為警報添加一些上下文。

當名額達到門檻值或标準時，會生成一個警報并将其推送到Alertmanager

。警報在

Alertmanager

上的

HTTP

端點上接收。一個或多個

Prometheus 伺服器可以将警報定向到單個Alertmanager

，或者你可以建立一個高可用的

Alertmanager叢集。

收到警報後，

Alertmanager

會處理警報并根據其标簽進行路由。一旦路徑确定，它們将由Alertmanager發送到外部目的地，如電子郵件、短信或聊天工具。

部署Alertmanager

要實作告警通過altermanager這個元件完成的，必須告訴普羅米修斯altermanager是誰，到時候評估進階規則裡面觸發了門檻值好把告警事件推送給altermanager，然後進入其自己内部的處理邏輯，處理完之後發送到接收人。

在altermanager裡面還需要配置接收人，分組，收斂

[root@localhost system]# pwd
/usr/lib/systemd/system
[root@localhost ~]# tar xf alertmanager-0.21.0.linux-amd64.tar.gz 
[root@localhost ~]# mv alertmanager-0.21.0.linux-amd64 /usr/local/alertmanager


[root@localhost system]# systemctl daemon-reload
[root@localhost system]# systemctl start alertmanager.service
[root@localhost system]# cat alertmanager.service 
# vi /usr/lib/systemd/system/grafana.service
[Unit]
Description=alertmanager

[Service]
ExecStart=/usr/local/alertmanager/alertmanager --config.file=/usr/local/alertmanager/alertmanager.yml
ExecReload=/bin/kill -HUP $MAINPID
KillMode=process
Restart=on-failure

[Install]
WantedBy=multi-user.target

配置Prometheus與Alertmanager通信

alerting:
  alertmanagers:
  - static_configs:
    - targets:
       - 127.0.0.1:9093

配置告警規則也是在普羅米修斯這裡進行配置

alerting

塊包含允許

Prometheus

識别一個或多個

Alertmanager

的配置。為此，

Prometheus

使用與查找抓取目标時相同的發現機制，在預設配置中是static_configs

。與監控作業一樣，它指定目标清單，此處是主機名alertmanager

加端口

9093

（

Alertmanager

預設端口）的形式。該清單假定你的

Prometheus

伺服器可以解析alertmanager

主機名為

位址，并且

Alertmanager

在該主機的端口

9093

上運作。

配置Alertmanager

一個簡單的

alertmanager.yml

配置檔案

此配置檔案包含一個基本設定，用于處理警報并通過電子郵件将其發送到一個位址。讓我們依次看一下每個塊的具體内容。

第一個塊

global

包含

Alertmanager

的全局配置。這些選項為所有其他塊設定預設值，并在這些塊中作為覆寫生效。在示例中，我們隻是配置一些電子郵件和SMTP

設定：發送電子郵件的郵件伺服器、發送電子郵件的位址，并且我們禁用自動使用TLS

的要求

接下來，我們看看route塊，它會告訴Alertmanager如何處理特定的傳入警報。警報根據規則進行比對然後采取相應的操作。你可以把路由想象成有樹枝的樹，每個警報都從樹的根（基本路由或基本節點）進入（如圖所示）。除了基本節點之外，每個路由都有比對的标準，這些标準應該比對所有警報。然後，你可以定義子路由或子節點，它們是樹的分支，對某些特定的警報感興趣，或者會采取某些特定的操作。例如，來自特定叢集的所有警報可能由特定的子路由處理。

在目前的配置中，我們隻定義了基本路由，即樹的根節點。在本章後面，我們将利用路由來確定警報具有正确的容量、頻率和目的地。

我們隻定義了一個參數

receiver

。這是我們警報的預設目的地，在示例中是

電子郵件。接下來我們将定義該接收器。

最後一個塊

receivers

指定警報目的地。你可以通過電子郵件發送警報，或者發送到

PagerDuty

和 VictorOps等服務，以及

Slack

和

HipChat

等聊天工具。這裡我們隻定義了一個目的地：一個電子郵件位址。

每個接收器都有一個名稱和相關配置。這裡我們已經命名了接收器

。然後，我們為特定類型的接收器提供配置。

對于電子郵件警報，我們使用

email_configs

塊

來指定電子郵件選項，例如接收警報的位址。我們還可以指定SMTP

設定（這将覆寫全局設定），并添加其他條目（例如郵件标頭）。

修改altermanager的配置檔案

分組的概念：将類似的名額分組，比如說監控linux伺服器會監控其負載，資源負載就是一個分組，這個分組下面會有cpu的名額，記憶體的名額。

rules.yml: |
    groups:
    - name: kubernetes
      rules:
      - alert: KubernetesNodeReady
        expr: kube_node_status_condition{condition="Ready",status="true"} == 1
        for: 30s
        labels:
          severity: critical
        annotations:
          summary: Kubernetes Node ready (instance {{ $labels.instance }})
          description: "Node {{ $labels.node }} has been unready for a long time\n  VALUE = {{ $value }}\n  LABELS = {{ $labels }}"
    - name: example
      rules:
      - alert: InstanceDown
        expr: up == 0
        for: 30s
        labels:
          severity: critical
        annotations:
          summary: "{{ $labels.instance }} stop"
          description: "{{ $labels.instance }}:job{{ $labels.job }} stop"

每個告警也不是每個人都需要收到，這個時候就需要根據名額當中的不同标簽發送給不同的人，這下面加了一個routes節點，在這下面有兩塊的接收人，根據不同的标簽發給不同的項目組的人，總之就是通過标簽去比對。Altermanager根據名額當中的标簽比對發送到不同的收件人。

一個是對告警進行分組，一個routes根據标簽發送給不同的人。

route:
      group_by: [alertname]
      group_wait: 10s
      group_interval: 10s
      repeat_interval: 100m
      receiver: default

      routes:
      - receiver: email
        group_wait: 15s
        match:
          job: pushgateway

    receivers:
    - name: 'default'
      webhook_configs:
      - url: 'http://192.168.100.5:8060/dingtalk/cluster1/send'
        send_resolved: true
    - name: 'email'
      email_configs:
      - to: '[email protected]'
        send_resolved: true
~

[root@localhost ~]# cat /usr/local/alertmanager/alertmanager.yml 
global:
  resolve_timeout: 5m
  smtp_smarthost: 'smtp.163.com:25'
  smtp_from: '[email protected]'
  smtp_auth_username: '[email protected]'
  smtp_auth_password: 'xxxxxxxxxxxxxxx' 
  smtp_require_tls: false

route:
  group_by: ['alertname']
  group_wait: 10s
  group_interval: 10s
  repeat_interval: 10m
  receiver: 'mail'
receivers:
- name: 'mail'
  email_configs:
  - to: '[email protected]'
  - to: '[email protected]'

産生告警之後等待10s，同一個組還有報警，那就和其他告警一起發出去，産生告警不會立刻發出去，等待這個組内其他告警産生，然後一起發出去。

route:  #用于配置告警分發政策
      group_by: [alertname] # 采用哪個标簽來作為分組依據
      group_wait: 10s       # 組告警等待時間。也就是告警産生後等待10s，如果有同組告警一起發出
      group_interval: 10s   # 如果有不同的組，兩組告警的間隔時間
      repeat_interval: 10m    # 重複告警的間隔時間，減少相同郵件的發送頻率
      receiver: default-receiver  # 設定預設接收人

普羅米修斯啟用告警配置

這個目錄就是一個相對路徑

rule_files:
   - "rules/*.yml"

建立告警規則，這個是在分組下面建立告警規則，up為1代表正常 up為0代表不正常

隻要采集目标端up名額等于0那麼普羅米修斯評估到觸發門檻值了，然後将其發向latermanager

1m鐘之内，隻要處于處于條件為真的狀态up==0那麼就觸發

自定義标簽，也就是自定義，讓你收到告警的時候對标簽更加清晰，附加資訊說明告警

[root@localhost ~]# mkdir -p /usr/local/prometheus/rules

[root@localhost ~]# cat /usr/local/prometheus/rules/node.yml 
groups:
- name: example 
  rules:
  - alert: InstanceDown 
    expr: up == 0 # 基于PromQL的觸發條件
    for: 1m # 等待評估時間
    labels: # 自定義标簽
      severity: page
    annotations: # 指定附加資訊
      summary: " {{ $labels.instance }} 停止工作"
      description: "{{ $labels.instance }}:job{{ $labels.job }} 已經停止5分鐘以上."

這裡可以寫多個分組，如果還要分組- name

隻要采集的名額當中有的名額都可以在告警描述當中引用

每個被監控端都有up這個标簽，up為1代表服務正常，如果等于0代表服務不正常。是以可以通過up擷取所有的被監控端狀态

檢視告警規則是否生效

告警狀态

• Inactive：這裡什麼都沒有發生。

• Pending：已觸發門檻值，但未滿足告警持續時間，也就是for字段

• Firing：已觸發門檻值且滿足告警持續時間。警報發送給接受者。

被監控端一個主機down了，檢視告警，可以看到告警處于pending的狀态，進入for循環評估當中

在評估期内滿足條件告警狀态觸發了，此時狀态為Firing

這裡可以在告警規則裡面定義一些标簽，方面後期的處理，主要是在altermanager裡面展現

最後郵箱檢視，記住，同一個組下面的多個告警觸發，在發送的時候會合并為一封郵件！

最後一點我想說的是， repeat_interval: 10m # 重複告警間隔發送時間，可以看到相同的告警再次觸發需要間隔十分鐘，建議配置為1m鐘

Kubernetes Node ready

Node {{ $labels.node }} has been unready for a long time

- alert: KubernetesNodeReady
    expr: kube_node_status_condition{condition="Ready",status="true"} == 0
    for: 10m
    labels:
      severity: critical
    annotations:
      summary: Kubernetes Node ready (instance {{ $labels.instance }})
      description: "Node {{ $labels.node }} has been unready for a long time\n  VALUE = {{ $value }}\n  LABELS = {{ $labels }}"

Prometheus一條告警怎麼觸發的？

Prometheus scrape_interval: 15s：采集的時間間隔是15s，也就是預設每隔15s采集一次名額，也就是有一個執行個體宕掉了，正好前一秒剛好采集完，那麼還要等15s才能采集到這個名額，普羅米修斯才能感覺到。

Prometheus evaluation_interval: 1m：告警評估周期，也就是每隔多長時間對采集的名額做個評估

Alertmanager 告警詳解

監控告警

Alertmanager如何工作

部署Alertmanager

配置Prometheus與Alertmanager通信

配置Alertmanager

修改altermanager的配置檔案

普羅米修斯啟用告警配置

告警狀态

Prometheus一條告警怎麼觸發的？

繼續閱讀

解決"T-SQL無法附加到程序"錯誤的補充,T-SQLcan not attach to process

【網絡篇】第五篇——網絡套接字程式設計(一)(socket詳解)socket程式設計LINUX下socket程式的示範

網絡空間安全中高職業院校職技能大賽——Telnet弱密碼滲透測試

門戶通專訪月光部落格：第一部落格是如何打造成的

解讀2008年網絡技術熱詞之雲計算

磁盤結構及在Linux中的命名

寶塔java項目部署日志路徑

Centos 7 Apache配置虛拟主機

Ubunto 安裝Apache2以後 httpd.conf檔案找不到問題

Apache httpd 安裝啟動demo（Window版）

Apache配置檔案中的deny和allow的使用

debian9更新4.9.0核心到4.19.2核心過程

配置網頁内容通路

艱難安裝LDAP,SSL認證

Apache配置SSLApache配置SSL

Windows下配置Apache的SSL服務