Prometheus初體驗（三）

時間  2019-11-21
標籤 prometheus 體驗 简体版
原文   原文鏈接

1、安裝部署

Prometheus基於Golang編寫，編譯後的軟件包，不依賴於任何的第三方依賴。用戶只須要下載對應平臺的二進制包，解壓而且添加基本的配置便可正常啓動Prometheus Server。html

二進制部署

一、下載安裝包node

爲您的平臺下載最新版本的Prometheus，而後解壓縮並運行它：mysql

https://prometheus.io/download/git

https://prometheus.io/docs/prometheus/latest/getting_started/github

tar xvfz prometheus-*.tar.gz
cd prometheus-*
mv prometheus-* /usr/local/prometheus

二、註冊爲服務

Centos7上，註冊爲服務：web

cat  /usr/lib/systemd/system/prometheus.service sql

 [Unit]
Description=https://prometheus.io

[Service]
Restart=on-failure
ExecStart=/usr/local/prometheus/prometheus --config.file=/usr/local/prometheus/prometheus.yml

[Install]
WantedBy=multi-user.target

　　

Centos6上，註冊爲服務：docker

#!/bin/bash
#
# Comments to support chkconfig
# chkconfig: 2345 98 02
# description: prometheus service script
#
# Source function library.
. /etc/init.d/functions
 
### Default variables
prog_name="prometheus"
config_file="/usr/local/${prog_name}/${prog_name}.yml"
prog_path="/usr/local/${prog_name}/${prog_name}"
data_path="/usr/local/${prog_name}/data"
pidfile="/var/run/${prog_name}.pid"
prog_logs="/var/log/${prog_name}.log"
#啓動項，監聽本地9090端口，支持配置熱加載
options="--web.listen-address=0.0.0.0:9090 --config.file=${config_file}  --storage.tsdb.path=${data_path}"
DESC="Prometheus Server"

# Check if requirements are met
[ -x "${prog_path}" ] || exit 1
 
RETVAL=0
 
start(){
  action $"Starting $DESC..." su -s /bin/sh -c "nohup $prog_path $options >> $prog_logs 2>&1 &" 2> /dev/null
  RETVAL=$?
  PID=$(pidof ${prog_path})
  [ ! -z "${PID}" ] && echo ${PID} > ${pidfile}
  echo
  [ $RETVAL -eq 0 ] && touch /var/lock/subsys/$prog_name
  return $RETVAL
}
 
stop(){
  echo -n $"Shutting down $prog_name: "
  killproc -p ${pidfile}
  RETVAL=$?
  echo
  [ $RETVAL -eq 0 ] && rm -f /var/lock/subsys/$prog_name
  return $RETVAL
}
 
restart() {
  stop
  start
}
 
case "$1" in
  start)
    start
    ;;
  stop)
    stop
    ;;
  restart)
    restart
    ;;
  status)
    status $prog_path
    RETVAL=$?
    ;;
  *)
    echo $"Usage: $0 {start|stop|restart|status}"
    RETVAL=1
esac
 
exit $RETVAL

　　

三、啓動promethues

Centos7：數據庫

systemctl start prometheusapi

 

Centos6:

service prometheus start 

 

Docker方式部署

https://prometheus.io/docs/prometheus/latest/installation/

prometheus.yml經過運行如下命令將您從主機綁定：

docker run -p 9090:9090 -v /tmp/prometheus.yml:/etc/prometheus/prometheus.yml \
       prom/prometheus

　　

或者爲配置使用額外的卷：

docker run -p 9090:9090 -v /prometheus-data \
       prom/prometheus --config.file=/prometheus-data/prometheus.yml

　　

2、界面訪問

http://localhost:9090訪問本身的狀態頁面

能夠經過訪問localhost:9090驗證Prometheus自身的指標：localhost:9090/metrics

 

 

3、自我監控

