背景

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

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

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

在沒有 Overwatch 之前，每當(dāng)線上系統(tǒng)出現(xiàn)報(bào)警，我們的工程師都要登上相應(yīng)系統(tǒng)的某臺(tái)機(jī)器查看日志。然而這樣的工作收效甚微，因?yàn)榭赡艹霈F(xiàn)問題的原因真的有很多：

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

為了達(dá)到京東商城對(duì)配送時(shí)效的高標(biāo)準(zhǔn)，我們必須快速響應(yīng)、定位并解決系統(tǒng)故障。通過 Overwatch 系統(tǒng)，我們便可以做到這一點(diǎn)。

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

簡(jiǎn)介

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

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

Figure 1 Overwatch 主界面截圖

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

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

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

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

Figure 2 日志收集 - 分析架構(gòu)圖

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

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

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

2、從服務(wù)消費(fèi)方監(jiān)控

從服務(wù)消費(fèi)方可以實(shí)現(xiàn)上述“客觀”的監(jiān)控。

Figure 3 從服務(wù)消費(fèi)方監(jiān)控

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

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

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

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

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

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

Figure 5 有向圖概念示意圖

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

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

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

由于 Overwatch 的服務(wù)端由 Node.js 實(shí)現(xiàn)，所以可以完美實(shí)現(xiàn)一個(gè)事件驅(qū)動(dòng)的、從服務(wù)器到瀏覽器的 CQRS 架構(gòu)。架構(gòu)設(shè)計(jì)如下：

Figure 6 CQRS 模式架構(gòu)圖

顯示器的第三個(gè)維度

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

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

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

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

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

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

Figure 8 異常定位

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

優(yōu)勢(shì)：直接

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

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

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

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

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

系統(tǒng)展示

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

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

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

Figure 13 有向圖布局設(shè)置

未來展望

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

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

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

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

 

 

 

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

 

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

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