監控方案設計

飛鴿監控目的

1. 業務功能的監控。防止出現問題，致使飛鴿服務長時間的不可用，而且人員未發現。
2. 性能可用性的監控。功能知足須要，不表明飛鴿的性能知足須要，須要對性能進行監控，以及作出預警。
3. 提供有效的預警機制。防止業務爆發式增加帶來的隱患：消費能力不足；飛鴿存儲不足。
4. 提供快速定位問題的有效信息。提供消息流轉過程，有效定位出問題點。
5. 提供飛鴿使用組件（jws、os、mysql）的監控。

飛鴿監控的思路

服務組成的思路

飛鴿服務有OS、JWS、MySQL、飛鴿server、飛鴿admin、飛鴿SDK組成

從少到多的思路

隨着業務量的發展變化，服務器數量逐漸增多，單臺server的可用性和總體服務的可用性，都須要進行監控，對發生的問題進行告警。

發展變化的思路

從時間角度考慮，發佈者業務的爆發，會給飛鴿和消費者帶來衝擊，server的壓力上升，消費者消息的積壓；飛鴿接入量的變化，給飛鴿server的壓力。 所以須要一種預警機制，提取發現問題暴露的苗頭，及早進行調整。

分層的思路

數據流轉過程：

具體到監控該如何作，能夠採用分層的架構模式。 採集部分只負責數據的採集，產生元數據。 統計彙總，則對元數據根據統計規則和業務規則，進行彙總統計，併產生統計數據 監控邏輯，對產出的統計數據，結合監控告警規則，向告警平臺發出告警請求。

飛鴿監控邏輯結構

從飛鴿app服務到使用飛鴿做爲組件；從一臺飛鴿服務器到多臺飛鴿服務器考慮。飛鴿須要提供業務的監控功能由兩部分組成：業務監控和組件監控 而出現問題時輔助定位的工具也是不可缺乏的。 所以整個飛鴿有3部分組成：業務層監控、組件層監控、輔助定位工具

業務層監控

從發展變化的視角看飛鴿可用性，業務層監控須要提供：告警和預警功能。 告警：對目前飛鴿服務可用性問題發生時，通知相關人員。 預警：對業務量的增加帶來的可用性風險，通知相關人員。

飛鴿告警

1. 這裏是列表文本提供業務功能的監控。防止出現問題，致使飛鴿服務的不可能。
2. 提供性能可用性的監控。功能知足須要，不表明飛鴿的性能知足須要。

飛鴿預警

• 這裏是列表文本提供有效的預警機制。防止業務爆發式增加帶來的隱患。

業務層監控

飛鴿使用的組件，一旦發生問題，勢必會影響飛鴿的可用性，所以對於飛鴿使用組件的監控也是必不可少的。 飛鴿組件的監控，須要提供飛鴿使用組件（jws、os、mysql）的監控。

輔助定位工具

當出現可用性或者其餘問題時，如何快速的協助業務定位出問題所在，減小問題定位所花費的時間，是對可用性的間接提高。 所以問題定位輔助工具，須要提供快速定位問題的有效信息：提供消息流轉過程，有效定位出問題點。

飛鴿監控內容

經過以上的介紹，飛鴿須要進行的監控包括如下內容：

其中飛鴿功能可用、飛鴿服務性能、及時發現問題數據飛鴿業務層監控範疇；快速定位問題屬於飛鴿問題定位輔助工具範疇；業務爆發影響屬於組件層以及部分業務層範疇。

飛鴿監控方案

業務層監控方案

ELK方案

Logstash：收集日誌 ElasticSearch：進行日誌的彙總和統計 Kibana：展示日誌記錄 DoveAdmin：根據業務規則展示性能數據和鏈接數據；請求提供數據查詢接口給Diag。 Diag：從DoveAdmin獲取各個Server數據信息，並做爲業務的組件層展現。

ES方案

DoveServer：上報鏈接以及性能統計數據 ElasticSearch：存儲上報的相關數據 DoveAdmin：根據業務展現邏輯，彙總查詢數據；提供Diag查詢接口，在業務的組件層展現 Diag：業務立體化監控，進行相關的展現和告警。

Diag方案

須要Diag提供對飛鴿的特別支持。

DoveAdmin：提供配置拉取接口，供Diag使用。 飛鴿Diag：先從 DoveAdmin拉取配置，而後根據配置，向每一個server獲取server的鏈接信息、性能數據；獲取到的數據存儲在ElasticSearch中，並在飛鴿Diag的業務層展現 DoveServer：提供接口供飛鴿Diag查詢鏈接和性能數據。 業務Diag：業務Diag能夠複用diag的數據，做爲業務的組件層數據

注意：飛鴿Diag獲取DoveServer的數據，能夠有兩種方式：飛鴿Diag主動向DoveServer查詢；DoveServer主動上報給飛鴿Diag。

方案對比

對比項	ELK方案	ES方案	diag方案
性能	logstash採集日誌，使用redis進行緩存<br>elasticsearch進行彙總統計<br>kibana 進行展現<br>因爲elasticsearch的寫入速度限制，須要加上redis提高性能，可是數據量大，統計分析任務重<br>總評：性能中	elastic的寫入性能低 <br> 總評：低	DoveServer進行彙總後發送給DoveAdmin，使用HTTP接口<br> 總評：性能中
成本（硬件）	須要較多的服務器和存儲支持	存儲成本高，整體中	DoveAdmin存儲性能數據，有效期7天，成本低。
擴展性	存儲了元數據，能夠根據業務對元數據進行靈活使用。擴展性高	DoveServer進行了基本的彙總不少細節數據不存在。擴展性低	也是進行了彙總。擴展性低（diag只能提供接口請求量整體數據以及組件層監控）
複雜度	涉及組件較多，複雜度高	複雜度中等	目前已實現，須要添加diag部分，複雜度中
維護性	組件太多，維護成本高	維護成本中	維護成本中

組件層監控方案

接入diag(立體化監控)，使用立體化監控進行監控和告警。 diag目前已經支持了組件層的監控，主要有：mysql 、OS 、 jws 等

問題定位輔助工具方案

使用ELK（ElasticSearch + logstash + Kibana）方案。 logstash：進行日誌收集 elasticsearch：進行彙總分析 kibana：進行日誌的可視化展現