目錄
1. prometheus
2. 告警狀態
3. 告警規則for 即持續時間
4. 例子
5. alertmanager
告警評估時間週期: evaluation_interval 預設1m
metrics收集週期: scrape_interval 預設1m
inactive 既不觸發告警也不是掛起狀態
pending 已經處於啟用狀態，但是啟用時間小於配置的閾值持續時間
firing 已經處於啟用狀態並且啟用時間超過閾值持續時間
沒有設定for，達到滿足告警閾值的時候則是立即觸發firing；
有設定for，經歷evaluation_interval間隔後由inactive轉換成pending，再經歷evaluation_interval間隔後由pending轉換成firing， 因此至少需要2倍的evaluation_interval ，告警才會觸發
以節點的負載大於20為例，相關配置如下
prometheus
scrape_interval : 20s
evaluation_interval: 1m
告警規則
alert node_load_1m
if load > 100
for 1m
a: 花費時間在1m ~ 20s+1m+1m之間。
1. prometheus每20s收集一次
2. 設定的告警規則，prometheus每1m評估一次
3. 當告警表示式滿足告警觸發條件時(load > 20)，由於設定了for:1m, 告警狀態由inactive轉pending
4. 在下一輪的evaluation_interval, 如果表示式依舊滿足(load > 20)，由於設定了for:1m， 此時告警狀態由pending轉firing，此時告警由推送到alertmanager
group_by: [ 'a-label', 'another-label' ]
group_wait: 30s 當乙個新的告警觸發時，這個告警要等待group_wait的時間直到排程通知。alertmanager會快取改通知達30s。
group_interval: 5m 當下一輪的evaluation_interval觸發了相同組內的其他告警，此時就不會再等待group_wait時間，而是等待group_interval， group_interval從上次傳送通知的時間開始計算。
alertmanager郵件告警
alertmanager郵件告警 這篇文章是基於之前部落格進行開展的 關於計畫任務的乙個小需求 利用了prometheus 下 process exporter對crond計畫任務程序監控的，grafana內建的監控報警有點醜，如下圖 而且配置不夠靈活，沒有分組，靜默等東西配置。所以就有了這個ale...
Alertmanager告警規則編寫案例（十二）
首先要將一些類似的監控項規劃到乙個分組，在定義表示式 告警級別 告警詳細內容，在告警詳細內容中一定要熟練使用監控項自身的標籤，這樣就可以在告警內容中讓管理員一眼知道什麼觸發了告警 expr指定表示式，在使用邏輯符號匹配閾值 告警內容中要熟練運用各種標籤，標籤都是監控項中自帶的，value標籤就是當前...
Alertmanager配置檔案詳解
重點 apiversion v1 kind configmap metadata name alert config namespace kube ops data config.yml global 在沒有報警的情況下宣告為已解決的時間 resolve timeout 5m 配置郵件傳送資訊 sm...