*作者：宋傲（凡星）*

## 背景及現狀

### 系統架構簡介

![1.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/8afd726ca9b4456fbc9f4a7b19ead559~tplv-k3u1fbpfcp-zoom-1.image "1.png")

上圖為阿里雲內部實際使用的系統架構，系統主要用途為實時資料流的計算和儲存。使用阿里雲的容器服務 ACK 作為系統底座，容器化的部署、釋出、管控等全部基於 K8s 標準。使用自己開發的 Gateway service 作為系統流量入口，並基於 LoadBalancer 型別的 service 部署。

此架構也是應用 K8s 做系統較為常見的做法，透過 ACK 提供的 CCM 元件自動將 service 和底層 SLB 例項進行繫結，透過此例項承接外部流量。Gateway 收到上報的資料流後，將資料放入 Kafka 並在某個 topic 中進行資料緩衝。當 Consumer 感知到資料流的上報後，則會從 Kafka 相應的 topic 中對資料進行進一步計算處理，並將最終結果寫入儲存介質。

此處存在兩種儲存介質：其中阿里雲塊儲存 ESSD 相對較快，但價格較高；檔案儲存 NAS 主要用於存放效能要求較低的資料。後設資料由 ACM 進行管理，自研的元件 Consumer 和 Center 負責從儲存介質中查詢計算結果，並返回給使用者。

### 系統現狀

![2.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/17ecd0b473f643cd9635cdfb75bd1715~tplv-k3u1fbpfcp-zoom-1.image "2.png")

系統目前為全球開服，部署在全球將近 20 個 region 中，從圖中也可以間接看出資料讀寫鏈路較長，需要經過多個元件的處理。監控物件也較為複雜，包括基礎設施（排程、儲存、網路等）、中介軟體（Kafka）、業務元件（Gateway、Center、Consumer）。

### 工作內容

-   **可觀測資料的收集**

![3.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/3a2b4df4faaa4f39aec24cea7cb692bd~tplv-k3u1fbpfcp-zoom-1.image "3.png")

可觀測性主要包含Metrics、Tracing 和 Logging三類資料。三類資料各司其職，相輔相成。

Metrics 負責回答系統是否出現問題，它也是系統的自監控體系入口。針對 Metrics 做異常的告警或問題的排查，可以快速確定系統是否有問題，是否需要人為介入處理。

Tracing 負責回答系統問題出現在什麼位置，它能夠提供元件之間的呼叫關係、每一次請求以及哪兩個元件之間的呼叫過程出現了問題等具體細節。

找到出現問題的元件後，需要透過最詳細的問題日誌即 Logging 來定位問題根因。

-   **資料視覺化&問題排查**

![4.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/eb6f0cddc8b448cfbbdc1f76d1e30edf~tplv-k3u1fbpfcp-zoom-1.image "4.png")

收集到三類資料後，下一步需要透過大盤將資料用視覺化的方式展現，能夠一眼確定問題所在，使問題排查更高效。

-   **告警&應急處理**

![5.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/99872fc1e8894df09ae134bb72c72caa~tplv-k3u1fbpfcp-zoom-1.image "5.png")

確定問題後，需要透過告警和應急處理流程來解決問題。

應急處理過程主要有以下幾個要點：

第一，需要分級的告警通知和升級策略，能夠快速找到相應的人員處理告警。與此同時，若原定人員因為某些原因無法及時處理，還需將告警升級到其他人員以及時處理。

第二，問題認領和處理流程標準化。

第三，事後統計及覆盤。系統出現故障並解決後，還需要事後的統計以及覆盤工作，讓系統透過故障和教訓避免後續再出現相同的問題，讓系統更穩定。

第四，運維處理工具化、白屏化，儘量減少手動輸入命令的工作，將整套標準的處理動作用工具進行固化。

## 實踐經驗分享

### 可觀測資料收集&接入

-   **指標（Metrics）資料**

![6.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/1dd2da573b614bfb85be733b8b151c54~tplv-k3u1fbpfcp-zoom-1.image "6.png")

監控的第一步是收集可觀測資料，這些資料在系統裡可以分為三個層面。

