完美世界小说txt下载,盗墓笔记同人小说,小说阅读网

新聞中心

這里有您想知道的互聯(lián)網(wǎng)營銷解決方案

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

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

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

站在用戶的角度思考問題，與客戶深入溝通，找到和田縣網(wǎng)站設(shè)計(jì)與和田縣網(wǎng)站推廣的解決方案，憑借多年的經(jīng)驗(yàn)，讓設(shè)計(jì)與互聯(lián)網(wǎng)技術(shù)結(jié)合，創(chuàng)造個性化、用戶體驗(yàn)好的作品，建站類型包括：成都網(wǎng)站設(shè)計(jì)、成都網(wǎng)站制作、企業(yè)官網(wǎng)、英文網(wǎng)站、手機(jī)端網(wǎng)站、網(wǎng)站推廣、域名申請、網(wǎng)頁空間、企業(yè)郵箱。業(yè)務(wù)覆蓋和田縣地區(qū)。

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

先以應(yīng)用服務(wù)監(jiān)控為抓手，能
- 實(shí)時統(tǒng)計(jì)應(yīng)用各類服務(wù)的調(diào)用次數(shù)
- 基于 a，實(shí)時統(tǒng)計(jì)各類服務(wù)各類返回值的次數(shù)，如 200，404，500，等。
- 基于 b，如果某類返回值調(diào)用超限，進(jìn)行實(shí)時報(bào)警。
提供歷史查詢功能，能返回任意時段任意服務(wù)任意返回值調(diào)用次數(shù)統(tǒng)計(jì)。
以后未來公司各類定制的業(yè)務(wù)監(jiān)控能快速擴(kuò)展到該系統(tǒng)上，如各接口響應(yīng)統(tǒng)計(jì)時間，用戶特征統(tǒng)計(jì)等。

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

技術(shù)選項(xiàng)

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

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

由于公司業(yè)務(wù)規(guī)模不小，白天峰段的平均 QPS 已經(jīng)上百，而且業(yè)務(wù)還在快速增長，因此將每秒上百次調(diào)用信息每次直接存放到數(shù)據(jù)庫中再實(shí)時查詢肯定不合適，成本太高且不適合擴(kuò)展。
阿里云提供搜索引擎服務(wù)，錯誤統(tǒng)計(jì)功能基本能滿足老板需求。但是不確定因素有兩個。一方面搜索引擎價格存儲成本偏高（搜索引擎需要引入索引存儲），而且各類聚合查詢?nèi)缃涌陧憫?yīng)時間統(tǒng)計(jì)等查詢響應(yīng)時間不太好保證，另一方面考慮到實(shí)時報(bào)警還需要編寫 API 不停進(jìn)行各類調(diào)用的錯誤次數(shù)的輪詢，性能和成本都不太確定。
基于實(shí)時計(jì)算的架構(gòu)，可以將線上所有日志通過服務(wù)，返回值錯誤類型，和時間等維度在內(nèi)存中進(jìn)行實(shí)時的聚合計(jì)算，然后再持久化到存儲中。一方面實(shí)時計(jì)算效率高，聚合后的結(jié)果大小會比原始數(shù)據(jù)大大減少，因此持久化成本低，實(shí)時能保證；另一方面還可以在內(nèi)存中實(shí)時校驗(yàn)報(bào)警策略，讓報(bào)警的性能開銷足夠小。

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

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

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

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

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

數(shù)據(jù)通道這塊，小明在阿里云上選取了一款類似于 Kafka 的數(shù)據(jù)通道，在支持性能和消息堆積等特性的同時，在數(shù)據(jù)接入上提供了一定的簡便性。
計(jì)算引擎上，小明為了簡易入手，選擇了一款基于 spark-stream 計(jì)算引擎組件，可以上面直接寫 SQL 語句進(jìn)行實(shí)時計(jì)算編排而不需要自己寫流式計(jì)算程序。
存儲方面，由于沒有太強(qiáng)事物需求，而且在容量上要求較高，小明選擇了一款類似 Hbase 的云上存儲產(chǎn)品。
展示門戶方面，沒有直接對應(yīng)產(chǎn)品。小明撓了撓頭，決定還是只能自己突擊一下前段編程技術(shù)，基于開源展示框架來編寫一個簡單的查詢門戶。

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

漫漫開發(fā)路程

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

集成故障排查成本

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

日志清洗

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

持久化表設(shè)計(jì)

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

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

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

報(bào)警

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

報(bào)警準(zhǔn)確性

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

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

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

針對錯誤場景的診斷方法

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

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

掐指一算，兩個月晃眼過了。項(xiàng)目還沒弄完一半，小明有點(diǎn)急了。

另外一種新的思路

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

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

“噢，是么？我們業(yè)務(wù)的監(jiān)控邏輯很多都是基于 Nginx 日志定制，ARMS 具備接入 Nginx 日志的能力，并允許讓我定制業(yè)務(wù)監(jiān)控能力么？“小明問道。
“當(dāng)然。ARMS 上不僅提供監(jiān)控 Nginx 的任務(wù)模板，本身自帶報(bào)警和監(jiān)控報(bào)表，同時還全程開放定制能力。如果你要增加自己的業(yè)務(wù)監(jiān)控邏輯，或者刪除或修改自己不要的通用監(jiān)控邏輯，直接在其平臺上定制即可?！崩系ご鸬?。

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

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

“聽起來不錯，看來我的項(xiàng)目有救了，我趕緊去看看?！?/p>

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

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

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

ARMS 采用的是實(shí)時計(jì)算+列式存儲。這種方案的優(yōu)勢是數(shù)據(jù)實(shí)時性高，而且對于固定的數(shù)據(jù)查詢接口查詢效率非常塊。在 Nginx 的監(jiān)控方案中，其架構(gòu)概要如下所示, 藍(lán)色部分為 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 上進(jìn)行配置。以下篇幅從 ARMS 數(shù)據(jù)集，報(bào)警，和交互大盤，三個部分進(jìn)行配置概要描述。關(guān)于數(shù)據(jù)源如何添加到ARMS可參見文檔，在此不贅述。

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

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

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

頁面的 PV, UV

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

頁面響應(yīng)時間

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

頁面流量

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

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

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

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

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

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

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

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

常見的 Nginx 報(bào)警有以下幾種:

某類頁面的響應(yīng)時間過長。
某類頁面的錯誤率頁面過高。
使用 ARMS 的原生報(bào)警的一些特性天然支持 Nginx 監(jiān)控報(bào)警的各種場景。以下舉例。
支持某類指標(biāo)的維度下鉆遍歷
例如檢查（遍歷）所有頁面維度的響應(yīng)時間是否超過 100ms.
支持不同指標(biāo)之間的復(fù)合計(jì)算
典型如錯誤碼為 5xx 占總調(diào)用的占比，通過不同指標(biāo)復(fù)合計(jì)算而得。
支持各種其他報(bào)警高級報(bào)警配置
包括最近 N 分鐘同比，環(huán)比，最大，最小值比較，等。例如，最近5分鐘同比PV下跌50%這種典型的場景。

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

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

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

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

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

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

5. 馬上快速上手

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

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

傳送門在此

標(biāo)題名稱：如何快速實(shí)現(xiàn)一個基于Nginx網(wǎng)站的監(jiān)控場景
URL標(biāo)題：http://m.fisionsoft.com.cn/article/djhgghp.html