2018年02月25日 08:55:26 朋好友5 閱讀數：634 標籤： 大數據日誌分析系統 更多
首先說：技術爲了需求而服務，公司的需求就是進行日誌分析。
公司現狀：CDN公司（可以百度一下），邊緣節點服務器會產生很多用戶請求日誌，要對日誌進行各種分析和原始日誌打包，最終分析結果進行收費、讓客戶可以獲取請求日誌各種分析結果、爲客戶進行原始日誌按域名按天按小時分割打包。
先說滿足這樣的大數據實時計算需要的幾個基本組件（一定要注意版本問題，java大數據機器間通信用的是RPC 而不是restful_api,如果版本不對應很可能出現版本間的兼容問題）：
1.日誌收集 -從CDN邊緣節點服務器進行日誌收集
2.日誌緩存 -收集上來的日誌存儲到一個緩存設備
3.數據計算 -對收集的日誌進行計算，域名請求數分析、地區統計等等
4.計算結果存儲 -對各種分析結果進行存儲，要方便查找
5.日誌打包結果存儲
首先說公司剛開始的日誌系統分佈：
logstash-forward (邊緣節點日誌收集，上傳到有logstash的機器) -》
kafka 強大的數據緩存組建 （由logstash收集日誌到kafka） -》
elasticsearch (分佈式、可擴展、實時的搜索與數據分析引擎) (用logstash從kafka取出數據存到es) ->
spark（大規模數據計算引擎，從es取出原始日誌然後通過spark計算結果） -》
elasticsearch （進行計算結果數據存儲），hadoop（原始日誌打包存儲） -》
nginx + django服務 進行反向代理、負載均衡、地址隱藏 django進行界面展示-》
可客戶直接訪問觀看
說一下版本（zookeeper 3.4.7 kafka_2.11-0.8.2.1 logstash-2.2.2 elasticsearch-2.4.6 hadoop-2.6.4 spark-1.6.1）
現在這樣的系統由於經常出現問題，es報紅，或者計算有問題等，這是由於剛開始一個人做完還沒完全穩定就直接撤人了，轉了幾次到了我手裏（因爲我懂java，android但是部門基本上是以python爲主）。到我手裏了是個挑戰也是一個機遇嘛，然後就開始了填坑之旅。。。。。。。。。。。。
還有一點是這樣不能夠很好的保持數據的實時性。
再次說公司原技術上改進：
簡短几句心酸路程，剛開始接手什麼也不懂：不懂spark hadoop 還有 scala(線上的spark統計用scala寫的).
其中遇到也解決了各種問題，就舉例最主要的兩個。
1.線上的客戶投訴獲取不到原始日誌，沒那麼多時間弄懂了再改進所以解決是 --》 寫python腳本（到了這家公司開始用與部門統一的python）---》功能是從elasticsearch獲取到某個域名原始日誌然後寫入本地文件（雖然不會寫，但是這麼多年編程scala的大概對日誌的處理邏輯還是能看懂的），本地壓縮，然後python調用hadoop本地命令行將日誌上傳到hadoop，先臨時解決了問題
2.elasticsearch報紅、kafka堆積
不知道怎樣解決，只能看日誌了，嘗試用elasticsearch升級到了5.5.2，發現不會出現這樣的問題。 但是又出現了新的問題：spark不能兼容這樣的es版本， 給老大反映情況（提了 我傾向的用python腳本計算這一條路和對es降級嘗試的路），聽命於領導就先對原來的elasticsearch-2.4.6進行了配置改動-但是發現還是偶爾會出現es報紅的情況。 只能用另一條路用python腳本代替spark，使用es自身的聚合功能進行計算，這樣就解決了問題。
總結：所以最後的解決辦法是 去掉spark 先用python腳本直接聚合統計方式請求es獲取結果,這樣也滿足線上要求，就先這樣了。
logstash-forward (邊緣節點日誌收集，上傳到有logstash的機器) -》
kafka 強大的數據緩存組建 （由logstash收集日誌到kafka） -》
elasticsearch (分佈式、可擴展、實時的搜索與數據分析引擎) (用logstash從kafka取出數據存到es) ->
python腳本（調用elasticsearch的resultful_api獲取統計結果，同時打包原始日誌到本地上傳到hadoop） -》
elasticsearch （進行計算結果數據存儲），hadoop（原始日誌打包存儲） -》
nginx + django服務 進行反向代理、負載均衡、地址隱藏 django進行界面展示-》
客戶直接訪問觀看
說一下版本（zookeeper 3.4.7 kafka_2.11-0.8.2.1 logstash-2.2.2 elasticsearch-5.5.2 hadoop-2.6.4 python以及python elasticsearch庫）
最後再說一種現在的架構：
公司在我剛開始接手的同時已經公司招聘了一個大數據人員（但不是本部門的），本部門也要有新項目有更大的數據量要計算需要跟他對接，但是等了好幾個月仍然沒有啥成果，老大忍不住了讓我去看看他的大數據代碼、提改進建議催進度（他主要用spark最終結果存到hbase，java寫的代碼），然後發現代碼寫的比較爛（因爲java基本的靜態變量 方法封裝 繼承多態等一看就是新手），業務邏輯也有點問題-跟老大反映，但是不同部門管不着也不能說啊，細節不說了，最終又開始了新架構的嘗試之旅。
1.filbeat 邊緣節點日誌收集，上傳到有logstash的機器（或者可以用flume) -》
2.kafka 強大的數據緩存組建 （由logstash收集日誌到kafka） -》
3.spark（大規模數據計算引擎，從kafka取出日誌，通過scala編寫的spark代碼把計算結果存入es） -》
4.elasticsearch （進行計算結果數據存儲） -》
5.nginx + django 界面展示或接口讓客戶獲取服務
同時並行的原始日誌打包 （剛開始日誌打包考慮到了用spark或者flume直接上傳到hadoop，但是後來發現現有機器這樣的速度趕不上實際需要，）
3.flume(自定義sink插件，filter插件 從kafka的另一個topic中獲取日誌數據，把日誌按域名，按小時打包到本地） -》
4.python 調用hadoop命令行上傳本地打包好的日誌到hadoop ->
5.nginx + django 界面展示或接口讓客戶獲取服務
版本信息
apache-flume-1.6.0-bin hadoop-2.6.4 kafka_2.11-1.0.0 spark-1.6.1-bin-hadoop2.6
elasticsearch-5.5.2 hbase jdk1.8.0_144 logstash-6.1.1 zookeeper-3.4.5
jdk1.7.0_45(剛開始hadoop使用 後來spark要求更高就用了1.8版本）
當然每個階段都需要增加監控，這裏用的是zabbix監控配合腳本監控