Prometheus從目標機上經過http方式拉取採樣點數據, 它也能夠拉取自身服務數據並監控自身的健康情況

固然Prometheus服務拉取自身服務採樣數據，並無多大的用處，可是它是一個好的DEMO。保存下面的Prometheus配置，並命名爲：prometheus.yml:

global:
  scrape_interval:     15s # 默認狀況下，每15s拉取一次目標採樣點數據。

  # 咱們能夠附加一些指定標籤到採樣點度量標籤列表中, 用於和第三方系統進行通訊, 包括：federation, remote storage, Alertmanager
  external_labels:
    monitor: 'codelab-monitor'

# 下面就是拉取自身服務採樣點數據配置
scrape_configs:
  # job名稱會增長到拉取到的全部採樣點上，同時還有一個instance目標服務的host：port標籤也會增長到採樣點上
  - job_name: 'prometheus'

    # 覆蓋global的採樣點，拉取時間間隔5s
    scrape_interval: 5s

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

　　重啓promethues服務。

經過http://10.11.100.99:9090/targets，就能夠查看到了：

 

4、配置文件

配置文件的格式是YAML，使用--config.file指定配置文件的位置。本節列出重要的配置項。

一、全局配置文件

有關配置選項的完整，請參閱：https://prometheus.io/docs/prometheus/latest/configuration/configuration/

Prometheus以scrape_interval規則週期性從監控目標上收集數據，而後將數據存儲到本地存儲上。scrape_interval能夠設定全局也能夠設定單個metrics。

Prometheus以evaluation_interval規則週期性對告警規則作計算，而後更新告警狀態。evaluation_interval只有設定在全局。

 

global：全局配置

alerting：告警配置

rule_files：告警規則

scrape_configs：配置數據源，稱爲target，每一個target用job_name命名。又分爲靜態配置和服務發現

global:
  # 默認抓取週期，設置每15s採集數據一次，默認1分鐘
  [ scrape_interval: <duration> | default = 1m ]
  # 默認抓取超時
  [ scrape_timeout: <duration> | default = 10s ]
  # 估算規則的默認週期 # 每15秒計算一次規則。默認1分鐘
  [ evaluation_interval: <duration> | default = 1m ]
  # 和外部系統（例如AlertManager）通訊時爲時間序列或者警情（Alert）強制添加的標籤列表
  external_labels:
    [ <labelname>: <labelvalue> ... ]
 
# 規則文件列表
rule_files:
  [ - <filepath_glob> ... ]
 
# 抓取配置列表
scrape_configs:
  [ - <scrape_config> ... ]
 
# Alertmanager相關配置
alerting:
  alert_relabel_configs:
    [ - <relabel_config> ... ]
  alertmanagers:
    [ - <alertmanager_config> ... ]
 
# 遠程讀寫特性相關的配置
remote_write:
  [ - <remote_write> ... ]
remote_read:
  [ - <remote_read> ... ]

　　其中，比較重要的配置爲scrape_configs.

二、scrape_configs

根據配置的任務（job）以http/s週期性的收刮（scrape/pull）

指定目標（target）上的指標（metric）。目標（target）

能夠以靜態方式或者自動發現方式指定。Prometheus將收刮（scrape）的指標（metric）保存在本地或者遠程存儲上。

 

使用scrape_configs定義採集目標

配置一系列的目標，以及如何抓取它們的參數。通常狀況下，每一個scrape_config對應單個Job。

目標能夠在scrape_config中靜態的配置，也可使用某種服務發現機制動態發現。

# 任務名稱，自動做爲抓取到的指標的一個標籤
job_name: <job_name>
 
# 抓取週期
[ scrape_interval: <duration> | default = <global_config.scrape_interval> ]
# 每次抓取的超時
[ scrape_timeout: <duration> | default = <global_config.scrape_timeout> ]
# 從目標抓取指標的URL路徑
[ metrics_path: <path> | default = /metrics ]
# 當添加標籤發現指標已經有同名標籤時，是否保留原有標籤不覆蓋
[ honor_labels: <boolean> | default = false ]
# 抓取協議
[ scheme: <scheme> | default = http ]
# HTTP請求參數
params:
  [ <string>: [<string>, ...] ]
 
