新思路設計可視化大型微服務監控系統

背景

隨著微服務在生產實踐中被大量使用，后臺系統中的服務系統數量暴增，挑戰也隨之產生。當系統出現問題時，如何在上百個相關的、依賴錯綜復雜的服務系統之中快速定位到出錯的系統？

達達 - 京東到家的 Overwatch 系統已經在線上運行了一年有余，采用了創新性的可視化監控設計，并成功幫助達達 - 京東到家的系統渡過了“雙十一”的挑戰，設計思想值得分享。

“雙十一”期間，系統承載了京東商城每天幾百萬單的壓力，“雙十一”當天單量即突破 600 萬單，第二天的單量更是超過了 800 萬單。對于大型微服務系統來說，任何一個服務系統出現問題，都可能導致大面積的系統故障。當配送員在配送過程中操作 APP 然后發現操作失敗時，究竟是訂單系統出現了問題？還是用戶系統出現了問題？還是某個第三方服務出現了問題？導致這些問題的是數據庫的慢查詢？還是系統本身的 GC？又或者僅僅是一次網絡波動？

在沒有 Overwatch 之前，每當線上系統出現報警，我們的工程師都要登上相應系統的某臺機器查看日志。然而這樣的工作收效甚微，因為可能出現問題的原因真的有很多：

• 該系統響應失敗是因為調用其他系統失敗，報出錯誤的系統本身并沒有問題。
• 調用其他系統失敗是由于網絡問題，請求并沒有到達目標系統，所以在目標系統的日志中看不到任何異常。
• 被調用的系統響應超時，導致調用方主動斷開連接，在被調用方的日志中只能看到連接意外中止的異常信息。
• 調用其他系統存在一條很長的調用鏈，無法快速追蹤到源頭。

為了達到京東商城對配送時效的高標準，我們必須快速響應、定位并解決系統故障。通過 Overwatch 系統，我們便可以做到這一點。

Overwatch 監控系統

簡介

Overwatch 是一個遠程調用監控系統，通過對系統調用外部系統的監控，并以可視化圖形的方式展現，實現對大型微服務系統可用性的監控。

Overwatch 能夠實時監控系統中所有的 RPC（廣義上的 RPC），及時發現所有 RPC 調用失敗情況。通過一個有向圖進行數據展現，讓工程師可以在多個系統同時異常時快速定位到異常的根源。

Figure 1 Overwatch 主界面截圖

數據采集

為了能夠發現 RPC 調用失敗的所有情況（包括業務問題、系統問題、網絡問題），我們討論如下兩種監控方案：

1、從服務提供方監控

對服務提供方應用容器的訪問日志（如 Tomcat 的 access.log）進行監控，將所有應用的這些日志文件通過公司現有的日志收集 - 分析系統進行統一收集分析。這樣的方案可以快速實施且無需修改現有代碼，開發量也較少。

Figure 2 日志收集 - 分析架構圖

然而這樣做的問題也很明顯：

• 無法監控到網絡問題，因為請求會由于網絡原因沒有到達服務提供方（Connect Timeout）。
• 請求響應超時（Read Timeout），這樣的請求不會展現在訪問日志中（一些版本的 Tomcat 存在該問題，包括我們正在使用的版本）。
• 無法監控到異常的響應請求，即雖然返回了 HTTP 200 狀態碼，但是實際上是請求失敗（如返回 JSON 字符串{“status”: “failed”}）。

我們不能從服務提供方進行“主觀”的監控。服務是給服務消費方使用的，服務提供方所認為的“正確”是不夠“客觀”的，只有服務消費方認為請求成功，才是“客觀”的請求成功。

2、從服務消費方監控

從服務消費方可以實現上述“客觀”的監控。

Figure 3 從服務消費方監控

但是我們需要自己實現信息的收集和聚合，同時我們需要一個在服務進程中的 Agent 去收集 RPC 信息。我們采用了 Kafka 進行數據的收集，Storm 進行數據的聚合，最后將數據交給 Overwatch 服務進程進行存儲和展現。這樣我們可以做到一個延遲在秒級的實時監控系統。

數據展現

至此，我們還需要解決一個問題：如何能夠在多個系統同時異常時，快速定位到異常的根源。傳統的監控多以柱狀圖、折線圖的形式展現信息。

Figure 4 傳統監控圖表

這樣的信息展現顯然不能滿足我們的需求，Overwatch 在信息的展現方式上需要作出改變，我們采用了有向圖的方式展現監控數據。有向圖展現 RPC 監控數據有如下優點：

• 可以在一張圖表中完整展現所有系統的狀態。
• 由于 RPC 是有向的（從消費方向提供方），使用有向圖可以完美表達出該信息。
• 圖可以表達系統之間的依賴關系，當多個系統同時異常時，可以通過觀察圖中的依賴關系來找到異常的根源。

Figure 5 有向圖概念示意圖

使用有向圖也存在一些問題：傳統圖表可以展現“監控統計值 - 時間”這樣的二維關系，而在有向圖中展現這些數據并沒有那么簡單，我們在之后的章節討論中會討論展現的方法。

