之前寫過第一版監控思路，收到我都想不到的關注度，後面梳理需求進行了一個更大範圍的監控，並支持後續報表的生成。最近因爲資源增加，也在關注elk監控相關思路，之後應該也會有新的文章產出（把監控的坑越挖越大），現在結合舊版講下設計思路和實現。
設計思路：
這次專注於數據量監控，因爲這是一個痛點。同時每天數據量能直觀對數據接入是否成功進行驗證，同時比對每個模塊數據是否正常寫入，發現延遲卡死等問題。
相比之前監控拓展了監控範圍，從最開始的輸入端到最後的輸出。同時方便小組其他人員查看並提供之後報告到處的接口，爲推送給客戶做準備。
設計實現：
首先把時間粒度由一小時延長到一天，因爲按照這個時間粒度仍然能很快發現數據異常，並可以迅速向下查找問題，同時把輸出改爲mysql，增加了字段描述，併爲之後導出爲報表提供了接口。 同時這次新增了計算數據頻率字段，能更直觀發現數據變化，也能做相應統計指標。
這次沒有監控kafka的數據，而是從接入端flume和數據存儲的tsdb，habse，hive和kylin進行存儲，實現整個流程的完整監控。
所以這次程序是java原生程序和腳本輔助構成的。flume是通過定時腳本讀取flume的日誌獲取數據條數和數據字節大小，寫入redis緩存。hbase和tsdb是在程序中直接查詢。hive和kylin也是通過定時腳本（因爲是定時任務，所以會在3-4點左右查前一天數據）。本次hbase，tsdb，hive和kylin也是採取指標點查詢數據（查詢單點）。
最後通過程序聚合數據，寫出到mysql中。
問題與總結
1.flume日誌會很多有用的信息，而且日誌的規範會對腳本統計非常重要。後續做elk準備繼續總結修改相關日誌。
2.hive和kylin的腳本必須運行在安裝相應客戶端的節點，kylin腳本的一個小坑：https://blog.csdn.net/jyj1100/article/details/89667694
3.注意查詢延遲，其中hive查詢會執行10分鐘左右，kylin會執行2分鐘左右。這也是擴大粒度的一個原因
這次除了數據斷掉，更直接的發現了服務掛掉或者卡死的問題，並且能快速定位。但對於整個系統仍然是不夠的 ，目前準備調研和上elk，之後的監控應該就由elk完成了。