[[196173]]

一切從應(yīng)用服務(wù)監(jiān)控說起

小明所在的一家小型互聯(lián)網(wǎng)創(chuàng)業(yè)公司一直將應(yīng)用運行在阿里云上。該應(yīng)用采用通用的分布式 Nginx+App 架構(gòu)為用戶提供電商數(shù)據(jù)統(tǒng)計的 webservice 服務(wù)。應(yīng)用運行至今除偶發(fā)各類 Bug，性能問題以外，情況還算良好。

undefined

最近，小明的老板給小明布置了一個任務(wù)，希望把應(yīng)用服務(wù)監(jiān)控起來，以提高應(yīng)用運行質(zhì)量。老板的需求有三點：

1.先以應(yīng)用服務(wù)監(jiān)控為抓手，能

1. 實時統(tǒng)計應(yīng)用各類服務(wù)的調(diào)用次數(shù)
2. 基于 a，實時統(tǒng)計各類服務(wù)各類返回值的次數(shù)，如 200，404，500，等。
3. 基于 b，如果某類返回值調(diào)用超限，進行實時報警。

2.提供歷史查詢功能，能返回任意時段任意服務(wù)任意返回值調(diào)用次數(shù)統(tǒng)計。

3.以后未來公司各類定制的業(yè)務(wù)監(jiān)控能快速擴展到該系統(tǒng)上，如各接口響應(yīng)統(tǒng)計時間，用戶特征統(tǒng)計等。

“方案盡量多快好省，而且搭建的監(jiān)控平臺最好就在阿里云上，數(shù)據(jù)不要外放在第三方云上，主要是為了公網(wǎng)流量成本和以后大數(shù)據(jù)分析作準備”，老板最后提到。

技術(shù)選項

小明接到任務(wù)以后開始著手進行技術(shù)選型。擺在他面前貌似可行的有三個選擇，傳統(tǒng) OLAP 式處理方式，搜索引擎，以及實時計算方式。

undefined

在調(diào)研現(xiàn)狀和眾多技術(shù)后，他發(fā)現(xiàn)，

由于公司業(yè)務(wù)規(guī)模不小，白天峰段的平均 QPS 已經(jīng)上百，而且業(yè)務(wù)還在快速增長，因此將每秒上百次調(diào)用信息每次直接存放到數(shù)據(jù)庫中再實時查詢肯定不合適，成本太高且不適合擴展。

阿里云提供搜索引擎服務(wù)，錯誤統(tǒng)計功能基本能滿足老板需求。但是不確定因素有兩個。一方面搜索引擎價格存儲成本偏高(搜索引擎需要引入索引存儲)，而且各類聚合查詢?nèi)缃涌陧憫?yīng)時間統(tǒng)計等查詢響應(yīng)時間不太好保證，另一方面考慮到實時報警還需要編寫 API 不停進行各類調(diào)用的錯誤次數(shù)的輪詢，性能和成本都不太確定。

基于實時計算的架構(gòu)，可以將線上所有日志通過服務(wù)，返回值錯誤類型，和時間等維度在內(nèi)存中進行實時的聚合計算，然后再持久化到存儲中。一方面實時計算效率高，聚合后的結(jié)果大小會比原始數(shù)據(jù)大大減少，因此持久化成本低，實時能保證;另一方面還可以在內(nèi)存中實時校驗報警策略，讓報警的性能開銷足夠小。

綜上考慮，基于實時計算的架構(gòu)看來最能滿足當前公司的需求。決定了以后，小明開始思考進一步架構(gòu)設(shè)計。

架構(gòu)設(shè)計

決定了基于實時計算的技術(shù)以后，小明開始進行架構(gòu)設(shè)計。通過參考各類技術(shù)網(wǎng)站，他發(fā)現(xiàn)要架構(gòu)一個靠譜的網(wǎng)站監(jiān)控方案，需要的組件以下缺一不可。