# 身份驗證信息
basic_auth:
  [ username: <string> ]
  [ password: <secret> ]
  [ password_file: <string> ]
# Authorization請求頭取值
[ bearer_token: <secret> ]
# 從文件讀取Authorization請求頭
[ bearer_token_file: /path/to/bearer/token/file ]
 
# TLS配置
tls_config:
  [ <tls_config> ]
 
# 代理配置
[ proxy_url: <string> ]
 
# DNS服務發現配置
dns_sd_configs:
  [ - <dns_sd_config> ... ]
# 文件服務發現配置
file_sd_configs:
  [ - <file_sd_config> ... ]
# K8S服務發現配置
kubernetes_sd_configs:
  [ - <kubernetes_sd_config> ... ]
 
# 此Job的靜態配置的目標列表，用的最多的配置！！！
static_configs:
  [ - <static_config> ... ]
 
# 目標重打標籤配置
relabel_configs:
  [ - <relabel_config> ... ]
# 指標重打標籤配置
metric_relabel_configs:
  [ - <relabel_config> ... ]
 
# 每次抓取容許的最大樣本數量，若是在指標重打標籤後，樣本數量仍然超過限制，則整個抓取認爲失敗
# 0表示不限制
[ sample_limit: <int> | default = 0

　　

三、relabel_configs

relabel_configs ：容許在採集以前對任何目標及其標籤進行修改

從新標籤的意義？

  • 重命名標籤名
  • 刪除標籤
  • 過濾目標

 

action：從新標籤動做

  • replace：默認，經過regex匹配source_label的值，使用replacement來引用表達式匹配的分組
  • keep：刪除regex與鏈接不匹配的目標 source_labels
  • drop：刪除regex與鏈接匹配的目標 source_labels
  • labeldrop：刪除regex匹配的標籤
  • labelkeep：刪除regex不匹配的標籤
  • hashmod：設置target_label爲modulus鏈接的哈希值source_labels
  • labelmap：匹配regex全部標籤名稱。而後複製匹配標籤的值進行分組，replacement分組引用（${1},${2},…）替代

 

四、基於文件的服務發現

支持服務發現的來源：

  • azure_sd_configs
  • consul_sd_configs
  • dns_sd_configs
  • ec2_sd_configs
  • openstack_sd_configs
  • file_sd_configs
  • gce_sd_configs
  • kubernetes_sd_configs
  • marathon_sd_configs
  • nerve_sd_configs
  • serverset_sd_configs
  • triton_sd_configs

 

Prometheus也提供了服務發現功能，能夠從consul，dns，kubernetes，file等等多種來源發現新的目標。

其中最簡單的是從文件發現服務。

https://github.com/prometheus/prometheus/tree/master/discovery

服務發現支持： endpoints，ingress，kubernetes，node，pod，service

 

5、監控案例

監控Linux服務器

node_exporter：用於*NIX系統監控，使用Go語言編寫的收集器。

使用文檔：https://prometheus.io/docs/guides/node-exporter/

GitHub：https://github.com/prometheus/node_exporter

exporter列表：https://prometheus.io/docs/instrumenting/exporters/

 

收集到 node_exporter 的數據後，咱們可使用 PromQL 進行一些業務查詢和監控，下面是一些比較常見的查詢。

注意：如下查詢均以單個節點做爲例子，若是你們想查看全部節點，將 instance="xxx" 去掉便可。

CPU使用率：
100 - (avg(irate(node_cpu_seconds_total{mode="idle"}[5m])) by (instance) * 100)
內存使用率：
100 - (node_memory_MemFree_bytes+node_memory_Cached_bytes+node_memory_Buffers_bytes) / node_memory_MemTotal_bytes * 100
磁盤使用率：
100 - (node_filesystem_free_bytes{mountpoint="/",fstype=~"ext4|xfs"} / node_filesystem_size_bytes{mountpoint="/",fstype=~"ext4|xfs"} * 100)

　　

監控Mysql數據庫

mysql_exporter：用於收集MySQL性能信息。

 

https://github.com/prometheus/mysqld_exporter

https://grafana.com/dashboards/7362

登陸mysql爲exporter建立帳號：
mysql> CREATE USER 'exporter'@'localhost' IDENTIFIED BY 'XXXXXXXX' WITH MAX_USER_CONNECTIONS 3;
mysql> GRANT PROCESS, REPLICATION CLIENT, SELECT ON *.* TO 'exporter'@'localhost';

# cat .my.cnf 
[client]
user=exporter
password=exporter123

# ./mysqld_exporter --config.my-cnf=.my.cnf
- job_name: 'mysql'
    static_configs:
      - targets: ['localhost:9104']

6、可視化方案

Grafana是一個開源的最近很是流行的度量分析和可視化工具。

https://grafana.com/grafana/download

Grafana支持查詢普羅米修斯。自Grafana 2.5.0（2015-10-28）以來，包含了Prometheus的Grafana數據源。

 

Grafana.com維護着一組共享儀表板 ，能夠下載並與Grafana的獨立實例一塊兒使用。

好比

https://grafana.com/dashboards/9276

 

7、監控告警

告警無疑是監控中很是重要的環節，雖然監控數據可視化了，也很是容易觀察到運行狀態。但咱們很難作到時刻盯着監控，因此程序來幫巡檢並自動告警，這個程序是幕後英雄，保障業務穩定性就靠它了。

前面講到過Prometheus的報警功能主要是利用Alertmanager這個組件。當Alertmanager接收到 Prometheus 端發送過來的 Alerts 時，Alertmanager 會對 Alerts 進行去重複，分組，按標籤內容發送不一樣報警組，包括：郵件，微信，webhook。

使用prometheus進行告警分爲兩部分：Prometheus Server中的告警規則會向Alertmanager發送。而後，Alertmanager管理這些告警，包括進行重複數據刪除，分組和路由，以及告警的靜默和抑制。

 

一、部署Alertmanager

在Prometheus平臺中，警報由獨立的組件Alertmanager處理。一般狀況下，咱們首先告訴Prometheus Alertmanager所在的位置，而後在Prometheus配置中建立警報規則，最後配置Alertmanager來處理警報併發送給接收者（郵件，webhook、slack等）。

 

地址1：https://prometheus.io/download/

地址2：https://github.com/prometheus/alertmanager/releases

 

註冊爲服務

 

#!/bin/bash
#
# Comments to support chkconfig
# chkconfig: 2345 98 02
# description: prometheus service script
#
# Source function library.
. /etc/init.d/functions
 
### Default variables
base_name="alertmanager"
prog_name="alertmanager"
config_file="/usr/local/${base_name}/${prog_name}.yml"
prog_path="/usr/local/${base_name}/${prog_name}"
data_path="/usr/local/${base_name}/data"
pidfile="/var/run/${porg_name}.pid"
prog_logs="/var/log/${prog_name}.log"
#啓動項，監聽本地9090端口，支持配置熱加載
options="--config.file=${config_file}"
DESC="altermanager"

# Check if requirements are met
[ -x "${prog_path}" ] || exit 1
 
RETVAL=0
 
start(){
  action $"Starting $DESC..." su -s /bin/sh -c "nohup $prog_path $options>> $prog_logs 2>&1 &" 2> /dev/null
  RETVAL=$?
  PID=$(pidof ${prog_path})
  [ ! -z "${PID}" ] && echo ${PID} > ${pidfile}
  echo
  [ $RETVAL -eq 0 ] && touch /var/lock/subsys/$prog_name
  return $RETVAL
}
 
stop(){
  echo -n $"Shutting down $prog_name: "
  killproc -p ${pidfile}
  RETVAL=$?
  echo
  [ $RETVAL -eq 0 ] && rm -f /var/lock/subsys/$prog_name
  return $RETVAL
}
 
restart() {
  stop
  start
}
 
case "$1" in
  start)
    start
    ;;
  stop)
    stop
    ;;
  restart)
    restart
    ;;
  status)
    status $prog_path
    RETVAL=$?
    ;;
  *)
    echo $"Usage: $0 {start|stop|restart|status}"
    RETVAL=1
