摘要： 最近，小明的老闆給小明佈置了一個任務，希望把應用服務監控起來，以提高應用運行質量。小明接到任務以後開始着手進行技術選型。 趕緊來看看，小明如何通過另外一種新的思路快速搭建Nginx監控任務。
一切從應用服務監控說起
小明所在的一家小型互聯網創業公司一直將應用運行在國內某A雲上。該應用採用通用的分佈式Nginx+App架構爲用戶提供電商數據統計的webservice 服務。應用運行至今除偶發各類Bug, 性能問題以外，情況還算良好。
最近，小明的老闆給小明佈置了一個任務，希望把應用服務監控起來，以提高應用運行質量。老闆的需求有三點：
- 先以應用服務監控爲抓手，能
a) 實時統計應用各類服務的調用次數
b) 基於a，實時統計各類服務各類返回值的次數，如200，404，500，等。
c) 基於b，如果某類返回值調用超限，進行實時報警。
-
提供歷史查詢功能，能返回任意時段任意服務任意返回值調用次數統計。
-
以後未來公司各類定製的業務監控能快速擴展到該系統上，如各接口響應統計時間，用戶特徵統計，等。
“方案儘量多快好省，而且搭建的監控平臺最好就在A雲上，數據不要外放在第三方雲上，主要是爲了公網流量成本和以後大數據分析作準備”，老闆最後提到。
技術選項
小明接到任務以後開始着手進行技術選型。擺在他面前貌似可行的有三個選擇，傳統OLAP式處理方式，搜索引擎，以及實時計算方式。
在調研現狀和衆多技術後，他發現，
-
由於公司業務規模不小，白天峯段的平均qps已經上百，而且業務還在快速增長，因此將每秒上百次調用信息每次直接存放到數據庫中再實時查詢肯定不合適，成本太高且不適合擴展。
-
A雲提供搜索引擎服務，錯誤統計功能基本能滿足老闆需求。但是不確定因素有兩個。一方面搜索引擎價格存儲成本偏高(搜索引擎需要引入索引存儲)，而且各類聚合查詢如接口響應時間統計等查詢響應時間不太好保證，另一方面考慮到實時報警還需要編寫API不停進行各類調用的錯誤次數的輪詢，性能和成本都不太確定。
-
基於實時計算的架構，可以將線上所有日誌通過服務，返回值錯誤類型，和時間等維度在內存中進行實時的聚合計算，然後再持久化到存儲中。一方面實時計算效率高，聚合後的結果大小會比原始數據大大減少，因此持久化成本低，實時能保證；另一方面還可以在內存中實時校驗報警策略，讓報警的性能開銷足夠小。
綜上考慮，基於實時計算的架構看來最能滿足當前公司的需求。決定了以後，小明開始思考進一步架構設計。
架構設計
決定了基於實時計算的技術以後，小明開始進行架構設計。通過參考各類技術網站，他發現要架構一個靠譜的網站監控方案，需要的組件以下缺一不可。
- 數據通道：負責將數據從Nginx拉取出來，傳送到搜索引擎。數據通道同時肩負數據堆積和數據重算的任務。
- 計算引擎：基於Nginx服務，錯誤碼，時間的維度的聚合實時計算邏輯需要基於選定的引擎進行編寫。計算引擎最好能同時負責一些報警的邏輯。
- 存儲：存放最終Nginx監控結果的地方。考慮到監控結果雖然表結構簡單，但是各種維度查詢比較多，最好是類似於OLAP的存儲類型。
- 展示門戶：針對所有Nginx監控結果作各類維度的快速分析和展示。
好在針對前三個組件，A雲提供了一些現成的產品組件，小明不需要自己手動一個個去搭建，因此入門門檻還不算高。
- 數據通道這塊，小明在阿里雲上選取了一款類似於Kafka的數據通道，在支持性能和消息堆積等特性的同時，在數據接入上提供了一定的簡便性。
- 計算引擎上，小明爲了簡易入手，選擇了一款基於spark-stream計算引擎組件，可以上面直接寫SQL語句進行實時計算編排而不需要自己寫流式計算程序。
- 存儲方面，由於沒有太強事物需求，而且在容量上要求較高，小明選擇了一款類似Hbase的雲上存儲產品。
- 展示門戶方面，沒有直接對應產品。小明撓了撓頭，決定還是隻能自己突擊一下前段編程技術，基於開源展示框架來編寫一個簡單的查詢門戶。
跟老闆申請了預算以後，小明開始陸續開通各類產品進行開發測試。預計一個月完成任務，
漫漫開發路程
開通流程很簡單。花了半天不到，kafka, storm, hbase的租戶集羣到手。可惜常言道，開發項目80%的時間花費在最終20%的坑上。項目過了一個月，但是功能尚未完成70%。小明在自己的技術博客上默默的記錄下以下踩過的坑。
-
集成故障排查成本
由於需要集成的組件包括數據通道，實時計算層，後臺存儲，並在代碼中集成推送數據邏輯以及報警查詢邏輯。每個環節稍有出錯將造成整個鏈路阻塞，調試成本顯得非常高。 -
日誌清洗
開發期間爲了獲取到相關應用爲了調整對於日誌的推送邏輯，需要在每臺Nginx日誌內容變更以後再在每個服務端變更API的推送邏輯，變更過程冗長且容易出錯。 -
持久化表設計
除了要針對監控項做出適合的表庫設計，並儘量避免索引熱點以外，還需要考慮當數據結果由於實時計算層不穩定重複計算時如何保證數據庫寫入冪等性，這對錶結構設計是一個不小的挑戰 -
延遲數據合併
如果由於應用原因導致Nginx日誌數據被延遲發送，如何保證比如晚到1個小時的數據能被實時計算引擎準確計算並將結果合併到之前的結果。 -
報警
針對所有結果需要設置定時任務每分鐘對數據進行遍歷查詢。比如針對任何返回500調用錯誤超過5%佔比的服務，需要所有服務進行多次的調用結果進行遍歷查詢。如何不遺漏所有的服務錯誤檢查的同時保證高效率查詢也是個不小的挑戰。 -
報警準確性
有的時候由於日誌延遲，上一分鐘部分服務器正常日誌還沒采集全，導致局部500調用錯誤的服務暫時超過5%，類似錯誤是否需要報警？如果報警，有可能誤報，不報警的話，可能漏報，怎麼處理呢？ -
如何統計UV, TopN
以UV爲例。如果要跨任意時間度查詢UV，則常規手段還需要在數據庫中存入每單位時間(如分鐘級別)的全量IP訪問信息。這對於存儲利用率來講顯然是無法接受的。有沒有更優化的方案？
針對錯誤場景的診斷方法
針對各類返回值500的調用錯誤，業務方提出希望出現500錯誤時能根據時間和調用服務維度查詢到詳細的調用入參和其他詳情，其場景和日誌搜索類似。對於類似新加入需求，貌似通過實時聚合計算和存儲不能直接辦到。需要對日誌另闢蹊徑另行處理。
以上問題還不包括前段展示的各類問題。
掐指一算，兩個月晃眼過了。項目還沒弄完一半，小明有點急了。
另外一種新的思路
小明晚上約了自己的同門師兄老丹搓串。就着小酒，小明把自己最近的煩心事從頭到尾跟老丹說了一遍。
老丹聽了一拍大腿：“小明，你這就奧特了。其實在阿里雲上有一款雲產品, 叫做業務實時監控，簡稱ARMS，基本上你遇到的這些問題，在ARMS上已經提供了一站式的解決方案，你只需要快速接入即可。”。
“噢，是麼？我們業務的監控邏輯很多都是基於Nginx日誌定製，ARMS具備接入Nginx日誌的能力，並允許讓我定製業務監控能力麼？“小明問道。
“當然。ARMS上不僅提供監控Nginx的任務模板，本身自帶報警和監控報表，同時還全程開放定製能力。如果你要增加自己的業務監控邏輯，或者刪除或修改自己不要的通用監控邏輯，直接在其平臺上定製即可。”老丹答道。
“聽起來不錯。最終結果除了報表和報警外，公司的下游業務平臺也能用麼？”
“可以的，ARMS提供API, 下游系統直接對接數據API即可，跟你在雲上直接讀數據庫沒什麼本質區別。”
“聽起來不錯，看來我的項目有救了，我趕緊去看看。”
趕緊來看看吧，看如何使用ARMS快速搭建Nginx監控任務。
詳情請見：https://help.aliyun.com/document_detail/51476.html
ARMS產品詳情：https://www.aliyun.com/product/arms
立即登錄ARMS控制檯：arms.console.aliyun.com