• 數(shù)據(jù)通道：負責將數(shù)據(jù)從 Nginx 拉取出來，傳送到搜索引擎。數(shù)據(jù)通道同時肩負數(shù)據(jù)堆積和數(shù)據(jù)重算的任務(wù)。
• 計算引擎：基于 Nginx 服務(wù)，錯誤碼，時間的維度的聚合實時計算邏輯需要基于選定的引擎進行編寫。計算引擎最好能同時負責一些報警的邏輯。
• 存儲：存放最終 Nginx 監(jiān)控結(jié)果的地方?？紤]到監(jiān)控結(jié)果雖然表結(jié)構(gòu)簡單，但是各種維度查詢比較多，最好是類似于 OLAP 的存儲類型。
• 展示門戶：針對所有 Nginx 監(jiān)控結(jié)果作各類維度的快速分析和展示。

undefined

好在針對前三個組件，阿里云提供了一些現(xiàn)成的產(chǎn)品組件，小明不需要自己手動一個個去搭建，因此入門門檻還不算高。

數(shù)據(jù)通道這塊，小明在阿里云上選取了一款類似于 Kafka 的數(shù)據(jù)通道，在支持性能和消息堆積等特性的同時，在數(shù)據(jù)接入上提供了一定的簡便性。

計算引擎上，小明為了簡易入手，選擇了一款基于 spark-stream 計算引擎組件，可以上面直接寫 SQL 語句進行實時計算編排而不需要自己寫流式計算程序。

存儲方面，由于沒有太強事物需求，而且在容量上要求較高，小明選擇了一款類似 Hbase 的云上存儲產(chǎn)品。

展示門戶方面，沒有直接對應(yīng)產(chǎn)品。小明撓了撓頭，決定還是只能自己突擊一下前段編程技術(shù)，基于開源展示框架來編寫一個簡單的查詢門戶。

跟老板申請了預(yù)算以后，小明開始陸續(xù)開通各類產(chǎn)品進行開發(fā)測試。預(yù)計一個月完成任務(wù)，

漫漫開發(fā)路程

開通流程很簡單?；税胩觳坏?，kafka、storm、hbase 的租戶集群到手?？上СＱ缘溃_發(fā)項目 80% 的時間花費在最終 20% 的坑上。項目過了一個月，但是功能尚未完成 70%。小明在自己的技術(shù)博客上默默的記錄下以下踩過的坑。

集成故障排查成本

由于需要集成的組件包括數(shù)據(jù)通道，實時計算層，后臺存儲，并在代碼中集成推送數(shù)據(jù)邏輯以及報警查詢邏輯。每個環(huán)節(jié)稍有出錯將造成整個鏈路阻塞，調(diào)試成本顯得非常高。

日志清洗

開發(fā)期間為了獲取到相關(guān)應(yīng)用為了調(diào)整對于日志的推送邏輯，需要在每臺 Nginx 日志內(nèi)容變更以后再在每個服務(wù)端變更 API 的推送邏輯，變更過程冗長且容易出錯。

持久化表設(shè)計

除了要針對監(jiān)控項做出適合的表庫設(shè)計，并盡量避免索引熱點以外，還需要考慮當數(shù)據(jù)結(jié)果由于實時計算層不穩(wěn)定重復(fù)計算時如何保證數(shù)據(jù)庫寫入冪等性，這對表結(jié)構(gòu)設(shè)計是一個不小的挑戰(zhàn)。

延遲數(shù)據(jù)合并

如果由于應(yīng)用原因?qū)е?Nginx 日志數(shù)據(jù)被延遲發(fā)送，如何保證比如晚到 1 個小時的數(shù)據(jù)能被實時計算引擎準確計算并將結(jié)果合并到之前的結(jié)果。

報警

針對所有結(jié)果需要設(shè)置定時任務(wù)每分鐘對數(shù)據(jù)進行遍歷查詢。比如針對任何返回 500 調(diào)用錯誤超過 5% 占比的服務(wù)，需要所有服務(wù)進行多次的調(diào)用結(jié)果進行遍歷查詢。如何不遺漏所有的服務(wù)錯誤檢查的同時保證高效率查詢也是個不小的挑戰(zhàn)。