esac
 
exit $RETVAL

 

　　

啓動Alertmanager

service alertmanager start

 

二、配置alertmanager

 一個完整的alertmanager.yml以下：

# 全局配置項
global: 
  resolve_timeout: 5m #處理超時時間，默認爲5min
  smtp_smarthost: 'smtp.sina.com:25' # 郵箱smtp服務器代理
  smtp_from: '******@sina.com' # 發送郵箱名稱
  smtp_auth_username: '******@sina.com' # 郵箱名稱
  smtp_auth_password: '******' # 郵箱密碼或受權碼
  wechat_api_url: 'https://qyapi.weixin.qq.com/cgi-bin/' # 企業微信地址


# 定義模板信心
templates:
  - 'template/*.tmpl'

# 定義路由樹信息
route:
  group_by: ['alertname'] # 報警分組依據
  group_wait: 10s # 最初即第一次等待多久時間發送一組警報的通知
  group_interval: 10s # 在發送新警報前的等待時間
  repeat_interval: 1m # 發送重複警報的週期 對於email配置中，此項不能夠設置太低，不然將會因爲郵件發送太多頻繁，被smtp服務器拒絕
  receiver: 'email' # 發送警報的接收者的名稱，如下receivers name的名稱

# 定義警報接收者信息
receivers:
  - name: 'email' # 警報
    email_configs: # 郵箱配置
    - to: '******@163.com'  # 接收警報的email配置
      html: '{{ template "test.html" . }}' # 設定郵箱的內容模板
      headers: { Subject: "[WARN] 報警郵件"} # 接收郵件的標題
    webhook_configs: # webhook配置
    - url: 'http://127.0.0.1:5001'
    send_resolved: true
    wechat_configs: # 企業微信報警配置
    - send_resolved: true
      to_party: '1' # 接收組的id
      agent_id: '1000002' # (企業微信-->自定應用-->AgentId)
      corp_id: '******' # 企業信息(個人企業-->CorpId[在底部])
      api_secret: '******' # 企業微信(企業微信-->自定應用-->Secret)
      message: '{{ template "test_wechat.html" . }}' # 發送消息模板的設定
