背景

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

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

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

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

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

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

Overwatch 監(jiān)控系統(tǒng)

簡介

Overwatch 是一個遠程調用監(jiān)控系統(tǒng)，通過對系統(tǒng)調用外部系統(tǒng)的監(jiān)控，并以可視化圖形的方式展現(xiàn)，實現(xiàn)對大型微服務系統(tǒng)可用性的監(jiān)控。

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

Figure 1 Overwatch 主界面截圖

數(shù)據(jù)采集

為了能夠發(fā)現(xiàn) RPC 調用失敗的所有情況（包括業(yè)務問題、系統(tǒng)問題、網(wǎng)絡問題），我們討論如下兩種監(jiān)控方案：

1、從服務提供方監(jiān)控

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

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

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

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

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

2、從服務消費方監(jiān)控

從服務消費方可以實現(xiàn)上述“客觀”的監(jiān)控。

Figure 3 從服務消費方監(jiān)控

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

數(shù)據(jù)展現(xiàn)

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

Figure 4 傳統(tǒng)監(jiān)控圖表

這樣的信息展現(xiàn)顯然不能滿足我們的需求，Overwatch 在信息的展現(xiàn)方式上需要作出改變，我們采用了有向圖的方式展現(xiàn)監(jiān)控數(shù)據(jù)。有向圖展現(xiàn) RPC 監(jiān)控數(shù)據(jù)有如下優(yōu)點：

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

Figure 5 有向圖概念示意圖

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

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

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

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

Figure 6 CQRS 模式架構圖

顯示器的第三個維度

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

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

Figure 7 數(shù)據(jù)節(jié)點三色環(huán)示意圖

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

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

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

Figure 8 異常定位

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

優(yōu)勢：直接

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

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

Figure 9 傳統(tǒng)調用鏈監(jiān)控系統(tǒng)

傳統(tǒng)的調用鏈監(jiān)控系統(tǒng)是從“請求”的維度進行監(jiān)控數(shù)據(jù)的收集和展現(xiàn)，將一個“請求”的完整鏈路展現(xiàn)出來。這樣的監(jiān)控系統(tǒng)更適合用來作為細致的性能分析和優(yōu)化工具，并不適合作為一個快速定位異常的工具使用。

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

系統(tǒng)展示

Figure 10 節(jié)點信息，包括 5 分鐘、10 分鐘、15 分鐘統(tǒng)計

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

Figure 12 單系統(tǒng)歷史信息查詢

Figure 13 有向圖布局設置

未來展望

Overwatch 是一個相對年輕的系統(tǒng)，是一次對大型微服務系統(tǒng)可視化監(jiān)控現(xiàn)的嘗試。同時，我們也在不斷優(yōu)化、加強 Overwatch 的功能。Overwatch 有著極大的擴展?jié)摿�，我們正在努力實現(xiàn)以下功能：

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

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

• 各語言的監(jiān)控數(shù)據(jù)收集 Agent（Java、Python 等）
• 各協(xié)議、中間件的監(jiān)控 Agent
• 監(jiān)控數(shù)據(jù)收集 Agent 的無感知接入
• 監(jiān)控數(shù)據(jù)的多樣化存儲（支持 OpenTSDB 等）

 

 

 

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

 

標簽： Google linux Mysql 代碼 服務器 數(shù)據(jù)分析 數(shù)據(jù)庫 網(wǎng)絡

版權申明：本站文章部分自網(wǎng)絡，如有侵權，請聯(lián)系：west999com@outlook.com
特別注意：本站所有轉載文章言論不代表本站觀點！
本站所提供的圖片等素材，版權歸原作者所有，如需使用，請與原作者聯(lián)系。