報警準確性

有的時候由于日志延遲，上一分鐘部分服務(wù)器正常日志還沒采集全，導致局部 500 調(diào)用錯誤的服務(wù)暫時超過 5%，類似錯誤是否需要報警?如果報警，有可能誤報，不報警的話，可能漏報，怎么處理呢?

如何統(tǒng)計 UV、TopN

以 UV 為例。如果要跨任意時間度查詢 UV，則常規(guī)手段還需要在數(shù)據(jù)庫中存入每單位時間(如分鐘級別)的全量 IP 訪問信息。這對于存儲利用率來講顯然是無法接受的。有沒有更優(yōu)化的方案?

針對錯誤場景的診斷方法

針對各類返回值 500 的調(diào)用錯誤，業(yè)務(wù)方提出希望出現(xiàn) 500 錯誤時能根據(jù)時間和調(diào)用服務(wù)維度查詢到詳細的調(diào)用入?yún)⒑推渌斍?，其場景和日志搜索類似。對于類似新加入需求，貌似通過實時聚合計算和存儲不能直接辦到。需要對日志另辟蹊徑另行處理。

以上問題還不包括前段展示的各類問題。

掐指一算，兩個月晃眼過了。項目還沒弄完一半，小明有點急了。

另外一種新的思路

小明晚上約了自己的同門師兄老丹搓串。就著小酒，小明把自己最近的煩心事從頭到尾跟老丹說了一遍。

老丹聽了一拍大腿：“小明，你這就奧特了。其實在阿里云上有一款云產(chǎn)品, 叫做業(yè)務(wù)實時監(jiān)控，簡稱 ARMS，基本上你遇到的這些問題，在 ARMS 上已經(jīng)提供了一站式的解決方案，你只需要快速接入即可。”。

“噢，是么?我們業(yè)務(wù)的監(jiān)控邏輯很多都是基于 Nginx 日志定制，ARMS 具備接入 Nginx 日志的能力，并允許讓我定制業(yè)務(wù)監(jiān)控能力么?“小明問道。

“當然。ARMS 上不僅提供監(jiān)控 Nginx 的任務(wù)模板，本身自帶報警和監(jiān)控報表，同時還全程開放定制能力。如果你要增加自己的業(yè)務(wù)監(jiān)控邏輯，或者刪除或修改自己不要的通用監(jiān)控邏輯，直接在其平臺上定制即可。”老丹答道。

undefined

“聽起來不錯。最終結(jié)果除了報表和報警外，公司的下游業(yè)務(wù)平臺也能用么?”

“可以的，ARMS 提供 API, 下游系統(tǒng)直接對接數(shù)據(jù) API 即可，跟你在云上直接讀數(shù)據(jù)庫沒什么本質(zhì)區(qū)別。”

“聽起來不錯，看來我的項目有救了，我趕緊去看看。”

實現(xiàn)一個基于 Nginx 的網(wǎng)站監(jiān)控場景

1. ARMS 的 Nginx 監(jiān)控方案概述和準備

目前在監(jiān)控領(lǐng)域上比較流行的數(shù)據(jù)處理方法有很多種，例如，搜索引擎，時間序列數(shù)據(jù)庫，實時計算，甚至是大數(shù)據(jù)離線計算，等。

ARMS 采用的是實時計算+列式存儲。這種方案的優(yōu)勢是數(shù)據(jù)實時性高，而且對于固定的數(shù)據(jù)查詢接口查詢效率非常塊。在 Nginx 的監(jiān)控方案中，其架構(gòu)概要如下所示, 藍色部分為 ARMS 所集成的 Nginx 監(jiān)控開箱即用的黑盒。

由于 ARMS 的分析是針對 Nginx 的 access.log 日志，因此對 Nginx 日志有一定要求，需要用戶在 nginx.config 中配置出打印內(nèi)容，包括：“$upstream_response_time” “$request_time” 等代表請求消耗時間的日志信息。如下例：

 log_format   main '$remote_addr - $remote_user [$time_local]  $status ' 
