[[196173]]

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

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

undefined

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

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

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

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

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

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

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

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

undefined

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

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

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

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

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

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

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

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

undefined

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

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

計(jì)算引擎上，小明為了簡(jiǎn)易入手，選擇了一款基于 spark-stream 計(jì)算引擎組件，可以上面直接寫(xiě) SQL 語(yǔ)句進(jìn)行實(shí)時(shí)計(jì)算編排而不需要自己寫(xiě)流式計(jì)算程序。

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

展示門(mén)戶(hù)方面，沒(méi)有直接對(duì)應(yīng)產(chǎn)品。小明撓了撓頭，決定還是只能自己突擊一下前段編程技術(shù)，基于開(kāi)源展示框架來(lái)編寫(xiě)一個(gè)簡(jiǎn)單的查詢(xún)門(mén)戶(hù)。

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

漫漫開(kāi)發(fā)路程

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

集成故障排查成本

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

日志清洗

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

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

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

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

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

報(bào)警

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

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

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

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

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

針對(duì)錯(cuò)誤場(chǎng)景的診斷方法

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

以上問(wèn)題還不包括前段展示的各類(lèi)問(wèn)題。

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

另外一種新的思路

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

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

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

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

undefined

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

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

“聽(tīng)起來(lái)不錯(cuò)，看來(lái)我的項(xiàng)目有救了，我趕緊去看看。”

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

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

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

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

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

 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" 

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

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

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

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

頁(yè)面的 PV, UV

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

頁(yè)面響應(yīng)時(shí)間

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

頁(yè)面流量

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

對(duì)于 Nginx 監(jiān)控，最常見(jiàn)的維度有以下幾類(lèi):

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

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

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

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

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

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

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

• 某類(lèi)頁(yè)面的響應(yīng)時(shí)間過(guò)長(zhǎng)。
• 某類(lèi)頁(yè)面的錯(cuò)誤率頁(yè)面過(guò)高。

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

• 支持某類(lèi)指標(biāo)的維度下鉆遍歷

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

• 支持不同指標(biāo)之間的復(fù)合計(jì)算

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

• 支持各種其他報(bào)警高級(jí)報(bào)警配置

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

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

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

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

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

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

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

5. 馬上快速上手

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

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