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']
設置告警和通知的主要步驟以下：
- 部署Alertmanager
- 配置Prometheus與Alertmanager通訊
- 在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小時或以上
主要處理流程：
- 接收到Alert，根據labels判斷屬於哪些Route（可存在多個Route，一個Route有多個Group，一個Group有多個Alert）。
- 將Alert分配到Group中，沒有則新建Group。
- 新的Group等待group_wait指定的時間（等待時可能收到同一Group的Alert），根據resolve_timeout判斷Alert是否解決，而後發送通知。
- 已有的Group等待group_interval指定的時間，判斷Alert是否解決，當上次發送通知到如今的間隔大於repeat_interval或者Group有更新時會發送通知。
四、告警收斂（分組、抑制、靜默）
告警面臨最大問題，是警報太多，至關於狼來了的形式。收件人很容易麻木，再也不繼續理會。關鍵的告警經常被淹沒。在一問題中，alertmanger在必定程度上獲得很好解決。
Prometheus成功的把一條告警發給了Altermanager，而Altermanager並非簡簡單單的直接發送出去，這樣就會致使告警信息過多，重要告警被淹沒。因此須要對告警作合理的收斂。
告警收斂手段：
分組（group）：將相似性質的警報分類爲單個通知
抑制（Inhibition）：當警報發出後，中止重複發送由此警報引起的其餘警報
靜默（Silences）：是一種簡單的特定時間靜音提醒的機制
五、Prometheus一條告警怎麼觸發的？
報警處理流程以下：
- Prometheus Server監控目標主機上暴露的http接口（這裏假設接口A），經過上述Promethes配置的'scrape_interval'定義的時間間隔，按期採集目標主機上監控數據。
- 當接口A不可用的時候，Server端會持續的嘗試從接口中取數據，直到"scrape_timeout"時間後中止嘗試。這時候把接口的狀態變爲「DOWN」。
- Prometheus同時根據配置的"evaluation_interval"的時間間隔，按期（默認1min）的對Alert Rule進行評估；當到達評估週期的時候，發現接口A爲DOWN，即UP=0爲真，激活Alert，進入「PENDING」狀態，並記錄當前active的時間；
- 當下一個alert rule的評估週期到來的時候，發現UP=0繼續爲真，而後判斷警報Active的時間是否已經超出rule裏的‘for’ 持續時間，若是未超出，則進入下一個評估週期；若是時間超出，則alert的狀態變爲「FIRING」；同時調用Alertmanager接口，發送相關報警數據。
- AlertManager收到報警數據後，會將警報信息進行分組，而後根據alertmanager配置的「group_wait」時間先進行等待。等wait時間事後再發送報警信息。
- 屬於同一個Alert Group的警報，在等待的過程當中可能進入新的alert，若是以前的報警已經成功發出，那麼間隔「group_interval」的時間間隔後再從新發送報警信息。好比配置的是郵件報警，那麼同屬一個group的報警信息會彙總在一個郵件裏進行發送。
- 若是Alert Group裏的警報一直沒發生變化而且已經成功發送，等待‘repeat_interval’時間間隔以後再重複發送相同的報警郵件；若是以前的警報沒有成功發送，則至關於觸發第6條條件，則須要等待group_interval時間間隔後重復發送。
- 同時最後至於警報信息具體發給誰，知足什麼樣的條件下指定警報接收人，設置不一樣報警發送頻率，這裏有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配置從新加載失敗"
- 1. Prometheus 初體驗
- 2. Prometheus Operator 初體驗
- 3. Flink初體驗
- 4. Tensorflow初體驗
- 5. MVVM初體驗
- 6. LevelDB初體驗
- 7. 19JDBC初體驗
- 8. puppeteer初體驗
- 9. Quartz初體驗
- 10. Manjaro初體驗
- 更多相關文章...
- • Rust 結構體 - RUST 教程
- • DTD - 實體 - DTD 教程
- • 適用於PHP初學者的學習線路和建議
- • RxJava操作符（三）Filtering
-
每一个你不满意的现在，都有一个你没有努力的曾经。
- 1. vs2019運行opencv圖片顯示代碼時，窗口亂碼
- 2. app自動化 - 元素定位不到？別慌，看完你就能解決
- 3. 在Win8下用cisco ××× Client連接時報Reason 422錯誤的解決方法
- 4. eclipse快速補全代碼
- 5. Eclipse中Java/Html/Css/Jsp/JavaScript等代碼的格式化
- 6. idea+spring boot +mabitys(wanglezapin)+mysql (1)
- 7. 勒索病毒發生變種 新文件名將帶有「.UIWIX」後綴
- 8. 【原創】Python 源文件編碼解讀
- 9. iOS9企業部署分發問題深入瞭解與解決
- 10. 安裝pytorch報錯CondaHTTPError：******
- 1. Prometheus 初體驗
- 2. Prometheus Operator 初體驗
- 3. Flink初體驗
- 4. Tensorflow初體驗
- 5. MVVM初體驗
- 6. LevelDB初體驗
- 7. 19JDBC初體驗
- 8. puppeteer初體驗
- 9. Quartz初體驗
- 10. Manjaro初體驗