'"$request" $body_bytes_sent "$http_referer" ' 
'"$http_user_agent" "$http_x_forwarded_for"' 
'"$upstream_response_time" "$request_time" "$ user_cookie_id"' ;   

這樣的話，打印出的日志，大致如下表所示。

58.211.119.29 144288 - [16/Mar/2017:21:47:07 +0800] "POST http://arms.console.aliyun.com/api/query.json?action=DataQueryAction&eventSubmitDoQueryData=1" 200 594 "https://arms.console.aliyun.com/" "127.0.0.1:8080" "Mozilla/5.0 (Windows NT 5.1) AppleWebKit/537.4 (KHTML, like Gecko) Chrome/22.0.1229.79 Safari/537.4" "0.144" "0.144" "EX866MB1-Y70JO57WM37ST3HWDVFK3-JWPNH30J-Z" 
58.211.119.29 148219 - [16/Mar/2017:21:47:08 +0800] "POST http://arms.console.aliyun.com/api/query.json?action=DataQueryAction&eventSubmitDoQueryData=1" 200 583 "https://arms.console.aliyun.com/" "127.0.0.1:8080" "Mozilla/5.0 (Windows NT 5.1) AppleWebKit/537.4 (KHTML, like Gecko) Chrome/22.0.1229.79 Safari/537.4" "0.148" "0.148" "EX866MB1-Y70JO57WM37ST3HWDVFK3-JWPNH30J-Z" 

完成上述日志配置定制以后，即可開始在 ARMS 上進行配置。以下篇幅從 ARMS 數(shù)據(jù)集，報警，和交互大盤，三個部分進行配置概要描述。關(guān)于數(shù)據(jù)源如何添加到ARMS可參見文檔，在此不贅述。

2. 基于 ARMS 的 Nginx 監(jiān)控 數(shù)據(jù)集實現(xiàn)

在 Nginx 監(jiān)控模板中，用戶數(shù)據(jù)分為兩類，一類是指標，相當于數(shù)據(jù)倉庫中的 Measure;一類是維度，相當于數(shù)據(jù)倉庫中的 Dimension。

對于Nginx監(jiān)控，最常見的指標為以下幾類指標:

頁面的 PV, UV

• PV: 頁面的 PV 通過對 access.log 中的每一條日志做 coun t來統(tǒng)計，
• UV: 通過日志中代表用戶 ID 的對應(yīng)的 $cookie_id 來做 count distinct 來統(tǒng)計。對應(yīng)的 cookie_id 需要開發(fā)人員進行手動統(tǒng)計。

頁面響應(yīng)時間

• 平均頁面響應(yīng)時間: 在 ARMS 中通過對$request_time做sum操作來統(tǒng)計出total_request_time，然后在通國際 total_request_time / pv 來得到某維度下的瓶平均響應(yīng)時間。
• 最大響應(yīng)時間: 則對單條日志 request_time 進行 max 統(tǒng)計。

頁面流量

• 平均頁面流量和最大頁面流量：針對 $body_bytes_sent 來進行統(tǒng)計。統(tǒng)計方式和頁面響應(yīng)時間類似，不贅述。

對于 Nginx 監(jiān)控，最常見的維度有以下幾類:

• 頁面 URL: $request。用戶可以針對特定 URL 進行訪問統(tǒng)計，甚至可以在不同 URL 之間進行訪問排行。
• 頁面返回狀態(tài)：$status。用戶可以針對不同的返回值維度進行統(tǒng)計，如僅統(tǒng)計 200 返回值的正常頁面訪問情況，或是非 200 返回值的錯誤頁面訪問情況。
• 瀏覽器類型：根據(jù) $http_user_agent 統(tǒng)計出的用戶的瀏覽器客戶端，如 Chrome, Sofari, IE, Firefox, 甚至 Curl 命令，等。用戶可以根據(jù)此類維度統(tǒng)計客戶端的分布情況。
• 用戶 ID：根據(jù) $cook_id 統(tǒng)計出的用戶的使用習慣，如哪一類頁面被哪一些用戶經(jīng)常訪問，等。