最上層為應用層，主要關心核心業務介面的健康度，透過RED（Rate、Error、Duration）三個黃金指標進行衡量。其中 Rate 指介面的 QPS 或 TPS ，Error 指錯誤率或錯誤數，Duration 指介面在多長時間內能夠返回。可以透過黃金指標來定義 SLO 並分配 Error Budget 。如果 Error Budget 很快耗盡，則應及時調整 SLO，直到系統最佳化到足夠完善後，再將其調高。也可以透過 Apdex Score 衡量服務的健康度，計算公式如上圖所示。此外，應用層也會關心與業務強相關的指標，比如營收、使用者數、UV、PV 等。

![7.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/04d27fc6d8f94442a63808aec2a31fbb~tplv-k3u1fbpfcp-zoom-1.image "7.png")

中間層為中介軟體和儲存，主要關心繫統裡大量應用的 Kafka client 端消費位點的提交狀況、生產者緩衝區的佔用率、是否會提前將緩衝區佔滿導致新的訊息進不來、消費延遲、平均訊息大小等，比如 Kafka Broker 端的水位、讀寫流量、磁碟使用率等，再比如雲盤 ESSD 的掛載成功率、IOPS、磁碟空餘空間等。

![8.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/52be89f3de3844abb5f0282165a7bdaa~tplv-k3u1fbpfcp-zoom-1.image "8.png")

最下層是基礎設施層，關心的指標較為複雜，典型的有比如 ECS（K8s Node） CPU 記憶體水位、重啟次數、定時運維事件等，比如 K8s 核心元件的 API server、 ETCD、排程相關指標等，比如業務 Pod 的 Pending 狀態、是否有資源可供足夠的排程、OOMKilled 事件、Error 事件等，再比如 VPC/SLB 相關的出口頻寬、丟棄連線數等。

![9.jpeg](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/2a0a47e1430e411295e777ae2692c0ff~tplv-k3u1fbpfcp-zoom-1.image "9.jpeg")

監控 ECS 節點需要使用 node-exporter Daemonset 的方式部署，K8s 雲原生的核心元件可以透過 Metrics 介面將指標暴露，供 Prometheus 抓取。Kafka 或儲存元件由於使用了阿里雲的雲產品，本身提供了基礎監控指標，可以直接接入。ACK 對 CSI 儲存外掛也提供了非常核心的指標比如掛載率、iops、空間佔用率等，也需要接入。應用層包括 Java 應用和 Go 應用，Java 使用 MicroMeter 或 Spring Boot Actuator 做監控，Go 應用直接使用 Prometheus 官方 SDK 做埋點。

![10.jpeg](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/bbe1494d147549e0abd2ee7666720113~tplv-k3u1fbpfcp-zoom-1.image "10.jpeg")

基於 ACK 和 K8s 體系， Metrics 協議的最佳選型即 Prometheus。開源自建的 Prometheus 與雲託管的接入難度不相上下，但可靠性、運維成本等方面，雲託管的 Prometheus 更優於自建。比如使用 ARMS 體系，可以直接在叢集裡安裝非常輕量級的探針，然後將資料中心化儲存在全託管的儲存元件，並圍繞它做監控、告警、視覺化等，整個過程非常方便，不需要自建開源元件。雲託管在採集能力和儲存能力上也更有優勢。

![11.jpeg](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/4bf477ba9ed145d7915ec5d9e545fe54~tplv-k3u1fbpfcp-zoom-1.image "11.jpeg")

Prometheus 針對 ECS 節點、K8s 核心元件、Kafka 和儲存元件都提供了一鍵接入的能力。

![12.jpeg](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/7a0a8544926c4854ae927f16474c217b~tplv-k3u1fbpfcp-zoom-1.image "12.jpeg")

K8s 基礎監控和節點狀態接入主要透過 ACK 元件管理中心，只需簡單地安裝相關元件，即可使用該能力。

![13.jpeg](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/d13bf4829d1d4ebdb52895646702174b~tplv-k3u1fbpfcp-zoom-1.image "13.jpeg")

Kafka 的接入主要透過 Prometheus 雲服務例項，雲服務例項目前已經接入阿里雲非常完整的 PaaS 層雲產品。接入 Kafka 時，所需填寫的指標都為常見指標，無需額外學習成本。

![14.jpeg](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/e0552ce2661845389cdf80271eae5e5b~tplv-k3u1fbpfcp-zoom-1.image "14.jpeg")

雲盤 ESSD 監控的接入主要透過 CSI 儲存外掛監控。ACK 裡的 csi-provisioner 元件提供了很有用的可觀測效能力，可以透過它提供的資訊及時檢視哪塊盤沒有掛載上、哪塊盤掛在後 iops 達不到要求或配置告警，以及時發現雲盤的異常狀況。

