prometheus告警問題的示例分析

本篇文章為大家展示了prometheus告警問題的示例分析，內容簡明扼要并且容易理解，絕對能使你眼前一亮，通過這篇文章的詳細介紹希望你能有所收獲。

問題分析

最近運維prometheus的過程中發現，有的時候它應該發送告警，可實際卻沒有;有的時候，不該發送告警卻發送了;還有的時候，告警出現明顯的延遲。為了找出其中的具體原因，特地去查閱了一些資料，同時也參考了官網的相關資料。希望對大家在今后使用prometheus有所幫助。

先來看一下官網提供的prometheus和alertmanager的一些默認的重要配置。如下所示：

# promtheus global:   # How frequently to scrape targets by default. 從目標抓取監控數據的間隔   [ scrape_interval: <duration> | default = 1m ]   # How long until a scrape request times out. 從目標住區數據的超時時間   [ scrape_timeout: <duration> | default = 10s ]   # How frequently to evaluate rules. 告警規則評估的時間間隔   [ evaluation_interval: <duration> | default = 1m ] # alertmanager # How long to initially wait to send a notification for a group # of alerts. Allows to wait for an inhibiting alert to arrive or collect # more initial alerts for the same group. (Usually ~0s to few minutes.) [ group_wait: <duration> | default = 30s ] # 初次發送告警的等待時間  # How long to wait before sending a notification about new alerts that # are added to a group of alerts for which an initial notification has # already been sent. (Usually ~5m or more.) [ group_interval: <duration> | default = 5m ] 同一個組其他新發生的告警發送時間間隔  # How long to wait before sending a notification again if it has already # been sent successfully for an alert. (Usually ~3h or more). [ repeat_interval: <duration> | default = 4h ] 重復發送同一個告警的時間間隔

通過上面的配置，我們來看一下整個告警的流程。通過流程去發現問題。

根據上圖以及配置來看，prometheus抓取數據后，根據告警規則計算，表達式為真時，進入pending狀態，當持續時間超過for配置的時間后進入active狀態;數據同時會推送至alertmanager，在經過group_wait后發送通知。

告警延遲或頻發

根據整個告警流程來看，在數據到達alertmanager后，如果group_wait設置越大，則收到告警的時間也就越長，也就會造成告警延遲;同理，如果group_wait設置過小，則頻繁收到告警。因此，需要按照具體場景進行設置。

不該告警的時候告警了

prometheus每經過scrape_interval時間向target拉取數據，再進行計算。與此同時，target的數據可能已經恢復正常了，也就是說，在for計算過程中，原數據已經恢復了正常，但是被告警跳過了，達到了持續時間，就觸發了告警，也就發送了告警通知。但從grafana中看，認為數據正常，不應發送告警。這是因為grafana以prometheus為數據源時，是range  query，而不是像告警數據那樣稀疏的。

看完上述內容是否對您有幫助呢？如果還想對相關知識有進一步的了解或閱讀更多相關文章，請關注億速云行業資訊頻道，感謝您對億速云的支持。

上述內容就是prometheus告警問題的示例分析，你們學到知識或技能了嗎？如果還想學到更多技能或者豐富自己的知識儲備，歡迎關注億速云行業資訊頻道。