如何搭建一個可靠的監控系統
監控系統的組成
- 數據收集
- 數據傳輸
- 數據處理和數據展示
ELK:ELK是Elasticsearch.Logstash,Kibana三個開源軟件產品首字母的縮寫，他們三個通常配合使用，所以被稱爲ELK Stack 下圖是他的架構
分別的功能如下
- logstash負責數據的收集和傳輸，他支持動態地從個數據庫源收集數據，並對數據進行過濾分析，格式化，然後存儲到指定位置。
- elasticsearch負責數據處理，他是一個開源分佈式搜索和分析引擎，具有可伸縮性，高可靠和易管理等特點，絕對能對大容量的數據進行處理分析搜索操作，通常被用作基礎搜索引擎。
- Kibana：主要用於數據展示
![在這裏插入圖片描述]()
Beats
- Packetbeat，用來收集網絡流量數據
- Topbeat，用來收集系統，進程的CPU和內存使用情況等數據。
- Filebeat 用來收集文件數據
- Winlogbeat 用來收集Windows事件日誌數據
如何搭建一套適合你的服務追蹤系統
服務追蹤系統的實現：
- 埋點數據收集，負責在服務端進行埋點，來收集服務調用的上下文數據
- 實時數據處理：負責對收集到的鏈路信息，按照traceId和spaceId進行串聯和存儲
- 數據鏈路展示：把處理後的服務調用數據，按照調用鏈的形式展示出來。
開源服務追蹤方案：OpenZipKin
- Collector:負責收集探針Reporter埋點採集的數據，經過驗證處理並建立索引。
- Storage：存儲服務調用的鏈路數據，默認使用的是Cassandra是因爲Twitter內部大量使用了 Cassandra，也可以替換成elasticsearch或者mysql
- Api: 將格式化和建立索引的鏈表數據以api的方式提供服務，比如被UI調用
- UI：以圖形化的方式展示服務調用的鏈路數據。
工作原理
具體流程是:
- 通過業務的HTTP Clinet 前後引入服務追蹤代碼，這樣在HTTP 方法“/foo"調用前，生成trace信息，TraceId:aa,SpanId:6b、annotaion:GET/foo,以及當前時刻的timestamp：11*****，然後調用返回結果記錄下來耗時duration,之後再把這些trace信息和duration異步上傳給Zipkin Collector.
服務節點是否存活
- 經典問題，如果遇到網絡問題，大批服務提供者節點彙報給註冊中心的心跳信息可能會傳達失敗，註冊中心就會把他們從可用節點列表中移除出去，造成剩下的節點難以調用，可是實際上這些節點是可以調用的，引起雪崩，
- 方法：這個時候可以根據實際業務情況，設定一個閾值比例，即使遇到剛纔說的這種情況，註冊中心也不能摘除超過這個閾值比例節點。
心跳開關保護機制
- 針對網絡抖動的情況，註冊中心可能會不斷變化，這時候消費者會頻繁的接受到服務提供者節點變更的信息。
- 針對這種情況，需要一種保護機制，即使在網絡頻繁抖動的情況下，服務消費者也不至於同時去請求註冊中心獲取最新的節點信息。
服務節點摘除保護機制
-
正常情況下，服務提供者在進程啓動時，會註冊到註冊中心，並每隔一段時候彙報心跳到註冊中心，以標識自己的存活狀態，如果隔了一段時候服務提供者沒有彙報心跳給註冊中心，註冊中心就會認爲該節點已經dead狀態，從服務的可用節點列表移除出去
-
但是如果遇到網絡問題，大批服務提供者節點彙報給註冊中心都可能會傳達失敗，註冊中心就會把他們都從可用節點列表移除出去，造成可用節點難以承受所有的調用，引起雪崩，這個時候就需要根據實際業務情況設定一個閾值，即使遇到這種情況註冊中心也不能摘除超過這個閾值比例的節點。
靜態註冊中心
- 因爲服務提供者是向服務消費者提供服務的，所以服務可不可以用，服務消費者最清楚，因此可以在服務消費者調用服務提供者是否成功來判斷服務提供者是否可用。如果服務消費者調用服務提供者節點失敗超過一定次數，可以在本地標記這個節點不可用。並且每隔一段時間，服務消費者向標記不可用的幾點發起探測，如果探測成功， 就標記不可用節點爲復活狀態，重新發起調用。
總結
當遇到網絡不穩定的時候，一般會出現以下兩個問題：
- 一個是服務消費者同時併發請求註冊中心獲取最新的服務信息導致註冊中心帶寬被拉滿，另一個就是服務提供者節點大量摘除的情況下，服務消費者沒有足夠的節點可以調用，導致服務“雪崩”