透過 ARMS Prometheus 接入，預置採集的 job 比如 K8s cluster 級別、node 級別的 PV 狀態都可以很方便地進行監控。

![15.jpeg](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/4a8c5ac847cf4a3c89d538c248076ade~tplv-k3u1fbpfcp-zoom-1.image "15.jpeg")

應用層不存在一鍵接入的便捷方式，需要透過應用埋點+服務發現的方式，將整個應用的 Metrics 介面暴露出來，提供給 ARMS Prometheus 的探針抓取。

![16.jpeg](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/a9e85a84eb184a28adb1e6232da63484~tplv-k3u1fbpfcp-zoom-1.image "16.jpeg")

Java 應用需要使用 MicroMeter 或 Spring Boot Actuator 進行埋點。

以上圖程式碼為例，MicroMeter 中很多 JVM 相關資訊可以簡單地透過幾行程式碼進行暴露，其他更有幫助的資訊，比如程式級別的 memory 或 thread、system 資訊等也可以透過很簡單的方式將其接入。設定完埋點後，需要在內部啟動 server ，將 Metrics 資訊透過 HTTP 介面的方式暴露，最後繫結指定的埠。至此，埋點流程結束。

此外，如果有業務指標，只需將自己的指標註冊到全域性的 Prometheus Registry 即可。

![17.jpeg](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/f5535598fda249648e011139f785a9e7~tplv-k3u1fbpfcp-zoom-1.image "17.jpeg")

ARMS 探針抓取暴露的端點，只需新增 ServiceMonitor ，由 ServiceMonitor 直接透過控制檯白屏化的方式，簡單地寫幾行 YAML 的定義，即可完整地將整個監控的採集、儲存和視覺化跑通。

![18.jpeg](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/b05ac42d98f64206988da383e3e108df~tplv-k3u1fbpfcp-zoom-1.image "18.jpeg")

Go 應用與 Java 大同小異，只是埋點方式有所區別，主要使用 Prometheus 官方的 SDK 埋點。

以上圖為例，比如系統裡有一個查詢元件關心每一條查詢的時間分佈，可以使用 Prometheus 裡面直方圖型別的指標，記錄每個請求的時間分佈，並在埋點的時候指定常用的分統進行統計。再由 ServiceMonitor 將 Go 應用的 endpoint 寫入，最終在控制檯上完成整套應用的接入。

![19.jpeg](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/615fd4b46a1049e0a326f0dcd2c31b59~tplv-k3u1fbpfcp-zoom-1.image "19.jpeg")

ARMS 還提供了基於 eBPF 的無侵入可觀測性實現方案，主要適用於不希望修改程式碼的場景，使用無侵入的方式監控系統介面的 RED，透過 ARMS Cmonitor 探針結合 eBPF 的方式，透過系統核心的 filter 實現資訊的抓取和儲存。

![20.jpeg](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/7e84c0ccd7ca4263b44669f363b6c1f4~tplv-k3u1fbpfcp-zoom-1.image "20.jpeg")

使用上述方式需要在叢集裡額外安裝 Cmonitor App，安裝後可在 Daemonset 看到 Cmonitor Agent，每個節點都需要啟動 Cmonitor Agent，作用是透過 eBPF 的方式註冊到系統核心中，抓取整臺機器的網路流量，然後過濾出想要的 service 網路的拓撲等資訊。如上圖，它可以監控整個系統的 QPS 、響應時間的分佈等資訊。

-   **鏈路（Trace）和日誌（Log）資料**

![21.jpeg](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/6c7f2a6930e14b9db90872cc8e3e984a~tplv-k3u1fbpfcp-zoom-1.image "21.jpeg")

Trace 也使用 Cmonitor 來實現相關能力。日誌方面，系統元件的日誌、K8s 控制面的日誌、JVM 的 DCLog 等，主要透過 arms-Promtail （採集應用日誌的探針）將日誌投遞到 Loki 內做長期儲存。

K8s 系統事件的日誌，主要基於 ARMS 事件中心的功能對 K8s 的關鍵事件、Pod 排程上的 OOM 、Error 等事件進行監護。

-   **讀寫鏈路監控和問題定位**

![22.jpeg](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/6fa1c38b6a17416385bdd0970aafd5c5~tplv-k3u1fbpfcp-zoom-1.image "22.jpeg")

