我們要觀測的生命徵象是什麼？

本篇學習重點

我們要監控系統的 uptime 時，我們的目的是什麼？什麼是系統的生命徵象？
在開始設定 Heartbeat 來設定監控之前，我們要考慮的面向有哪些？

系統的生命徵象

當我們要觀察系統的生命徵象時，Elastic Stack 的解決方案中，可以使用 Heartbeat 週期性的檢查系統的可用性 (availability)，不過在這邊我們要先想一下，什麼是系統的生命徵象？代表的意義是什麼？以下一邊透過以"人的生命徵象"來想像，另一邊對應到"系統的生命徵象"來思考：

還有沒有心跳： 也就是系統的主機是不是活著？是不是 ping 了之後能得到回應，當得到回應時，代表系統的主機是活著。
心跳的速率是否正常： ping 系統時，回應的速度如何？是否在我們接受的合理範圍之內？有沒有發生 timeout？
還有沒有意識能回話： 要能回話代表服務要能正常運作，所以我們應該透過應用程式所提供的 health check API 來進行確認，以認服務是否能正常的回應。
回話的速度： 透過 health check API 時，我們可以觀察 response time，也就是系統的回覆速度，是不是符合我們的期待？
回話是否正常： 我們對於 health check API 的回應結果，是否符合我們的預期？如果只是 HTTP 200 的話，其實有機率不代表是我們系統的回覆，(喬叔就曾經發生網路設定被誤改，因此請求被導到別的服務上，拿到的回應是 HTTP 200，但是 response 內容並非我們預期的)，回應的內容應該要是我們期待的結果。
其他活著的定義： 每個人對於活著的定義其實多少會有不同，有些人認為行屍走肉不算活著 XD，這邊提供一個思考的觀點，這個系統提供的是什麼服務，這個服務哪些部份是最重要的，一但這些功能停擺時，代表這個服務是死的了，因此這邊可以想像一下，如果是個有相依於 Database 的服務，如果 DB connection 無法正常連線的時候，這個服務算是活著的嗎？另外也應該要回歸商業面，是否有哪些最重要的功能，如果這些功能無法正常運作時，可以判定服務是死的？例如 auth service，如果他提供 issue token 或是 validate access token 的 API 是死的，是不是代表整個服務其實就是死的了呢？這個議題其實是 health check API 的設計方式，你要 check 的東西到底是什麼，是不是要包含到第三方相依服務的狀態？這個題目在這邊不會深入探討，但是絕對會是你們團隊在建立 uptime monitor 之前會要考慮清楚的 (其實是服務開發時就要定義好的)。

監控系統生命徵象時，你應該要考慮的面向

部署的方式，是不是夠安全可靠？

首先部署 Heartbeat 的最主要原則：當系統掛掉的時候，負責監測的 Heartbeat 不應該跟著掛掉。

因此官方文件就有直接提出，不建議使用 sidecar 的這種方式來部署 heartbeat，建議要部署成為獨立的服務，以降低主要的系統發生問題時，Heartbeat 也同時出問題的可能性。[1]

什麼是 sidecar?
sidecar 的中文是『邊車』，也就是把程式以另外的 process 掛載在主要的 process 或是 container 旁邊，避免直接運作在主 process 之中，一方面是可以更好的模組化、佈署的方式也能更容易標準化並重覆利用，另一方面是減少與主程式的相依性，不過實際運作上還是會有一些資源是共用的，例如安裝在同一台主機上、使用同樣的 disk，使用同樣的 network 環境…等。

監控不只從最外面的 Internet 來監控，從 client 端一路到服務所運作的伺服器，這條路線中你還要從哪一層切入？

一般我們要監控服務時，最直接會想到從外層，也就是 Internet 去監控，但試想，如果今天外層發現服務不通的時候，但你從服務的 local 端發現是好的時候，中間的這些網路問題，要如何能更有效的盤查與找出問題呢？

我們重新檢視從 Client 端，一路到服務運作的 Server 主機中，網路會經過哪些路徑，對外的服務一般來說會經過 CDN，若是內部的服務也可能跨過多個 VPN，因此在這樣有多段網路環境的路線當中，建議的做法是：CDN 內、外都要架設 heartbeat，不同 VPN 的網段內也要有各自的 heartbeat，透過一層一層的記錄，能夠最快速的幫我們在發生問題的當下，判斷是在網路的哪一層發生問題。

是否已盤查清楚系統運作的網路架構，你要從哪些地方監控才足夠？

當我們的服務對外有經過 CDN 時，CDN 的架構上會透過許多的 POPs (points of presence) 也就是散落在世界各地的節點，來處理快取，並且讓 client 能最近、也就會最快速的取得需要的內容，所以如果有使用 CDN 時，一般也就會建議要在多個不同的地區佈建 Heartbeat，收集各個不同地點是否能正常的存取服務的數據。

是否有佈署在另一個 Data Center 的備援服務？在多個 Data Center 時，除了監控自己，也應該互相監控。

如果有不同的 Data Center時，除了建議一定要在各個 Data Center 內部佈署自己的 Heartbeat，另外在設定監控時，除了監控自己 Data Center 的服務之外，也應該順便監控另個 Data Center 的服務，這樣跨 Data Center 時的網路環境會多透過 Internet，也會是出問題時能作為交互比對的參考資訊。

以上是建立監控之前，需要先思考及評估的部份，在經過這些評估及規劃之後，下一篇我們將透過 Elastic heartbeat 的設定，來收集這些我們需要取得的資料。

參考資料

PreviousUptime - 掌握系統的生命徵象 Next使用 Heartbeat 收集系統生命徵象數據

Last updated 2 years ago

系統的生命徵象

還有沒有心跳： 也就是系統的主機是不是活著？是不是 ping 了之後能得到回應，當得到回應時，代表系統的主機是活著。

心跳的速率是否正常： ping 系統時，回應的速度如何？是否在我們接受的合理範圍之內？有沒有發生 timeout？

還有沒有意識能回話： 要能回話代表服務要能正常運作，所以我們應該透過應用程式所提供的 health check API 來進行確認，以認服務是否能正常的回應。

回話的速度： 透過 health check API 時，我們可以觀察 response time，也就是系統的回覆速度，是不是符合我們的期待？

回話是否正常： 我們對於 health check API 的回應結果，是否符合我們的預期？如果只是 HTTP 200 的話，其實有機率不代表是我們系統的回覆，(喬叔就曾經發生網路設定被誤改，因此請求被導到別的服務上，拿到的回應是 HTTP 200，但是 response 內容並非我們預期的)，回應的內容應該要是我們期待的結果。

其他活著的定義： 每個人對於活著的定義其實多少會有不同，有些人認為行屍走肉不算活著 XD，這邊提供一個思考的觀點，這個系統提供的是什麼服務，這個服務哪些部份是最重要的，一但這些功能停擺時，代表這個服務是死的了，因此這邊可以想像一下，如果是個有相依於 Database 的服務，如果 DB connection 無法正常連線的時候，這個服務算是活著的嗎？另外也應該要回歸商業面，是否有哪些最重要的功能，如果這些功能無法正常運作時，可以判定服務是死的？例如 auth service，如果他提供 issue token 或是 validate access token 的 API 是死的，是不是代表整個服務其實就是死的了呢？這個議題其實是 health check API 的設計方式，你要 check 的東西到底是什麼，是不是要包含到第三方相依服務的狀態？這個題目在這邊不會深入探討，但是絕對會是你們團隊在建立 uptime monitor 之前會要考慮清楚的 (其實是服務開發時就要定義好的)。