圖 1. 噪音數和故障數等趨勢

利用應急事件詳情可快速定位對應監控，其中紅框是監控id，對應於antmonter（集團監控系統）所配置報警監控。

圖 2. 噪音及對應事件和監控

1. 如何衡量監控效果

對於監控報警而言，衡量效果最有效的指標為召回率——即衡量能夠正確識別出正樣本的百分比。召回率的計算公式為：召回率 = 正確識別的正樣本數 / 所有正樣本數。對於監控能夠保證召回率接近 100%，同時儘量提升準確率。在保證召回率，識別線上問題的同時，提升準確率降低噪音，便是監控治理要做的事。

2. 監控規則

有了衡量效果的指標，我們就需要對監控進行降噪。目前監控主要使用的是規則降噪，分為普通規則和智慧規則。普通規則更加個性化、更加方便實用，也有主要缺點：需要開發者同時對監控系統和組內業務非常瞭解，能夠預估報錯量，隨著業務的發展要經常更正，同時容易由於資料波動出現告警遺漏、告警頻繁。那麼針對普通規則，如何進行降噪？

(a). 避免維度單一

單一維度的監控配置，往往難以到達較好的監控效果，同時極易產生噪音。例如，單一設定業務成功量或失敗量，當n個單位採集時間低於或高於某閾值時報警。這種方法往往會在某些時刻頻繁報警，例如半夜，早晚高峰等等。必須根據業務場景增加多維度觸發條件，解決該問題方案如下：

1. 成功量級 + 成功率 / 失敗量級 + 成功率 適用降噪場景：成功量上升，是因為總量上升導致；失敗量下降，是因為總量下降導致。

2. 成功量級 + 成功率 + 總量 適用降噪場景：避免極少業務量場景下極端失敗情況，例如兩筆業務量，一筆失敗或兩筆都失敗 導致的報警。

3. 成功率 + 失敗數量 適用降噪場景：同樣適用極少業務量場景下極端失敗情況。

4. 設定採集週期 適用降噪場景：避免衝高回落導致的針狀突出噪音，如網路抖動導致問題。其中週期的範圍則需要開發運維人員更具業務量級和組內業務自行確定，透過召回率和準確率進行確定。

(b). 利用黑白名單

對於一部分監控，總會存在部分業務或介面極易超出設定報警閾值的情況，此時利用黑白名單進行單獨配置即可。

1.應用呼叫下游介面成功率監控，如果存在部分介面因業務問題造成失敗，或部分外部呼叫介面經常失敗且無影響，我們就需要將其進行單獨配置監控。首先透過噪音打標場景查出經常報警且標記為噪音的介面，在監控處透過黑白名單，黑名單過濾掉噪音介面，並對其配置一項敏感度較高的閾值，再配置一個監控，將這些介面加白，白名單部分減少監控敏感度。

圖5 敏感度配置

2. 業務錯誤碼報警。監控平臺能夠自定義配置所需監控錯誤碼，其來源於日誌當中有一些資訊，可以用來幫助我們判斷是否需要關心這種日誌。在進行資料採集時，可以自定義所需要關注的日誌資料，並配置白名單值，如圖6所示，之後可以選中其在產出日誌所在位置，利用監控自動進行資料獲取，如圖7所示。

圖6. 自定義日誌資料採集白名單

圖7. 日誌資料採集範圍

(c). 利用環比和同比

業務的總量，成功量，介面的呼叫成功率，單機應用error總數等等，總會存在一個資料慣性，如果最近一小時總量總是維持在每分鐘100，幾乎不可能會突變至每分鐘總量1000且持續存在。這樣我們就認為慣性失效，可能存在異常從而告警。這就衍生出環比和同比的作用。環比和同比是什麼？

環比，是指相鄰兩個時間段之間值的比較，即縱向的對比。以時刻為例，環比就是指此刻一小時與上一小時同一指標的變化率，計算公式為：（當前一小時指標-上一小時指標）/上一小時指標。

同比，是指同一時間段相鄰值之間的比較，即橫向的對比。以天為例，同比就是指今日此刻與昨日此刻同一指標的變化率，計算公式為：（今日此刻數值-昨日此刻數值）/昨日此刻數值。

由此可見，利用環比可監控慣性的變化，而利用同比可排除慣性的錯誤情況。對於監控而言，我們通常可以選擇 採集週期為當前五分鐘與上一個五分鐘作為環比，監控其下降或者上升的程度，從而監控慣性的變化。選擇同一時期與昨日或者上週作為同比，監控其下降或者上升的程度，從而判斷慣性變化是否所為異常。

圖8. 同比與環比監控

智慧降噪作為antmonter給出的智慧工具，可以有效進行降噪。

a.告警抑制：告警抑制可以幫助在大量報警風暴的情況下進行降噪，設定抑制採集週期數（如週期為一分鐘，則設定週期數為5則抑制五分鐘報警）。