上圖為部分系統截圖。

比如 trace 相關控制檯可以檢視每個請求經過的元件、接收用時、處理時長、回應耗時等標準資訊。

-   **元件執行日誌收集和儲存**

![23.jpeg](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/f03c92e0effd4fb5ae88ffae80862ea1~tplv-k3u1fbpfcp-zoom-1.image "23.jpeg")

日誌收集方面，透過在 Grafana 裡配置 Loki 的資料來源，即可輕鬆根據關鍵字或 Pod 標籤快速獲取到 Pod 或某個 service 下掛載的 Pod 日誌，對排查問題提供了極大便利。

-   **K8s 執行事件收集和監控**

![24.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/52ccf4128a1649989cf3e92284f7c6d9~tplv-k3u1fbpfcp-zoom-1.image "24.png")

上圖為 ARMS 提供的事件中心工作臺截圖。工作臺提供了關鍵事件列表，可以對等級較高的事件進行訂閱，訂閱只需簡單幾步：填寫基本規則，選擇需要匹配事件的模式，選擇告警傳送物件，即可對關鍵事件進行監控，實現及時響應的目的。

### 資料視覺化及問題排查

-   **Grafana 大盤配置實踐**

![25.jpeg](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/2296fd0649ed4f1a82ee18810c8149b2~tplv-k3u1fbpfcp-zoom-1.image "25.jpeg")

完成資料收集後，下一步需要打造高效可用的資料視覺化和問題排查工具。

Prometheus 與 Grafana 是一對黃金搭檔，因此我們也選擇了 Grafana 作為資料視覺化的工具。上圖列舉了大盤配置過程中的要點：

-   載入大盤時需要控制每個 panel 上的查詢時間線，避免在前端展現過多時間線，導致瀏覽器渲染壓力大。而且，對於問題排查而言，一次性顯示多時間線並沒有幫助。

-   大盤配置了很多靈活的 Variable ，可以隨意在一張大盤上切換各種資料來源和查詢條件。

-   使用 Transform 讓 Table Panel 靈活展現統計資訊。

-   分清 Range 和 Instant 查詢開關，避免無用的範圍查詢拖慢大盤顯示速度。

![26.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/ce4de44cface4900bc27604232c909b0~tplv-k3u1fbpfcp-zoom-1.image "26.png")

K8s叢集總覽

上圖為監控節點資訊、 K8s 叢集 Pod 資訊的大盤。整體佈局一目瞭然，透過不同顏色對關鍵資訊進行標記，透過 Grafana 的動態閾值功能將數字以不同的形式展現，提升問題排查效率。

![27.jpeg](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/e0de2679c664469cbfd42c2f0752c6d5~tplv-k3u1fbpfcp-zoom-1.image "27.jpeg")

節點水位

上圖為節點水位大盤，展示了磁碟iops 、讀寫時間、網路流量、記憶體使用率、CPU使用率等重要資訊。

![28.jpeg](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/480c97c9e826462aa6714aa4af64124c~tplv-k3u1fbpfcp-zoom-1.image "28.jpeg")

全域性 SLO

上圖為全域性 SLO 大盤 。透過 Grafana 託管服務配置自定義大盤，這也是 ARMS 最新上線的功能，在雲上託管 Grafana 例項，即可透過雲賬號直接登入到 Grafana 介面，其中包含阿里雲定製的特有功能。

大盤中包含了全域性 latency、QPS、成功率、錯誤碼的分佈情況、QPS 的變化趨勢，以及一些較細粒度的資訊，比如單分片、負載均衡、Gateway 元件、center 元件等。如遇發版，可以透過帶上版本號檢視前後版本的區別，可以在 pannel 中以變數的形式展現 datasource，也可以選擇全球各個 region 進行切換檢視。

![29.jpeg](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/b09a682dedc344648e7ee7d62a100b24~tplv-k3u1fbpfcp-zoom-1.image "29.jpeg")

Kafka 客戶端及服務端監控

叢集中依賴 Kafka 客戶端和服務端，其監控來源於雲監控整合。

![30.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/ce83310245274d0384db9b268191bfde~tplv-k3u1fbpfcp-zoom-1.image "30.png")

內部元件強依賴於 Kafka，透過指標監控 Kafka 以及它與 broker 之間的連線數、平均訊息長度、位點提交速率、消費流量等。Producer 端提供了緩衝區的佔用率、活躍的 producer 數等資訊。

