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

### 本篇學習重點

* 我們要監控系統的 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 的設定，來收集這些我們需要取得的資料。

## 參考資料

1. [Elastic 官方文件 - Ingest uptime data](https://www.elastic.co/guide/en/observability/current/ingest-uptime.html#ingest-uptime)