b.短週期抖動：短週期抖動是一種網路抖動等原因導致瞬間凸狀報錯週期，會導致採集週期內整體資料求和、求平均值等偏高超過閾值而產生告警。輸入短週期比例，則可以在產生該比率的報警週期時抑制，例如，採集週期為N，短週期比率A，則產生的報警在N * A內，則會被抑制。

c.衝高回落：衝高回落通常是指指標在一段時間內呈現出明顯的上升趨勢，突破了某個閾值或警戒線，但隨後迅速回落到原來的水平，相當於是一次短暫的異常波動。衝高回落是指監控指標在一段時間內上漲後又下跌。當勾選該模式後，若出現監控指標在設定時間段內的持續衝高後又下跌回平穩狀態，將不會觸發告警通知。

CDO（Complex Event Detection and Optimization）報警是一種複雜事件的監測，用於對系統的異常事件和效能問題進行監測和排查。對於CDO報警的降噪，除了列印error，warn日誌規範外，還有對異常丟擲的規範。對於一個應用來說，通常需要定義一個專有業務異常來服務於業務系統，並在出現可控業務問題時進行丟擲，而出現未在可控範圍內異常時再使用通用異常。下面舉個例子來進行異常與日誌的搭配程式碼

首先定義業務異常 BizException

public class BizException extends RuntimeException {    /** serialVersionUID */    private static final long serialVersionUID = 5840651686530819567L;
    /** 異常錯誤程式碼 */    private ResultCodeEnum    code             = ResultCodeEnum.UN_KNOWN_EXCEPTION;
    /**     * 建立一個<code>BizException</code>     *      * @param code 錯誤碼     */    public BizException(ResultCodeEnum code) {        super(code.getMsg());        this.code = code;    }
   /**     * 建立一個<code>BizException</code>     *      * @param code 錯誤碼     * @param message 自定義錯誤資訊     */    public BizException(ResultCodeEnum code, String message) {        super(message);        this.code = code;    }}

其次，定義業務處理模板，當丟擲業務異常時，在生產環境會進行warn日誌列印，而對於其餘不在可控之中的異常，則使用error日誌列印。在丟擲可控，不會導致系統崩潰或無法使用異常時，應丟擲業務異常，如此進行規範化。

public class HandleTemplate {
       public void execute(final Response response, final HandleCallback action) {        Profiler.enter("開始進入操作模板");        try {
            action.doPreAction();
            action.doAction();
            action.doPostAction();
        } catch (BizException be) {            if (EnvEnum.DEV.getType().equals(EnvUtil.getExactEnv())) {                LogUtil.error(LOGGER, be, "業務異常:");            } else {                LogUtil.warn(LOGGER, be, "業務異常:");            }            ResultUtil.generateResult(response, be);        } catch (IntegrationException ie) {            LogUtil.error(LOGGER, ie, "查詢業務異常:" + ie.getMessage());            ResultUtil.generateResult(response, ie);        } catch (Throwable e) {            LogUtil.error(LOGGER, e, "作業系統異常:" + e.getMessage());            ResultUtil.generateResult(response, ResultCodeEnum.SYSTEM_ERROR, e.getMessage());        } finally {
        }    }
}

此外，對於warn日誌和error日誌的使用也需要進行規範化，WARN日誌應該用於記錄系統發生了一些異常事件，但

這些事件不會導致系統崩潰或無法使用。例如輸入引數異常或不規範，輸入的引數為空、非法、越界等。ERROR日誌通常用於輸出一些嚴重錯誤資訊，表示系統發生了一些致命的錯誤，例如空指標異常導致系統崩潰、無法使用，未授權訪問、入侵等。如此進行規範化，則可以正確治理CDO報警。

此外，還有一些比較有必要的降噪方法，以適合不同場景下的降噪情況。

1.去除預發環境。去除預發環境的監控報警，只訂閱生產環境，避免無謂的資源消耗和時間消耗。

2.設定生效時間段。根據業務時間調整生效時間段，對於有高低峰期業務特性，配置生效時間段，從而減少低峰期報警噪音。同時設定生效時間段 + 連續N分鐘內只報警一次，可以避免大量報警風暴。

3.報警抑制，避免報警風暴。

4.去除不必要和重複報警，正確訂閱報警，如一些自動配置化的報警，以及做好報警監控日誌分析，避免大量重複覆蓋流量的監控報警。

5.傳送渠道最佳化。根據業務重要程度設定不同報警渠道，避免大量簡訊郵件轟炸。

自六月治理報警以來，噪音數已經大大減少，從佔整體事件的61.70%下降到12.80%，同時打標為故障數的報警數量維持變化不大，可以說明監控保持召回率不變的同時，準確率大大提升。

五月噪音率：

六月噪音率：

最後一定要注意，降噪的治理一定要結合業務實際，並在降噪後的一定時間內以指標進行衡量，如召回率，準確率等，否則以個人感覺進行調整，就會有可能出現線上問題被遮蔽的情況！降噪的目的，是保證召回率的同時，儘量提高準確率。