![31.jpeg](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/6cf406f661cc4a72a58b4ca505da12ef~tplv-k3u1fbpfcp-zoom-1.image "31.jpeg")

Java 應用執行情況監控

如果元件使用 Java 編寫，還需要監控 JVM 相關的 GC 情況，大盤能夠提供 JVM memory 的情況、GC 相關情況、CPU 使用率、執行緒數、執行緒狀態等。此外，比如發版或有動態載入的類，在載入類的統計中可以檢視是否存在持續上升的狀態等。

![32.jpeg](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/5dd12be88e9640f4ad4fd6afcc31022a~tplv-k3u1fbpfcp-zoom-1.image "32.jpeg")

Table 格式的錯誤型別覆盤統計表

如果希望使用電子表格統計叢集中的安裝狀態或重點客戶狀態，可以使用 Grafana 的 transform 功能將整個大盤打造成電子表格式的體驗。可以用 transform 將欄位對映到一張電子表格上，開啟 filter 後還可透過篩選各種欄位得出查詢結果。

-   **問題排查案例分享**

![33.jpeg](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/d9d67ac8f33f4281b322bcd2131fd21a~tplv-k3u1fbpfcp-zoom-1.image "33.jpeg")

日誌資訊的展示需要透過在 Grafana 裡查詢 Loki 的資料，比如 center 裡有查詢日誌，其中包含很多原始資訊，比如此次查詢的時間、UID 等。透過後處理的方式，首先將想要的日誌按行的方式進行篩選，然後透過模式匹配提取資訊，後續還可以按照 PromQL 將其中某些欄位的做大小關係的匹配，最終將匹配出來的日誌格式進行二次處理。

### 告警和分級響應機制

![34.jpeg](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/48bf4db57d9a4873ad92bfff8b036a89~tplv-k3u1fbpfcp-zoom-1.image "34.jpeg")

上圖為告警和分級響應機制流程，依次為告警配置、人員排班、告警觸發、應急處理、事後覆盤和機制最佳化，最後將機制最佳化體現在告警配置上，形成完整的閉環。

![35.jpeg](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/ec61522b30884b3abe4adaf3ded08121~tplv-k3u1fbpfcp-zoom-1.image "35.jpeg")

以上流程是自建的告警系統，透過依賴自建系統定時跑任務檢查指標，然後呼叫釘釘的 webhook 或其他運維繫統的 webhook 發出告警，流程中存在幾點不足：

1. 自建系統的穩定性需要自己負責，如果告警系統的穩定性比運維繫統更差，則告警系統的存在無意義。其次，隨著整個叢集開服的 region 越來越多，配置越來越複雜，自己維護配置並保證配置全球生效難以實現。

![36.jpeg](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/4db8608c4c0d479db84232c9e408053b~tplv-k3u1fbpfcp-zoom-1.image "36.jpeg")

2. 依賴手工排班，極易出現漏排或 backup 缺失。

![37.jpeg](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/ec3bda3ce43546f4a02e26ea3a975b7b~tplv-k3u1fbpfcp-zoom-1.image "37.jpeg")

3. 告警觸發階段觸發條件非常單一，難以在告警觸發鏈路上增加額外的業務邏輯，如動態閾值、動態打標等。

![38.jpeg](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/ad10d26f53224dbca87aa56d77f77b3b~tplv-k3u1fbpfcp-zoom-1.image "38.jpeg")

4. 應急處理階段，資訊傳送非常頻繁，無法主動認領和主動關閉。系統出現問題時，同類告警會在群裡高密度傳送，無法主動遮蔽告警也是缺陷之一。

![39.jpeg](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/b8bf172521e14ce0a3b1704e7712ba28~tplv-k3u1fbpfcp-zoom-1.image "39.jpeg")

5. 事後覆盤最佳化的時候沒有資料支撐，無法根據已有的告警統計資訊來最佳化整個流程。

因此，我們選擇基於 ARMS 來建立告警系統。ARMS 強大的告警和分級響應機制為我們帶來了諸多便利：

![40.jpeg](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/fa059442a84348d3a009d497b9e3bf55~tplv-k3u1fbpfcp-zoom-1.image "40.jpeg")

1. 告警模板全球生效功能：只需配置一次告警規則，即可使不同的叢集生效告警規則。比如沒有告警模板時需要對每個 cluster 裡的指標單獨配置告警。而有了模板後，只需透過告警規則模板的方式將 PromQL 或告警的 AlertRule  apply 到全球各個 region 叢集，非常方便。