# 一個inhibition規則是在與另外一組匹配器匹配的警報存在的條件下，使匹配一組匹配器的警報失效的規則。兩個警報必須具備一組相同的標籤。 
inhibit_rules: 
  - source_match: 
     severity: 'critical' 
    target_match: 
     severity: 'warning' 
    equal: ['alertname', 'dev', 'instance']

　　

設置告警和通知的主要步驟以下：

  1. 部署Alertmanager
  2. 配置Prometheus與Alertmanager通訊
  3. 在Prometheus中建立告警規則

a、配置Prometheus與Alertmanager通訊

# vi prometheus.yml
alerting:
  alertmanagers:
  - static_configs:
    - targets:
       - 127.0.0.1:9093

　　

b、在Prometheus中建立告警規則

# vi prometheus.yml
rule_files:
   - "rules/*.yml"

# vi rules/node.yml
groups:
- name: example   # 報警規則組名稱
  rules:
  # 任何實例5分鐘內沒法訪問發出告警
  - alert: InstanceDown
    expr: up == 0
    for: 5m  #持續時間 ， 表示持續一分鐘獲取不到信息，則觸發報警
    labels:
      severity: page  # 自定義標籤
    annotations:
      summary: "Instance {{ $labels.instance }} down" # 自定義摘要
      description: "{{ $labels.instance }} of job {{ $labels.job }} has been down for more than 5 minutes." # 自定義具體描述

　　

