零代碼如何打造本身的實時監控預警系統

概要

爲何要作監控

線上發佈了服務，怎麼知道它一切正常，好比發佈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.5萬條/秒)。

三、消息持久化，按topic分區存儲，支持可重複消費。

四、可根據broker配置按期刪除過時數據。