小明所在的一家小型網際網路創業公司一直将應用運作在國内某a雲上。該應用采用通用的分布式nginx+app架構為使用者提供電商資料統計的webservice 服務。應用運作至今除偶發各類bug, 性能問題以外，情況還算良好。
最近，小明的老闆給小明布置了一個任務，希望把應用服務監控起來，以提高應用運作品質。老闆的需求有三點：
1. 先以應用服務監控為抓手，能
a) 實時統計應用各類服務的調用次數
b) 基于a，實時統計各類服務各類傳回值的次數，如200，404，500，等。
c) 基于b，如果某類傳回值調用超限，進行實時報警。
2. 提供曆史查詢功能，能傳回任意時段任意服務任意傳回值調用次數統計。
3. 以後未來公司各類定制的業務監控能快速擴充到該系統上，如各接口響應統計時間，使用者特征統計，等。
“方案盡量多快好省，而且搭建的監控平台最好就在a雲上，資料不要外放在第三方雲上，主要是為了公網流量成本和以後大資料分析作準備”，老闆最後提到。
小明接到任務以後開始着手進行技術選型。擺在他面前貌似可行的有三個選擇，傳統olap式處理方式，搜尋引擎，以及實時計算方式。
在調研現狀和衆多技術後，他發現，
1. 由于公司業務規模不小，白天峰段的平均qps已經上百，而且業務還在快速增長，是以将每秒上百次調用資訊每次直接存放到資料庫中再實時查詢肯定不合适，成本太高且不适合擴充。
2. a雲提供搜尋引擎服務，錯誤統計功能基本能滿足老闆需求。但是不确定因素有兩個。一方面搜尋引擎價格存儲成本偏高(搜尋引擎需要引入索引存儲)，而且各類聚合查詢如接口響應時間統計等查詢響應時間不太好保證，另一方面考慮到實時報警還需要編寫api不停進行各類調用的錯誤次數的輪詢，性能和成本都不太确定。
3. 基于實時計算的架構，可以将線上所有日志通過服務，傳回值錯誤類型，和時間等次元在記憶體中進行實時的聚合計算，然後再持久化到存儲中。一方面實時計算效率高，聚合後的結果大小會比原始資料大大減少，是以持久化成本低，實時能保證；另一方面還可以在記憶體中實時校驗報警政策，讓報警的性能開銷足夠小。
綜上考慮，基于實時計算的架構看來最能滿足目前公司的需求。決定了以後，小明開始思考進一步架構設計。
決定了基于實時計算的技術以後，小明開始進行架構設計。通過參考各類技術網站，他發現要架構一個靠譜的網站監控方案，需要的元件以下缺一不可。
資料通道：負責将資料從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監控任務。
<a href="https://www.aliyun.com/aliware">企業級網際網路架構aliware</a>
為企業提供穩定、高效、易擴充的中間件産品~