路由合併概述
SLS的告警策略包含三種子策略：
- 路由合併
- 抑制
- 靜默
其中最重要的就是路由合併策略。簡而言之，路由合併的作用就是：告警經過一定的規則，合併成不同的合併集合，統一進行通知的發送。它的最大的優點就是可以進行告警的降噪，由於是合併後統一發送，因此可以有效避免告警風暴的產生。
可以參考如下的簡單示例：
一共產生了四個告警，它們經過路由合併之後，變成了三個合併集合，其中Alert-1和Alert-3在一起，會被一起發送通知。當然這只是一個非常簡單的示意，可以簡單理解為這裡根據的是不同的顏色進行了合併。在實際的使用場景中，可以根據告警自身的多種屬性進行策略的配置，例如把相同嚴重度的告警合併在一起，或者把同一個Project產生的告警放在一起，等等。在瞭解了路由合併的基本作用之後，接下來我們來看路由合併的一些詳細使用。
告警指紋
在對路由合併進行深入的瞭解之前，我們需要先來認識一下告警的指紋。簡單來說，每個告警都需要有一個唯一的身份證號，需要我們來識別它。
例如 08:00 產生了一條告警，說的是 192.168.1.100 這臺機器 CPU 使用率過高，達到了 90%；然後再 08:05 繼續產生了一條告警，說 192.168.1.100 這臺機器 CPU 使用率過高，達到了 95%。在這個例子中，我們可以看到，這兩個觸發的告警描述的其實是同一件事情，本質上它們其實是同一個告警，只不過是在連續的兩個週期都觸發了而已。就好像某個人昨天穿了白色的衣服出門，今天穿了黑色的衣服出門，雖然看起來有稍許區別，但其實還是同一個人。
對於告警來說，也有這樣的一個唯一標識，不管它在什麼時候觸發，我們都可以通過該標識來知道，它描述的某一個確切的事情。我們可以稱之為告警的指紋。如果兩個告警的指紋完全相同，那麼它們就是同一個告警的兩次出現。
告警指紋的計算依賴於告警的如下屬性：
- 用戶ID：阿里雲賬號UID
- Project：告警監控規則所在的項目
- 告警規則ID
- 告警標籤（key-value 結構）
一句話概括就是：如果兩條告警屬於同一用戶在同一個Project下創建的同一條告警監控規則，並且它們的標籤相同，那麼就是同一個告警。
關於告警的標籤，是在配置監控規則的時候設置的。
- 分組評估：
-
- 不分組：則默認沒有標籤
- 標籤自動：僅對時序庫有效，自動將時序指標的所有標籤作為告警的標籤
- 標籤自定義：需要用戶自己配置分組的標籤，例如
* | select host, count(*) as cnt group by host這樣的查詢語句，結果裡會有 host 和 cnt 兩個字段，假如用戶配置了按照 host 進行分組，那麼告警裡就會有 host 這個標籤
- 如果開啟了無數據告警，那麼還會有一個特殊的標籤
__no_data__ - 此外用戶還可以自己添加標籤，例如自己添加
app: nginx類似的固定標籤
基於告警指紋的降噪
假如同一個告警一直在觸發，那麼在告警管理的流程中，只會保留最新的那一次觸發。也就是說，每個告警集合會根據告警的指紋進行去重，僅保留最新版本。
例如：某臺主機從 20:00 開始每分鐘不停地觸發高CPU告警，告警策略按照配置來進行發送。那麼在首次觸發後，後續重複的告警都會去重並且延遲（因為配置了重複等待）發送。
合併集合
上面我們解釋了告警指紋及其去重機制，接下來介紹一下合併集合。合併集合簡單來說就是一個告警的容器，是一個批量處理單元。所有在該容器內的告警都會進行統一的發送通知。
合併集合有如下屬性：
- 合併基準
- 行動策略
- 首次等待時間
- 變化等待時間
- 重複等待時間
這幾個屬性解決了如下問題：
- 為什麼告警會在一起：合併基準
- 要發送給誰：行動策略
- 如何發送：首次等待、變化等待、重複等待
我們可以配置告警策略的路由合併基準，將告警歸類自動分派到多個合併集合中，並進一步的降噪控制（去重、合併等）後，將合併的告警分別發送給相應的行動策略。
例如上面的例子，通過合併基準的配置，將十個告警分到了六個合併集合中，並且會使用各自的行動策略來進行通知的發送。
使用告警策略進行數據隔離
通常來說，如果兩個合併集合的五個屬性完全相同，那麼它們本質上就是同一個合併集合。但是這有個前提，就是需要這兩個合併集合是由同一個告警策略產生的。
也就是說，告警策略相當於是提供了一個命名空間的作用。如果兩個告警使用了不同的告警策略，那麼即使最終它們所在的合併集合各個屬性都相同，但它們也是不同的合併集合。
因此可以使用告警策略來進行告警數據的隔離。例如不同的團隊使用不同的告警策略，那麼這兩個團隊的告警數據肯定不會混在一起，每個團隊只需要關注自己的告警策略配置即可。