prometheus告警問題的示例分析

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

問題分析

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

先來看一下官網(wǎng)提供的prometheus和alertmanager的一些默認(rèn)的重要配置。如下所示：

# promtheus global:   # How frequently to scrape targets by default. 從目標(biāo)抓取監(jiān)控?cái)?shù)據(jù)的間隔   [ scrape_interval: <duration> | default = 1m ]   # How long until a scrape request times out. 從目標(biāo)住區(qū)數(shù)據(jù)的超時(shí)時(shí)間   [ scrape_timeout: <duration> | default = 10s ]   # How frequently to evaluate rules. 告警規(guī)則評(píng)估的時(shí)間間隔   [ 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 ] # 初次發(fā)送告警的等待時(shí)間  # 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 ] 同一個(gè)組其他新發(fā)生的告警發(fā)送時(shí)間間隔  # 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 ] 重復(fù)發(fā)送同一個(gè)告警的時(shí)間間隔

通過上面的配置，我們來看一下整個(gè)告警的流程。通過流程去發(fā)現(xiàn)問題。

根據(jù)上圖以及配置來看，prometheus抓取數(shù)據(jù)后，根據(jù)告警規(guī)則計(jì)算，表達(dá)式為真時(shí)，進(jìn)入pending狀態(tài)，當(dāng)持續(xù)時(shí)間超過for配置的時(shí)間后進(jìn)入active狀態(tài);數(shù)據(jù)同時(shí)會(huì)推送至alertmanager，在經(jīng)過group_wait后發(fā)送通知。

告警延遲或頻發(fā)

根據(jù)整個(gè)告警流程來看，在數(shù)據(jù)到達(dá)alertmanager后，如果group_wait設(shè)置越大，則收到告警的時(shí)間也就越長(zhǎng)，也就會(huì)造成告警延遲;同理，如果group_wait設(shè)置過小，則頻繁收到告警。因此，需要按照具體場(chǎng)景進(jìn)行設(shè)置。

不該告警的時(shí)候告警了

prometheus每經(jīng)過scrape_interval時(shí)間向target拉取數(shù)據(jù)，再進(jìn)行計(jì)算。與此同時(shí)，target的數(shù)據(jù)可能已經(jīng)恢復(fù)正常了，也就是說，在for計(jì)算過程中，原數(shù)據(jù)已經(jīng)恢復(fù)了正常，但是被告警跳過了，達(dá)到了持續(xù)時(shí)間，就觸發(fā)了告警，也就發(fā)送了告警通知。但從grafana中看，認(rèn)為數(shù)據(jù)正常，不應(yīng)發(fā)送告警。這是因?yàn)間rafana以prometheus為數(shù)據(jù)源時(shí)，是range  query，而不是像告警數(shù)據(jù)那樣稀疏的。

看完上述內(nèi)容是否對(duì)您有幫助呢？如果還想對(duì)相關(guān)知識(shí)有進(jìn)一步的了解或閱讀更多相關(guān)文章，請(qǐng)關(guān)注億速云行業(yè)資訊頻道，感謝您對(duì)億速云的支持。

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