![41.jpeg](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/71ec472e27714b54ab719e7da28ab2b2~tplv-k3u1fbpfcp-zoom-1.image "41.jpeg")

2. 告警排班表和動態通知：系統能夠動態實現輪班替班工作，比手工排班更靠譜。

![42.jpeg](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/52cabccf98a049efa8d3fa23b4c7f6f4~tplv-k3u1fbpfcp-zoom-1.image "42.jpeg")

3. 事件處理流和告警富化：可以透過 ARMS 的事件處理流、告警中心的事件處理流和告警富化功能，在告警觸發後動態地打上標記，並且做分級處理。如上圖，可以給告警打上優先順序標籤，優先順序較高的告警等級升級為 P1，並且可以動態地修改告警接收人。

為了實現上述功能，首先需要有資料來源來提供打標的依據。在告警運維中心的控制檯上有資料來源的功能，告警觸發時可以透過 HTTP 請求或 RPC 請求呼叫資料來源，而後可以從 HTTP URL 裡獲取打標的結果。此介面的實現主要透過 IFC 輕量工具線上寫好程式碼，程式碼主要負責讀取 ACM 配置中心裡的資訊配置項，然後讀取配置項並對外暴露 HTTP 介面，提供給告警運維中心動態地呼叫。

完成以上步驟後，還需配置事件處理流，將需要的資訊透過匹配更新模式的方式傳遞到上述介面，並返回優先順序，最終打到告警上。

![43.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/80b2064b9b354b5995e320d0f56b779f~tplv-k3u1fbpfcp-zoom-1.image "43.png")

4. 告警的認領、關閉和遮蔽：ARMS 提供了認領、關閉、關注、遮蔽等實用功能，顯著提升了告警質量。

![44.jpeg](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/2e093fdbb1ef44c49be7ba83816ce161~tplv-k3u1fbpfcp-zoom-1.image "44.jpeg")

5. 告警的認領接手率統計大盤：覆盤的時候需要知道每個人處理了多少告警、處理時長、告警平均恢復時間等，引入了認領、關閉、恢復、遮蔽機制後，ARMS告警中心在後臺記錄了事件的日誌，透過對日誌的分析即可提供有用的覆盤資訊。

![45.jpeg](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/bbd3c2eaaaad48deb6a3cd153c160144~tplv-k3u1fbpfcp-zoom-1.image "45.jpeg")

得到告警資訊後，使用者希望可以在白屏化的介面上處理問題，因此我們引入了基於 Grafana 的白屏化運維工具鏈。其原理為，在配置大盤的時候引入動態資訊，並將其以連結的形式拼接到大盤裡。

我們內部有各種系統，如果沒有官方的連結拼接，則需要自己首拼 URL 或手動搜尋，效率非常低。而透過在 Grafana 裡嵌入連結的方式，將運維動作固化成連結之間的跳轉，對於效率的提升非常有幫助。能夠透過 Grafana 一套工具將所有工作完成，將運維動作標準化、固化，減少人工出錯的可能性。

## 總結和未來工作

![46.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/a0cf14a7c17a4ca1a72ccde55283c076~tplv-k3u1fbpfcp-zoom-1.image "46.png")

第一，告警準確度和接手率的最佳化。目前還沒有很好的方式能夠將告警的覆盤資訊高效地利用起來，未來我們將嘗試透過告警準確度和接手率的資訊，及時調整不合理的告警閾值，也可能會嘗試多閾值的告警，比如告警在 A 到 B 範圍之內是多少等級，在 B 以上是多少等級。

第二，多型別資料聯動。比如在排查問題的時候，除了 Metrics 、Trace 和 Log 之外，還有 profiler、CPU 的火焰圖等資訊，而目前這些資訊與可觀測資料的聯動較低。提升資料聯動，可以提升問題排查效率。

第三，埋點成本控制。對於外部客戶而言，埋點成本直接關係到客戶使用阿里雲的成本。我們將定期地對自監控指標的維度、發散的維度等進行針對性的治理，並且對於無用的維度進行資料清理，將埋點成本控制在較低水平。

釘釘掃碼，入群瞭解更多可觀測實踐

![47.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/ebabc2966d9348b29870f08c77322b8b~tplv-k3u1fbpfcp-zoom-1.image "47.png")

萬節點規模雲服務的 SRE 能力建設

相關文章