概要
為什么要做監控
線上發布了服務，怎么知道它一切正常，比如發布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配置定期刪除過期數據。