c、觸發告警

d、告警狀態

一旦這些警報存儲在Alertmanager，它們可能處於如下任何狀態：

  • Inactive：這裏什麼都沒有發生。
  • Pending：已觸發閾值，但未知足告警持續時間（即rule中的for字段）
  • Firing：已觸發閾值且知足告警持續時間。警報發送到Notification Pipeline，通過處理，發送給接受者。

 

這樣目的是屢次判斷失敗才發告警，減小郵件。

三、告警分配

route屬性用來設置報警的分發策略，它是一個樹狀結構，按照深度優先從左向右的順序進行匹配。

route:
  receiver: 'default-receiver'  
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
  group_by: [cluster, alertname]
# 全部不匹配如下子路由的告警都將保留在根節點，併發送到「default-receiver」
  routes:
# 全部service=mysql或者service=cassandra的告警分配到數據庫接收端
  - receiver: 'database-pager'
    group_wait: 10s
    match_re:
      service: mysql|cassandra
# 全部帶有team=frontend標籤的告警都與此子路由匹配
# 它們是按產品和環境分組的，而不是集羣
  - receiver: 'frontend-pager'
    group_by: [product, environment]
    match:
      team: frontend

　　

group_by：報警分組依據

group_wait：爲一個組發送通知的初始等待時間，默認30s

group_interval：在發送新告警前的等待時間。一般5m或以上

repeat_interval：發送重複告警的週期。若是已經發送了通知，再次發送以前須要等待多長時間。一般3小時或以上

主要處理流程：

  1. 接收到Alert，根據labels判斷屬於哪些Route（可存在多個Route，一個Route有多個Group，一個Group有多個Alert）。
  2. 將Alert分配到Group中，沒有則新建Group。
  3. 新的Group等待group_wait指定的時間（等待時可能收到同一Group的Alert），根據resolve_timeout判斷Alert是否解決，而後發送通知。
  4. 已有的Group等待group_interval指定的時間，判斷Alert是否解決，當上次發送通知到如今的間隔大於repeat_interval或者Group有更新時會發送通知。

 

四、告警收斂（分組、抑制、靜默）

告警面臨最大問題，是警報太多，至關於狼來了的形式。收件人很容易麻木，再也不繼續理會。關鍵的告警經常被淹沒。在一問題中，alertmanger在必定程度上獲得很好解決。

 

Prometheus成功的把一條告警發給了Altermanager，而Altermanager並非簡簡單單的直接發送出去，這樣就會致使告警信息過多，重要告警被淹沒。因此須要對告警作合理的收斂。

 

告警收斂手段：

分組（group）：將相似性質的警報分類爲單個通知

抑制（Inhibition）：當警報發出後，中止重複發送由此警報引起的其餘警報

靜默（Silences）：是一種簡單的特定時間靜音提醒的機制

 

五、Prometheus一條告警怎麼觸發的？

 