在 Overwatch 中，我們會展現系統最近一分鐘、最近 5 分鐘平均、最近 15 分鐘平均的統計值（類似于 Linux 中的 uptime 所展示的信息）。要展現這些數據，Overwatch 必須取最近 15 分鐘的所有監控數據，并進行相應的聚合計算，這是開銷特別大的操作，顯然不可能對于每次用戶的查看監控請求都進行一次這樣的操作。對于這部分的實現，我們采用了 CQRS 的模式。

CQRS（Command Query Responsibility Segregation）是指對于數據的修改、更新操作（Command）和讀取（Query）操作分別使用不同的 Model。這對于普通的 CRUD 業務需求來說只會增加系統復雜度，但是在 Overwatch 這樣復雜查詢、簡單寫入的場景下，是一種非常合適的模式。

由于 Overwatch 的服務端由 Node.js 實現，所以可以完美實現一個事件驅動的、從服務器到瀏覽器的 CQRS 架構。架構設計如下：

Figure 6 CQRS 模式架構圖

顯示器的第三個維度

上文提到了有向圖的問題，即難以展現一個時間軸。顯示器都是二維的，傳統的柱狀圖用一維表示統計值，另一維表示時間，二者形成的坐標點和二維顯示器上的點對應。而有向圖需要展現一個“方向”，節點需要在一個平面內展現，所以顯示器上的兩個維度已經被用完了。為了展示時間維度的信息，我們采用了顯示器的第三個維度——顏色。

我們使用三個同心圓表示一個節點，每個圓的顏色根據該系統所有 RPC 調用的成功率從藍（100%）到黃（<99.9%）到紅（<99%）。最內側的圓表示最近一分鐘的成功率；中間的圓表示最近 5 分鐘的成功率；最外側的圓表示最近 15 分鐘的成功率。通過這三個同心圓，我們就可以直觀了解到該系統當前的狀態以及最近 15 分鐘的變化。

Figure 7 數據節點三色環示意圖

除此之外我們使用節點的大小表示節點最近一分鐘的訪問量，用邊的顏色表示兩個系統之間的 RPC 調用的成功率。

當多個系統同時異常時，通過系統間的依賴關系，我們可以迅速找到異常的根源，也可以評估異常的影響范圍。

在大促期間，一旦 APP 接口開始報警，我們僅需打開 Overwatch 監控頁面，查看有向圖中的異常信息。

Figure 8 異常定位

根據上圖的異常信息（非真實數據），我們可以立刻得知是訂單系統在調用用戶系統時出現了異常，且異常為 ReadTimeout，那么用戶系統就是問題的根源。接下去，我們就可以通過應用日志分析、系統硬件監控等工具對這個系統的異常進行分析以及排查。

優勢：直接

與傳統的調用鏈監控系統，即 Google Dapper 的各種實現系統如淘寶的 EagleEye、推ter 的 Zipkin，或者 APM（Application Performance Management，應用性能管理）工具如 Pinpoint 相比，Overwatch 的設計思想更加“直接”。

使用調用鏈監控系統來進行問題排查，工程師首先需要定位到一個異常的請求，然后需要在一條調用鏈中查找異常，這是非常耗時且繁瑣的工作。

Figure 9 傳統調用鏈監控系統

傳統的調用鏈監控系統是從“請求”的維度進行監控數據的收集和展現，將一個“請求”的完整鏈路展現出來。這樣的監控系統更適合用來作為細致的性能分析和優化工具，并不適合作為一個快速定位異常的工具使用。

而 Overwatch 是從系統的維度進行監控數據的收集和展現，并不關心一個請求的完整鏈路。Overwatch 可以在一張監控圖中完成系統異常的發現和定位，通過有向圖的展示，工程師不需要做任何數據分析，僅憑“感覺”便可確定異常位置。

系統展示

Figure 10 節點信息，包括 5 分鐘、10 分鐘、15 分鐘統計

Figure 11 單系統信息快速展示，包括最近一小時統計圖表以及錯誤日志

Figure 12 單系統歷史信息查詢

Figure 13 有向圖布局設置

未來展望

Overwatch 是一個相對年輕的系統，是一次對大型微服務系統可視化監控現的嘗試。同時，我們也在不斷優化、加強 Overwatch 的功能。Overwatch 有著極大的擴展潛力，我們正在努力實現以下功能：

• 對于數據源、中間件的監控（如 MySQL、Redis、消息隊列），在有向圖中加入基礎組件，全面監控所有系統間的依賴以及調用情況。
• 支持更多 RPC 協議 （如 Thrift、gRPC）。
• 更多的 metric，實現精確到 API 的監控和展現。
• 使用智能算法自動發現異常（如系統訪問量突變）。
• 更多的展現方式（如形狀、動畫）。

我們也對 Overwatch 進行了開源， 目前僅對監控數據的展現部分進行了開源，數據收集以及分析部分由于依賴多種內部基礎設施，暫時沒有開源。接下去的開源計劃：

• 各語言的監控數據收集 Agent（Java、Python 等）
• 各協議、中間件的監控 Agent
• 監控數據收集 Agent 的無感知接入
• 監控數據的多樣化存儲（支持 OpenTSDB 等）

 

 

 

來自：http://www.infoq.com/cn/articles/visualization-microservice-monitoring-system