對于 ARMS 的數(shù)據(jù)集設(shè)計，其實就是針對用戶感興趣的 Nginx 監(jiān)控結(jié)果，進行各類維度的排列組合。

• 例如，以頁面URL維度，統(tǒng)計 UV, PV，頁面響應(yīng)時間，則可以統(tǒng)計出不同頁面的各自的UV, PV和頁面響應(yīng)時間，甚至根據(jù)例如PV進行TopN排行。

下圖是一個數(shù)據(jù)集配置的例子，該數(shù)據(jù)集配置出兩個維度: URL 和 Status (支持由 URL 下鉆到 Status 的查詢方式)，分別統(tǒng)計兩個指標：PV 和 UV。這樣用戶可以依次下鉆頁面路徑和返回值來查詢 PV, UV 情況。

下圖是另個數(shù)據(jù)集配置的例子，該數(shù)據(jù)集配置出和上例相同但是順序相反的兩個維度: Status 和 URL (支持由 Status下鉆到 URL 的查詢方式)，分別統(tǒng)計兩個指標：PV，平均響應(yīng)時間，最高響應(yīng)時間 。其中，平均調(diào)用時間是復(fù)合指標，由總體調(diào)用時間 / PV 間接得出。

3. 基于 ARMS 的 Nginx 監(jiān)控報警實現(xiàn)

常見的 Nginx 報警有以下幾種:

• 某類頁面的響應(yīng)時間過長。
• 某類頁面的錯誤率頁面過高。

使用 ARMS 的原生報警的一些特性天然支持 Nginx 監(jiān)控報警的各種場景。以下舉例。

• 支持某類指標的維度下鉆遍歷

例如檢查(遍歷)所有頁面維度的響應(yīng)時間是否超過 100ms.

• 支持不同指標之間的復(fù)合計算

典型如錯誤碼為 5xx 占總調(diào)用的占比，通過不同指標復(fù)合計算而得。

• 支持各種其他報警高級報警配置

包括最近 N 分鐘同比，環(huán)比，最大，最小值比較，等。例如，最近5分鐘同比PV下跌50%這種典型的場景。

以下例子結(jié)合以上三個特點，介紹了一種如何在 ARMS 定義”任意 URL 調(diào)用一分鐘 500 返回占比超過 10%”的報警定義例子，如下所示。

4. 基于 ARMS 的 Nginx 監(jiān)控大盤配置

監(jiān)控大盤一般有以下幾個用途：

• 掛在作戰(zhàn)室，全面掌控運行狀態(tài)。
• 用于實時查看，并下鉆分析每個具體用戶或網(wǎng)頁的網(wǎng)站實際使用情況。

針對 Nginx 監(jiān)控，ARMS 可以基于類似用戶維度，頁面維度，IP 維度，甚至地域維度，展示不同的數(shù)據(jù)。以展示用戶總體UV, PV 為例，假設(shè)對應(yīng)的數(shù)據(jù)集為”整站 UV PV”，則配置如下：

集成各類 UV, PV，響應(yīng)時間等統(tǒng)計的最終交互式大盤效果圖如下：

5. 馬上快速上手

以上各類 Nginx 監(jiān)控場景，目前在 ARMS 上已有成熟商業(yè)模板支持，用戶只需要在 ARMS 首頁點擊 “新建標準模板監(jiān)控”，并選擇 Nginx 高級模板，即可。

想了解更多關(guān)于分布式監(jiān)控方面的信息，請參加線上舉辦的首屆阿里巴巴中間件技術(shù)峰會，揭秘阿里10年分布式技術(shù)沉淀!阿里高可用體系核心締造者、全鏈路壓測創(chuàng)始人，DRDS 與 TDDL 負責人等大咖出場，干貨分享，不可錯過!