現在告警系統可以說是系統的必備部分，只要有監控，就需要一個告警系統來幫忙主動推送消息，以此減少人不停的主動查看監控的作用。

在最初的告警系統中，基本主要就是設置閾值，達到閾值就發生告警。這個在機器數量少的時候是滿足需求的。例如10個進程，就算都出問題也就是10條告警。在使用的過程中，隨著進程數量的增多，告警種類的增多。會出現告警的洪荒，一直不停的收到告警。

重復性

為了準確的傳達告警信息，告警的設計要只要問題不解決就需要一直告警，否則很容易出現告警信息不可達，人查看的時候忽略了。這種問題，需要讓告警持續的發送，直到解除為止。

分級

這里為了減少告警信息，我們會設置告警的級別。

cpu >80 嚴重

80 > cpu > 50 一般

然后發送告警的時候加上告警級別，郵件的規則根據告警的級別進行分類，就可以很容易的去找出嚴重的優先處理，一般的緊急程度就低一些。

靜默

雖然通過級別可以篩選出一些特別重要的信息，但是告警是一直持續發送的。例如cpu只要還在超過80，一定的時間間隔內，就會繼續發送告警，嚴重級別的郵箱很快也多起來。而且是同一個告警的不同時間的信息。這個時候如果有其他嚴重級別的告警的時候，很容易被沖刷掉。導致了一定的延后性，需要指望這個告警信息也不停的發送，如果間隔時間不一樣的話，很容易出現一些失誤。

這里就需要有一個靜默功能。

例如我收到了A進程的cpu使用率的告警，我現在開始去做處理，這時候并不能立馬解決這個問題。可以通過靜默的功能，把A進程的cpu告警取消發送。直到解決了問題以后再打開。中間過程如果再繼續收到信的告警，就需要再次注意了，證明和手頭正在解決的不是同一個問題。

抑制

我們想一個場景，現在有如下的告警設置

物理機宕機告警

進程探活告警

api接口超時告警

當物理機宕機后，上面的所有進程肯定也都停止了，探測api的檢測功能也檢測不到api能正常返回了。于是觸發了3條告警信息。但他們描述的根源的原因是同一個。如果一個機器上有20個進程，總共有300個api。那么就會一下子收到1+20+300=321條告警信息。這么多告警信息，人收到都是迷茫的，主動靜默都是很大的工作量。得靜默321條情況，這里也能直接選擇把告警去掉，也怕別的程序也這個時候出了問題，導致告警的丟失。

這里就需要告警的抑制。上面表達是一個包含關系，api超時的原因是進程停止了，進程停止了原因是物理機停止了。這種場景其實報告物理機的宕機告警就可以。

也是就是物理機告警，進程告警，端口告警同時出現的時候，物理機的告警要抑制進程告警，抑制api告警。

路由設置

告警信息的通知是需要多樣的，例如什么樣的告警，什么樣的級別通過什么樣的形式發送(郵件，短信，電話)。這個是需要分層的。越緊急的事情就需要越緊急的方式，例如普通的告警就發送郵件就可以了。但是嚴重的告警，管理員可能晚上睡著了，郵件的消息通知可能不能被看到，這里可能就需要通過電話開通知。選擇了更可靠的方式。

總結

以上是生活随笔為你收集整理的java告警系统设计_告警系统的设计的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。