概要
爲什麼要做監控
線上發佈了服務，怎麼知道它一切正常，比如發佈5臺服務器，如何直觀瞭解是否有請求進來，訪問一切正常。
當年有一次將線上的庫配置到了Beta，這麼低級的錯誤，排錯花了一個通宵，十幾個人。
某個核心服務掛了，導致大量報錯，如何確定到底是哪裏出了問題。
SOA帶來的問題，調用XX服務出問題，很慢，是否可以衡量？
由於業務系統數量大，每天都會產生大量的系統日誌和業務日誌，單流式業務的一臺服務器產生的日誌達400M 想直接查看內容打開可能幾分鐘，而且內容之多根本無法查看，給開發和運維帶來諸多不便，現業務都是分佈式的，日誌也是分佈在每臺服務器上，所以查看日誌和統計更是效率低下。實時收集分佈在不同節點或機器上的日誌，供離線或在線查閱及分析來提升工作效率的需求異常迫切，在此背景下，特對公司統一日誌平臺進行初步架構設計。
在信息化時代，日誌的價值是無窮的。爲了對系統進行有效的監控、維護、優化、改進，都離不開對日誌的收集和分析，接下來我們來看看秉着“短平快”的互聯網精神，構建的這套適合現有業務系統的統一日誌平臺，總體分爲業務日誌監控平臺和軟硬件服務監控平臺。
業務日誌平臺總體設計
以上是最終的一個最終的一個架構規劃，統一日誌監控系統負責將所有系統日誌和業務日誌集中，再通過flume或logstash上傳到日誌中心(kafka集羣)，然後供Storm、Spark及其它系統實時分析處理日誌，或直接將日誌持久化存儲到HDFS供離線數據分析處理，或寫入ElasticSearch提供數據查詢，或直接發起異常報警或提供指標監控查詢。
根據現有業務量來看，以上架構有點“重”，可以作爲以後的目標，現階段來說可以參考以下架構：
以上內容皆以配置爲主，對現有業務沒有影響，針對於Windows環境可以用FileBeat監控本地日誌全量、增量的上傳日誌，對於一些穩定的日誌，比如系統日誌或框架日誌(如HAproxy訪問日誌、系統異常日誌等)，通過rsyslog寫到本地目錄local0，然後logstash根據其配置，會將local0中的增量日誌上傳到日誌中心。Java環境下可以採用log4j直接發送到Logstash。
日誌處理層
可以在Logstash中對日誌作簡單的分類加工處理再發送出去。
我們可以將日誌聚合，根據業務不同，建立不同的索引，存入ElasticSearch提供查詢。 發現異常日誌時，發往監控中心，向對應的業務方發起報警，發現和預發問題的實時性提高了。統計一些訪問日誌或調用日誌等指標信息，發往監控中心來掌握相關調用趨勢。調用鏈開始做起來了，系統性能瓶頸一目瞭然了。
日誌存儲層
ElosticSearch中按照不同業務建索引主題（數據庫），業務裏面再按照需求建類型（表），不需要的歷史數據可按需要持久化到HDFS，以減少ES的壓力。
展示層Kibana
Kibana是ELK中的組件，是一個針對Elasticsearch的開源分析及可視化平臺，用來搜索、查看交互存儲在Elasticsearch索引中的數據。使用Kibana，可以通過各種圖表進行高級數據分析及展示。
Kibana讓海量數據更容易理解。它操作簡單，基於瀏覽器的用戶界面可以快速創建儀表板（dashboard）實時顯示Elasticsearch查詢動態。
Kibana可以非常方便地把來自Logstash、ES-Hadoop、Beats或第三方技術的數據整合到Elasticsearch，支持的第三方技術包括Apache Flume、Fluentd等。
監控ES的整體健康狀態
直接查詢ES索引內容
簡單的查詢過濾日誌數據窗口
可實時的圖形統計展示
採用ElastAlert實現日誌監控告警
平臺缺失針對mysql連接數的告警，指定業務如流式服務數據異常，當異常觸發時能夠及時通過短信、郵件等方式通知相關負責人員
如故障信息：
以上說的“日誌”不僅限於日誌信息，也可以是業務數據。
軟硬件服務監控平臺設計
當業務層日誌發現異常時如保存數據到Mysql時經常性報連接數據庫超時，只有當業務人中發現再通知我們時已經過了一段時間才發現問題，但已無法重現當時的生產環境，也就靠經驗來猜原因是服務器的網絡問題還是數據庫的真實連接滿了還是程序的寫法出現問題，因此就需要監控當時生產環境的軟硬件監控數據。
經過多方諮詢參考各大廠的監控方案和對比在此採用Zabbix作監控。
最近各服務整體問題一覽
針對Web服務器和API的訪問性能、HAproxy、IIS、Tomcat
實時繪圖監控服務器所有TCP端口的數量和 MySql數據庫連接數、Redis性能
自定義聚合展示服務器各指表最近的狀態,CPU、內存、流量。
顯示所有服務器的一個健康狀況，一目瞭然
自動註冊監控新的服務器
報警機制，Email、微信、短信等
其它特性
可監控Linux、Windows、打印機、文件系統、網卡設備、 SNMP OID、數據庫等平臺服務狀態。
允許靈活地自定義問題閥值， Zabbix 中稱爲觸發器(trigger), 存儲在後端數據庫中。
高級告警配置，可以自定義告警升級(escalation)、接收者及告警方式。
數據存儲在數據庫中 歷史數據可配置 內置數據清理機制。
web 前端採用 php 訪問無障礙。
Zabbix API 提供程序級別的訪問接口，第三方程序可以很快接入。
靈活的權限系統。
結合以上業務和軟硬件上的日誌方便開發和運維實時查找問題提高解決問題的效率，而且前期均可只通過配置0代碼就可實現監控和報表展示。
擴展性
可用Spark對數據實時分析，智能攔截異常數據和直接發送異常警報。
在Zabbix上結合自己的業務需求二次開發應用系統層面上的預警監控系統。
以後可加入Kafka將日誌集中，至於爲什麼選用kafka集羣來構建日誌中心，理由主要如下:
1、分佈式架構，可支持水平擴展。
2、高吞吐量，在普通的服務器上每秒鐘也能處理幾十萬條消息(遠高於我們的峯值1.5萬條/秒)。
3、消息持久化，按topic分區存儲，支持可重複消費。
4、可根據broker配置定期刪除過期數據。