概要

為什麼要做監控

線上釋出了服務，怎麼知道它一切正常，比如釋出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配置定期刪除過期資料。