報警處理流程以下：

  1. Prometheus Server監控目標主機上暴露的http接口（這裏假設接口A），經過上述Promethes配置的'scrape_interval'定義的時間間隔，按期採集目標主機上監控數據。
  2. 當接口A不可用的時候，Server端會持續的嘗試從接口中取數據，直到"scrape_timeout"時間後中止嘗試。這時候把接口的狀態變爲「DOWN」。
  3. Prometheus同時根據配置的"evaluation_interval"的時間間隔，按期（默認1min）的對Alert Rule進行評估；當到達評估週期的時候，發現接口A爲DOWN，即UP=0爲真，激活Alert，進入「PENDING」狀態，並記錄當前active的時間；
  4. 當下一個alert rule的評估週期到來的時候，發現UP=0繼續爲真，而後判斷警報Active的時間是否已經超出rule裏的‘for’ 持續時間，若是未超出，則進入下一個評估週期；若是時間超出，則alert的狀態變爲「FIRING」；同時調用Alertmanager接口，發送相關報警數據。
  5. AlertManager收到報警數據後，會將警報信息進行分組，而後根據alertmanager配置的「group_wait」時間先進行等待。等wait時間事後再發送報警信息。
  6. 屬於同一個Alert Group的警報，在等待的過程當中可能進入新的alert，若是以前的報警已經成功發出，那麼間隔「group_interval」的時間間隔後再從新發送報警信息。好比配置的是郵件報警，那麼同屬一個group的報警信息會彙總在一個郵件裏進行發送。
  7. 若是Alert Group裏的警報一直沒發生變化而且已經成功發送，等待‘repeat_interval’時間間隔以後再重複發送相同的報警郵件；若是以前的警報沒有成功發送，則至關於觸發第6條條件，則須要等待group_interval時間間隔後重復發送。
  8. 同時最後至於警報信息具體發給誰，知足什麼樣的條件下指定警報接收人，設置不一樣報警發送頻率，這裏有alertmanager的route路由規則進行配置。

六、編寫告警規則案例

# cat rules/general.yml 
groups:
- name: general.rules
  rules:
  - alert: InstanceDown
    expr: up == 0
    for: 2m
    labels:
      severity: error
    annotations:
      summary: "Instance {{ $labels.instance }} 中止工做"
      description: "{{ $labels.instance }}: job {{ $labels.job }} 已經中止5分鐘以上."


# cat rules/node.yml
groups:
- name: node.rules
  rules:
  - alert: NodeFilesystemUsage
    expr: 100 - (node_filesystem_free_bytes{fstype=~"ext4|xfs"} / node_filesystem_size_bytes{fstype=~"ext4|xfs"} * 100) > 80
    for: 2m
    labels:
      severity: warning
    annotations:
      summary: "{{$labels.instance}}: {{$labels.mountpoint }} 分區使用太高"
      description: "{{$labels.instance}}: {{$labels.mountpoint }} 分區使用大於 80% (當前值: {{ $value }})"
  - alert: NodeMemoryUsage
    expr: 100 - (node_memory_MemFree_bytes+node_memory_Cached_bytes+node_memory_Buffers_bytes) / node_memory_MemTotal_bytes * 100 > 80
    for: 2m
    labels:
      severity: warning
    annotations:
      summary: "{{$labels.instance}}: 內存使用太高"
      description: "{{$labels.instance}}: 內存使用大於 80% (當前值: {{ $value }})"
  - alert: NodeCPUUsage
    expr: 100 - (avg(irate(node_cpu_seconds_total{mode="idle"}[5m])) by (instance) * 100) > 80
    for: 2m
    labels:
      severity: warning
    annotations:
      summary: "{{$labels.instance}}: CPU使用太高"
      description: "{{$labels.instance}}: CPU使用大於 80% (當前值: {{ $value }})"

# cat rules/reload.yml 
groups:
- name: prometheus.rules
  rules:
  - alert: AlertmanagerReloadFailed
    expr: alertmanager_config_last_reload_successful == 0
    for: 10m
    labels:
      severity: warning
    annotations:
      summary: "{{$labels.instance}}: Alertmanager配置從新加載失敗"
      description: "{{$labels.instance}}: Alertmanager配置從新加載失敗"
  - alert: PrometheusReloadFailed
    expr: prometheus_config_last_reload_successful == 0
    for: 10m
    labels:
      severity: warning
    annotations:
      summary: "{{$labels.instance}}: Prometheus配置從新加載失敗"
      description: "{{$labels.instance}}: Prometheus配置從新加載失敗"
相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程