基於Storm的Nginx log即時監控系統

【編者按】Hadoop的缺點也和它的優點同樣鮮明——延遲大，回應緩慢，運維複雜。 被人廣受詬病，但是 有需求就有創造，在Hadoop基本奠定了大資料霸主地位的時候，很多的開源專案都是以彌補Hadoop的即時性為目標而被創造出來，Storm正是在這個時候橫空出世，Storm是一個免費開源、分散式、 高容錯的即時計算系統。 Storm令持續不斷的流計算變得容易，彌補了Hadoop批次處理所不能滿足的即時要求。

以下為原文：

背景UAE（UC App Engine）是一個UC內部的PaaS平臺，概念架構有點類似CloudFoundry，包括：


快速部署：支援Node.js、Play!、PHP等框架 資訊透明：運維過程、系統狀態、業務狀況 灰度試錯：IP灰度、地域灰度 基礎服務：key-value存儲、MySQL高可用、圖片平臺等

這裡它不是主角，不作詳細介紹。

有數百個Web應用運行在UAE上，所有的請求都會經過UAE的路由，每天的Nginx access log大小是TB級，如何即時監控每個業務的訪問趨勢、廣告資料、頁面耗時、訪問品質、自訂報表和異常報警？

Hadoop可以滿足統計需求，但秒級的即時性不能滿足；用Spark Streaming又有些大材小用，同時我們也沒有Spark的工程經驗；自寫分散式程式調度比較麻煩並且要考慮擴展、消息流動；

最後我們的技術選型定為Storm：相對輕量、靈活、消息傳遞方便、擴展靈活。

另外，而由於UC的各地集群比較多，跨集群日誌傳輸也會是其中一個比較大的問題。

技術準備 基數計數（Cardinality Counting）

在大資料分散式運算的時候，PV（Page View）可以很方便相加合併，但UV（Unique Visitor）不能。

分散式運算的情況下，幾百個業務、數十萬URL同時統計UV，如果還要分時段統計(每分鐘/每5分鐘合併/每小時合併/每天合併)，記憶體的消耗是不可接受的。

這個時候，概率的力量就體現了出來。 我們在Probabilistic Data Structures for Web Analytics and Data Mining可以看到，精確的雜湊表統計UV和基數計數的記憶體比較，並不是一個數量級的。 基數計數可以讓你實現UV的合併，記憶體消耗極小，並且誤差完全在可接受範圍內。

可以先瞭解LogLog Counting，理解均勻雜湊方法的前提下，粗糙估計的來由即可，後面的公式推導可以跳過。

具體演算法是Adaptive Counting，使用的計算庫是stream-2.7.0.jar。

即時日誌傳輸

即時計算必須依賴于秒級的即時日誌傳輸，附加的好處是可以避免階段性傳輸引起的網路擁堵。

即時日誌傳輸是UAE已有的羽量級的日誌傳輸工具，成熟穩定，直接拿來用了，包括用戶端（mca）和伺服器端（mcs）。

用戶端監聽各個集群的日誌檔的變化，傳輸到指定的Storm集群的各台機器上，存儲為普通日誌檔。

我們調整了傳輸策略，使得每台Storm機器上的日誌檔案大小大致相同，所以Spout唯讀取本機資料即可。

資料來源佇列

我們並沒有用Storm常用的佇列，如Kafka、MetaQ等，主要是太重了...

fqueue是一個輕量的memcached協定佇列，把普通的日誌檔轉為memcached的服務，這樣Storm的Spout就可以直接以memcached協定逐條讀取。

這個資料來源比較簡單，它不支援重新發射（replay），一條記錄被取出之後就不復存在，如果某個tuple處理失敗或超時，則資料丟失。

它比較輕量，基於本地檔讀取，做了一層薄的緩存，並不是一個純記憶體的佇列，它的性能瓶頸在於磁片IO，每秒輸送量跟磁片讀取速度是一致的。 但對於我們這個系統已經足夠，後續有計劃改成純記憶體佇列。

架構

通過上面的技術儲備，我們可以在使用者訪問幾秒後就能獲取到使用者的日誌。

整體架構也比較簡單，之所以有兩種計算bolt，是基於計算的均勻分佈考慮。 業務的量相差極大，如果僅按業務ID去進行fieldsGrouping，計算資源也會不均衡。

spout將每條原始日誌標準化，按照URL分組（fieldsGrouping，為保持每台伺服器計算量的均勻），派發到對應的stat_bolt上； stat_bolt是主要的計算Bolt，將每個業務的URL梳理並計算 ，如PV、UV、總回應時間、後端回應時間、HTTP狀態碼統計、URL排序、流量統計等； merge_bolt將每個業務的資料合併，如PV數，UV數等。 當然，這裡的UV合併就用到了前面提到的基數計數； 自寫了一個簡單的Coordinator協調類，streamId標記為」coordinator」，作用：時間協調（切分batch）、檢查任務完成度、超時處理。 原理跟Storm自帶的Transactional Topolgoy類似。 實現一個Scheduler通過API獲取參數，動態調整Spout、Bolt在各伺服器的分佈，以便靈活分配伺服器資源。 支援平滑升級Topology：當一個Topology升級的時候，新Topology和舊Topology講同時運行，協調切換時間，當新的Topology接管了fqueue之後，過河拆橋，殺死舊的Topology。

注意點：

Storm機器儘量部署在同一個機櫃內，不影響集群內的頻寬； 我們的Nginx日誌是按小時切分的，如果切分的時間不准確，在00分的時候，就可以看到明顯的資料波動，所以，儘量使用Nginx module去切日誌， 用crontab發信號切會有延遲。 切日誌這種10秒級的延遲，在大尺度的統計上沒有問題，秒級的統計時波動卻很明顯； 堆太小會導致woker被強制殺死，所以要配置好-Xmx參數； 自訂項 靜態資源：靜態資源過濾選項， 通過Content-Type或尾碼篩選特定的靜態資源。 資源合併：URL合併，比如RESTful的資源，合併後方便展示； 維度與指標：通過ANTLR v3做語法、詞法分析，完成自訂維度和指標，並且後續的報警也支援自訂表格達式。 其他

我們還用其他方式實現了：

業務的進程級（CPU/MEM/埠）監控 業務依賴的服務，如MySQL/memcached等的監控 伺服器的磁片/記憶體/IO/內核參數/語言環境/環境變數/編譯環境等監控 原文連結：基於Storm的Nginx log即時監控系統 （責編/魏偉）

免費訂閱「CSDN雲計算（左）和CSDN大資料（右）」微信公眾號，即時掌握第一手雲中消息，瞭解最新的大資料進展！

CSDN發佈虛擬化、Docker、OpenStack、CloudStack、資料中心等相關雲計算資訊，     分享Hadoop、Spark、NoSQL/NewSQL、HBase、Impala、記憶體計算、流計算、 機器學習和智慧演算法等相關大資料觀點，提供雲計算和大資料技術、平臺、實踐和產業資訊等服務。