當我們要觀察系統的生命徵象時,Elastic Stack 的解決方案中,可以使用 Heartbeat 週期性的檢查系統的可用性 (availability),不過在這邊我們要先想一下,什麼是系統的生命徵象?代表的意義是什麼?以下一邊透過以"人的生命徵象"來想像,另一邊對應到"系統的生命徵象"來思考:
首先部署 Heartbeat 的最主要原則:當系統掛掉的時候,負責監測的 Heartbeat 不應該跟著掛掉。
因此官方文件就有直接提出,不建議使用 sidecar 的這種方式來部署 heartbeat,建議要部署成為獨立的服務,以降低主要的系統發生問題時,Heartbeat 也同時出問題的可能性。[1]
什麼是 sidecar?
sidecar 的中文是『邊車』,也就是把程式以另外的 process 掛載在主要的 process 或是 container 旁邊,避免直接運作在主 process 之中,一方面是可以更好的模組化、佈署的方式也能更容易標準化並重覆利用,另一方面是減少與主程式的相依性,不過實際運作上還是會有一些資源是共用的,例如安裝在同一台主機上、使用同樣的 disk,使用同樣的 network 環境…等。
一般我們要監控服務時,最直接會想到從外層,也就是 Internet 去監控,但試想,如果今天外層發現服務不通的時候,但你從服務的 local 端發現是好的時候,中間的這些網路問題,要如何能更有效的盤查與找出問題呢?
我們重新檢視從 Client 端,一路到服務運作的 Server 主機中,網路會經過哪些路徑,對外的服務一般來說會經過 CDN,若是內部的服務也可能跨過多個 VPN,因此在這樣有多段網路環境的路線當中,建議的做法是:CDN 內、外都要架設 heartbeat,不同 VPN 的網段內也要有各自的 heartbeat,透過一層一層的記錄,能夠最快速的幫我們在發生問題的當下,判斷是在網路的哪一層發生問題。
當我們的服務對外有經過 CDN 時,CDN 的架構上會透過許多的 POPs (points of presence) 也就是散落在世界各地的節點,來處理快取,並且讓 client 能最近、也就會最快速的取得需要的內容,所以如果有使用 CDN 時,一般也就會建議要在多個不同的地區佈建 Heartbeat,收集各個不同地點是否能正常的存取服務的數據。
如果有不同的 Data Center時,除了建議一定要在各個 Data Center 內部佈署自己的 Heartbeat,另外在設定監控時,除了監控自己 Data Center 的服務之外,也應該順便監控另個 Data Center 的服務,這樣跨 Data Center 時的網路環境會多透過 Internet,也會是出問題時能作為交互比對的參考資訊。
以上是建立監控之前,需要先思考及評估的部份,在經過這些評估及規劃之後,下一篇我們將透過 Elastic heartbeat 的設定,來收集這些我們需要取得的資料。
查看最新 Elasticsearch 或是 Elastic Stack 教育訓練資訊: https://training.onedoggo.com
歡迎追蹤我的 FB 粉絲頁: 喬叔 - Elastic Stack 技術交流
不論是技術分享的文章、公開線上分享、或是實體課程資訊,都會在粉絲頁通知大家哦!