一台主機承擔的風險

一台主機上跑著入口、應用程式、資料庫、快取與整組監控時，所有元件共用同一個失效域（failure domain），風險有三種。中斷沒人通知：主機停掉時服務中斷，而負責通知的監控同時停掉，要等使用者回報才知道。監控與服務搶資源：主機過載時，應用程式、資料庫與監控搶同一組 CPU 與記憶體，監控量到的延遲混進它自己的等待（見 4.27 主機過載時的監控告警）。資料與備份一起消失：資料與它的備份放在同一台主機的磁碟上時，磁碟損壞或帳號被停權會讓兩者一起消失。

資料與備份一起消失是三種裡唯一不可逆的，也不需要第二台主機：備份放到另一個業者的物件儲存或另一個帳號，就不再與資料一起消失（備份與資料放在同一個帳號時，帳號被停權、或存取憑證外洩後被人刪除，兩者一起消失），所以它排在加主機之前做（備份的驗證見 備份與還原的地基）。分開帳號擋的是資料所在帳號的憑證外洩；寫入備份的那把存取金鑰仍放在服務主機上，它外洩之後備份會不會被刪除或覆寫，見 7.43 兩個網路之間的連線安全。第二台主機處理的是中斷沒人通知、監控與服務搶資源，處理哪一種取決於它放什麼。

第二台主機的用法：給監控、給應用程式的副本或給資料庫

給監控。 Prometheus、Alertmanager 與 Grafana 搬到第二台，服務主機只留 exporter（輸出指標給 Prometheus 讀取的程式）。原本跑在同一台的自架通知服務（ntfy、郵件轉送）一起搬過去，或改用外部的服務；留在服務主機上的話，「服務主機停了」這則告警要經過那台已經停掉的主機。服務主機停掉時，監控主機讀不到它的指標而發出告警；監控主機停掉時，服務照常運作，由服務主機上的心跳監看程式發現（見〈兩台主機互相監看〉）。服務本身的可用性沒有提高，主機停掉時服務照樣中斷；換到的是中斷有人通知，以及監控不再與服務搶資源。應用程式不必改，監控主機的資源需求也小（指標量的估算見 Prometheus 容量規劃與故障模式）。搬的時候要決定既有的指標歷史帶不帶過去：不帶的話新主機從零累積，搬移前後的趨勢在面板上接不起來；要帶的話把 Prometheus 的資料目錄一起搬，停掉舊的 Prometheus 再複製，避免複製到寫到一半的資料。

給應用程式的副本。 兩台主機各跑一份應用程式，前面以負載平衡器分流，一台停掉時另一台接手。換到的是服務的可用性，前提有四個：應用程式是無狀態的（session 不存在單台主機的記憶體或磁碟裡，見 無狀態設計）；資料庫不在任何一台應用主機上，否則放著資料庫的那一台停掉時，另一台的應用程式也沒有資料可讀；負載平衡器本身不是單點；應用程式內建的排程工作（清理過期的短網址、寄信、結算）只在一台執行，否則兩台各跑一份，副作用跟著重複，做法是加鎖、選出一台負責，或把排程工作獨立出來；固定指定一台時，那一台停掉排程就停了，以排程工作的心跳發現（見 4.28 單台主機的監控盲區與失效域以外的觀察者 的〈心跳監看：監控與送出心跳的那條路還在不在運作〉）。無狀態這一條違反時，平時看不出來：負載平衡器若以 sticky session 把同一個使用者固定送到同一台，兩台都在時每個人都正常；直到一台停掉的那一刻，那台上的使用者一起被登出、上傳到一半的檔案一起消失，而這是這個配置第一次真正派上用場的時候。資料庫因此要搬到託管服務或第三台主機，這個配置需要兩台應用主機加上另外放置的資料庫。

給資料庫。 資料庫搬到第二台，應用程式與資料庫各自有一台主機的資源。換到的是效能的隔離：資料庫的大查詢不再拖慢轉址這類延遲敏感的請求，應用程式與資料庫的容量也能分開調整。可用性沒有提高，反而多了一個會讓服務中斷的主機：兩台任一台停掉，服務都中斷。

目標只有「中斷有人通知」時，不需要第二台主機：第三方的心跳監看與外部探測服務幾乎不花錢就做得到，挑選與接法見 第三方心跳監看與外部探測服務。第二台給監控多換到的是三件事：監控不再與服務搶資源、監控資料與告警內容留在自己手上、心跳的接收端不依賴第三方的服務。通知的寄送與第三個位置的外部探測仍然依賴第三方：用來分辨兩台之間連線中斷的外部探測要放在兩台以外（見〈監控主機與服務主機之間的連線與連線中斷的誤判〉）。所以小型服務在要擴充主機時，第二台先給監控：中斷沒人通知與監控搶資源在一台主機的階段就存在，給監控的第二台同時處理這兩種風險，也不需要改應用程式；應用程式的副本要先處理無狀態化與資料庫的位置，資料庫的分離處理的是效能而不是可用性。停機代價高、主機故障又頻繁的服務，例外地先做應用程式的副本，判斷方式見 高可用的成本。

監控主機的位置：另一個業者或地端

監控主機要與服務主機分屬不同的失效域。兩台虛擬機租在同一個業者、同一個區域時，業者那個區域的網路故障或帳號被停權會讓兩台一起受影響；所以監控主機放在另一個雲端業者，或放在地端（公司或家裡長時間開著的一台主機）。多台主機的指標收集 的〈監控主機放在哪裡〉處理的是同一個私有網路裡分出一台監控主機的情形，本篇多加的是失效域的條件。

監控是內部服務，地端是合理的位置：Grafana 只給團隊看，連線經由 SSH 或 VPN（存取方式見 Grafana 的對外存取），不必對網際網路開放 Grafana。地端主機的代價是它自己的可靠度：停電、網路斷線、機器重開時監控就停了，停掉的那段時間沒有指標。這段時間由服務主機上的心跳監看程式發現；監控資料的連續性要求高時，改租另一個業者的小型 VPS。

監控主機與服務主機之間的連線與連線中斷的誤判

Prometheus 主動讀取各主機的 exporter，所以監控主機要連得到服務主機上的 exporter 連接埠。這些連接埠不對網際網路開放：exporter 預設沒有認證，輸出的指標透露主機的資源、服務的名稱與版本。同一個雲端業者內，exporter 綁在私有網路的位址上（多台主機的指標收集 以 EXPORTER_BIND_ADDR 設定）；跨業者或跨地端時沒有共用的私有網路，要在兩台之間建一條 VPN，例如 WireGuard 或 Tailscale（運作方式見 Tailscale 深入），exporter 改綁在 VPN 介面的位址上。VPN 預設兩個方向都互通，雲端主機被入侵時攻擊者也能經由它連回地端；隧道兩端各自連得到什麼、限制要放在哪一端，見 7.43 兩個網路之間的連線安全。

地端在 NAT 後面、對外 IP 會變動時，由地端主動建立 VPN：WireGuard 在地端那一側設定 PersistentKeepalive、主動連到雲端主機，雲端主機在業者的防火牆或安全群組開放一個 UDP 連接埠給它；Tailscale 由它的 NAT 穿越與中繼伺服器建立連線，兩端都不必開放連接埠。隧道建立之後兩個方向都連得到，所以 Prometheus 從監控主機讀取，或服務主機以 remote write 把指標推到監控主機，在網路上都走得通，兩者的取捨見〈多台主機的指標收集〉的〈指標回到中央的架構：中央直接讀取與各主機推送〉。安全上兩者的差別在誰要接受對方發起的連線：讀取時地端只發起連線，推送時地端要開放接收端點，見 7.43 兩個網路之間的連線安全。

跨網路讀取多了一種誤判：兩地之間的 VPN 斷掉時，監控主機讀不到服務主機，在監控看來與服務主機停了相同，up（Prometheus 記錄每個讀取對象是否讀取成功的序列）變成 0，主機停機的告警發出。分辨連線中斷與服務主機停機要靠第三個位置的觀察者：從另一個網路對服務的公開網址發請求的外部探測，放在服務主機與監控主機以外（通常是第三方的外部探測服務）。外部探測成功而監控讀不到，指向兩地之間的連線；兩者都失敗，指向服務主機。這個配置裡量使用者路徑的也是這個外部探測：監控主機經由 VPN 讀取，不走使用者用的公開網址（見 4.28 單台主機的監控盲區與失效域以外的觀察者 的〈外部探測：使用者看到的結果〉）。主機停機告警的說明因此寫上「也可能是監控主機連不過去」，值班的人收到時就知道有這兩種成因。

兩台主機互相監看

監控主機發現服務主機停掉；監控主機自己停掉時，要由服務主機發現。服務主機上跑一個心跳監看程式（dead man’s switch，例如自架的 healthchecks，或一個記下最後一次心跳、超過週期加寬限就通知的小程式），接收監控主機上 Alertmanager 送出的 Watchdog 心跳。自架 healthchecks 時，ping 網址、/fail、Alertmanager 的路由與暫停的用法與第三方版相同，見 第三方心跳監看與外部探測服務，網址換成服務主機的 VPN 位址。任一台停掉，另一台都會發現，心跳監看不必用第三方服務。

心跳監看本身的條件（見 4.28 單台主機的監控盲區與失效域以外的觀察者 的〈心跳監看：監控與送出心跳的那條路還在不在運作〉，例如送出間隔小於週期加寬限）之外，互相監看另外要滿足三個條件：

• 心跳的路徑也走 VPN。 監看程式的接收端點不對網際網路開放；知道心跳網址的人可以送出假的心跳，也可以送出假的失敗。代價是 VPN 斷線時這裡也會誤報：監看程式收不到心跳，寄出「監控主機停了」，同時監控主機讀不到服務主機，發出「服務主機停了」。兩邊的停機通知同時出現，指向的是兩地之間的連線；兩台都停掉時，第三方的外部探測也會失敗，外部探測成功就是連線的問題。
• 監看程式的通知不經過監控主機。 它直接寄 email（經由業者的郵件服務或一個寄送系統通知信的郵件服務，transactional email），或送到另一個推播服務，不送給監控主機上的 Alertmanager 或 ntfy。監控主機停掉時，經過它的通知一起停。
• 監看程式自己有人盯著。 它停掉時不會有任何訊號。它跑在服務主機上，監控主機以 blackbox_exporter 這類探測程式對它的網頁發 HTTP 請求，它停掉時由監控主機的告警通知；Prometheus 讀取 exporter 的方式讀的是指標格式，讀不了一般的網頁或健康端點。這條告警要同時涵蓋探測程式自己讀不到的情形：只寫 probe_success == 0 時，blackbox_exporter 自己停掉，這個序列跟著消失，告警不會成立，所以另外以 up == 0（或序列消失）告警。

剩下的風險是兩台同時停掉，這時沒有任何一方送得出通知。兩台在不同的業者時，同時停掉的機會小；兩台主機共用的依賴會讓這種情形比預期常見，例如兩台的通知都經由同一個郵件服務寄出、兩台的網域都在同一個 DNS 業者。兩台是否分屬不同失效域，看逐項比對依賴之後還剩下哪些共用項（比對方式見 Failure Domain 的〈判讀方式〉）。要涵蓋兩台同時停掉，〈監控主機與服務主機之間的連線與連線中斷的誤判〉裡用來分辨連線中斷的第三方外部探測服務，同時就是兩台主機以外的觀察者。

第三台主機的用法：給資料庫，或兩台應用主機搭配託管資料庫

應用主機、資料庫主機與監控主機。 第三台給資料庫，應用程式與資料庫各一台，兩台在同一個業者、同一個區域，以私有網路連線；監控主機維持在另一個業者或地端。這個配置處理資源競爭，可用性與只有服務主機加監控主機時相同：應用主機或資料庫主機任一台停掉，服務中斷。適合的情形是監控已經分出去、而效能問題來自應用程式與資料庫搶資源。

兩台應用主機加監控主機。 兩台各跑一份應用程式，前面放業者的負載平衡器，監控主機在另一個失效域。資料庫不能放在任何一台應用主機上，所以要用業者的託管資料庫（自架與託管的取捨見 自架還是託管：以資料庫為例）。這個配置提高可用性：一台應用主機停掉時服務照常，監控主機發出告警，通知值班的人有一台應用主機停了。代價是託管資料庫的費用，以及應用程式要先做到無狀態、排程工作只在一台執行。兩台應用主機放在同一個業者的不同可用區，才不會因為同一個機房的故障一起停；它們仍共用同一個帳號、業者的負載平衡器、同一條部署管線（一次壞掉的部署同時打到兩台，見 Correlated Failure）與同一組 DNS，這幾項是可用區分開之後剩下的共用依賴；託管資料庫本身也落在某個可用區，只開在單一可用區時，那個機房故障仍會讓服務中斷，跨可用區的設定與費用查自己那一家的文件。active-passive（備援平時不接流量）與 active-active（兩份同時接流量）的選擇見 冗餘設計模式。

不論第三台怎麼用，備份都維持在應用與資料庫的失效域以外（見〈一台主機承擔的風險〉）：資料庫搬到第三台或託管服務之後，備份的來源跟著換，備份的目的地仍是另一個業者或另一個帳號。

雲端業者負責的範圍與自己負責的範圍

主機數處理的是主機層的故障：一台停掉時另一台接手、監控不與服務一起停。業者對硬體與電力的故障處理到「讓虛擬機恢復」為止：在另一台實體機上重新啟動虛擬機，中間的停機仍由使用者處理：要不中斷就要另一台實體機上的副本（機房層級的故障要放在另一個可用區），那正是第二台主機給應用程式的副本時換到的保護（可用區見〈第三台主機的用法：給資料庫，或兩台應用主機搭配託管資料庫〉）。應用層的攻擊則是加主機也換不到保護的一類：它打在每一台都相同的入口上，主機再多也一樣進得來。這兩類由雲端業者與使用者之間的責任分擔模型（shared responsibility model）分工：業者處理所有客戶共用的部分，依應用而不同的部分留給使用者。

表裡「服務能自己啟動回來」這一項，業者在硬體維護後重新啟動虛擬機時要成立，主機裝了核心更新、排程自動重開機時也要成立。要確認的是服務的 unit 處在 enabled、容器設了 restart policy、主機防火牆的規則寫進了永久設定，最可靠的確認是在有人在場的維護時段手動重開一次，見 長期上線主機的維護項目：會累積的資料、定期讀的 log、對外入口的盤點、安全更新、會到期的設定與檢查間隔的推算〈會老化的軟體：各條更新管道與更新後的重開機〉。

網路層攻擊的處置（流量清洗、邊緣網路）見 9.15 無預警瞬時大流量 的〈體積型攻擊（DDoS）的處置：流量清洗與邊緣網路〉。以短網址服務為例，最可能遇到的攻擊是以正常的 HTTPS 請求大量掃描短碼、對轉址路徑灌請求。這些請求在網路層與一般使用者相同，業者的網路層防護不會攔下，要由入口的限流與掃描偵測處理；前面加一層 CDN 或 WAF，是把應用層的第一道過濾交給 CDN 業者，規則仍然要自己設定。各業者的防護範圍與處置方式寫在各自的服務條款與文件裡，選用前查自己那一家。

延伸閱讀：主機只有一台時、觀察者改由第三方提供時、exporter 的接法與冗餘的選擇

• 還沒有第二台主機、服務與監控在同一台時看不到哪些故障，心跳監看、外部探測與主機內部探測並排時怎麼判讀，見 4.28 單台主機的監控盲區與失效域以外的觀察者。
• 心跳監看或外部探測改由第三方服務提供時，挑選條件與 Alertmanager 的接法，見 第三方心跳監看與外部探測服務；自架 healthchecks 時同一篇的 ping 網址、/fail 與暫停也適用。
• 監控主機與服務主機之間的 VPN 要開到多寬、限制放在哪一端才在雲端主機被入侵之後仍然成立、異地備份的存取金鑰要拿掉哪些權限，見 7.43 兩個網路之間的連線安全。
• 監控主機已經分出去、要把各主機的 exporter 接上時，綁定位址、目標清單、主機標籤與主機消失的偵測，見 多台主機的指標收集。
• 決定做應用程式的副本之後，要選 active-passive 還是 active-active、資料怎麼同步，見 冗餘設計模式；每多一台要花多少、值不值得，見 高可用的成本。

監控與服務共用失效域時看不到的故障：主機停機、使用者路徑中斷與告警鏈中斷

監控要判斷一件事，有兩個條件：監控自己的程序在運作，以及它所在的位置看得到那件事。同一台主機上的 Prometheus 讀得到主機與容器的資源、每個服務的指標，也能從主機內部對各服務發探測請求，這些都在它的位置看得到。它與服務共用同一個失效域（failure domain）：同一台主機、同一個網路出口、同一個雲端帳號。下面三種故障，監控在自己的位置上看不到，或看到了也送不出告警：

主機整台停掉。 當機、斷電、雲端業者的維護重開、帳號因為付款失敗被停權，Prometheus 與 Alertmanager 跟著服務一起停。通知端的結果是什麼都沒收到，而「什麼都沒收到」與「一切正常」在收件匣裡看起來相同。

使用者到主機的路徑中斷。 網域過期、DNS 設定改錯、TLS 憑證過期、雲端業者的網路故障、防火牆規則擋掉外部連線，主機內部的服務都在運作，而使用者連不進來。主機內部的探測走的是容器網路或 127.0.0.1，不經過 DNS、不經過公開的網路入口與 TLS，所以照樣回報成功。以 4.27 主機過載時的監控告警 那個短網址服務為例，它的探測程式 Gatus 跑在同一個 Compose 專案裡，連的是服務名稱，量到的是「容器之間通不通」，不是「使用者連不連得到」。

告警鏈中斷。 規則照常成立，而告警送不到人手上，分成兩種。告警鏈停掉：Alertmanager 停了、規則檔沒有載入、Prometheus 連不到 Alertmanager。通知送不出去：Alertmanager 在運作，而某一條通知管道的網址打錯、外部的推播服務拒收。通知送不出去時，Alertmanager 會留下失敗的計數，Prometheus 可以把它寫成告警（見 Alertmanager 的通知管道 的〈通知送不出去的偵測〉）；而這條告警本身也要經過某一條通知管道，唯一的管道壞掉時它同樣送不出去。

主機停機與告警鏈中斷，是監控與它要判斷的對象一起停掉，或監控的告警出不去；使用者路徑中斷，是監控所在的位置不在使用者的路徑上。這兩類成因都不是在同一台主機上把監控做得更可靠（多跑一份 Prometheus、加大資源）解決得了的，因為多出來的那一份同樣在這台主機上、同樣不在使用者的路徑上；要的是一個位置在主機失效域以外、而且能照使用者路徑發請求的觀察者，下文稱為失效域以外的觀察者。它送出的訊號稱為頻外訊號（out-of-band signal，簡體中文資料常寫作「帶外」）。

主機過載是另一種情形：Prometheus 與 Gatus 都還在運作，而它們自己也在等 CPU，量到的延遲混進了監控本身的等待，判讀見 4.27 主機過載時的監控告警 的〈探測程式與 Prometheus 在過載主機上的 CPU 等待〉。

頻外訊號：心跳監看與外部探測

失效域以外的觀察者送出的頻外訊號有心跳監看與外部探測，兩者經過的路徑不同，所以各回答一個問題、彼此不能取代：心跳走的是監控本身送出告警的那條路，外部探測走的是使用者到服務的那條路。送出的方向也不同：心跳由被觀察的一方送出，觀察者在它缺席時通知；外部探測由觀察者主動發出請求，看回應。

心跳監看：監控與送出心跳的那條路還在不在運作

心跳監看（dead man’s switch）把判斷反過來：監控持續對外送出「我還在」，觀察者在約定的時限內沒收到就通知。時限由兩個值組成：週期（period，預期的心跳間隔）與寬限（grace time，容許的延遲），距離最後一次心跳超過兩者的總和就判定中斷。Prometheus 上的做法是一條永遠成立的告警規則（Watchdog），Alertmanager 定時把它經由一個專用的 receiver 送到觀察者的網址。主機整台停掉、主機對外的連線斷掉，以及告警鏈停掉的各種情形（Alertmanager 停了、規則檔沒有載入、Prometheus 連不到 Alertmanager、Watchdog 的路由設錯），心跳都會中斷。中斷的時間點大多在週期加寬限之後；停掉的是 Prometheus 時再晚一段：Prometheus 送給 Alertmanager 的告警帶著結束時間，Prometheus 停掉之後，Alertmanager 在這個結束時間之前照常重送心跳，依 Prometheus 的原始碼這段重送期約是 4 個評估週期（評估週期短於 1 分鐘時以 1 分鐘計），這裡沒有實測。

心跳只走送到觀察者的那一個 receiver，所以它不涵蓋通知送不出去的那一種：ntfy 的網址打錯、推播服務拒收時，心跳照常送達。這一種由通知送不出去的偵測發現，送到心跳監看服務上另一個專用檢查項目的回報失敗端點，設定見 第三方心跳監看與外部探測服務 的〈Alertmanager 的 receiver 與路由：心跳與送失敗的通知〉。心跳監看也不回答使用者連不連得到服務：主機照常運作、監控照常送心跳時，DNS 改錯讓使用者全部連不進來，心跳監看看不出任何異常。心跳也分不出故障與入侵：監控主機被入侵時，攻擊者可以用它存著的心跳網址自己送心跳，判讀見 7.43 兩個網路之間的連線安全 的〈監控主機在信任關係裡的位置〉。

成立的條件有三個。觀察者在送出心跳那台主機（跑 Alertmanager 的那一台）的失效域以外：跑在同一台主機上的觀察者，主機停掉時跟著停。觀察者的通知管道不依賴那台主機，也不寄到被監看服務網域底下的信箱：觀察者也透過那台主機上的推播服務通知時，心跳中斷的通知會走那條已經停掉的路；被監看服務的網域過期時，寄到那個網域的所有通知會一起收不到，觀察者的通知不能也在其中。Alertmanager 實際送出心跳的最長間隔（repeat_interval 加一個 group_interval，因為 Alertmanager 只在 group_interval 的時間點檢查要不要重送）要小於觀察者設定的週期加寬限，參數的寫法見 Alertmanager 的通知管道 的〈Watchdog：告警鏈本身的心跳〉。

沒有 Prometheus 的主機也能送心跳：以 systemd 的計時器定時對心跳監看服務送請求，做法見 服務掛了怎麼自動知道 的〈第三層：整台機器死掉怎麼辦（監控自己的盲點）〉。排程工作（備份、匯出）同樣可以在跑完時自己送一次心跳，那時心跳回答的是「工作有沒有跑完」。

外部探測：使用者看到的結果

這一篇的外部探測指從服務主機的失效域以外，在使用者連線出發的那一側網路照使用者的路徑對服務發請求：公開服務的使用者從公開的網際網路來，探測就解析公開的網域、經過 HTTPS 與公開的入口，檢查回應的狀態碼與內容（也叫 synthetic monitoring 或 blackbox 探測，多地區探測的做法見 4.10 Client-side / Synthetic / RUM 的〈Synthetic Monitoring〉）；只在公司內網或 VPN 裡提供的服務，探測端要放在那個網路裡。站內 多容器服務的存活監看 的外部探測是從同一台主機上另一個容器發出的，「外部」是相對於服務的程序；它在服務程序卡住時有用，而主機停掉時跟著停，不是這裡要的觀察者。

外部探測回答的是使用者連不連得到、回應對不對，涵蓋主機整台停掉與使用者路徑中斷。它不回答監控還在不在運作：服務照常回應、Alertmanager 已經停了一整天，外部探測全部成功。

成立的條件是探測的位置與路徑：探測端在使用者所在的那一側網路、服務主機的失效域以外，請求打的是使用者用的網址，而不是主機的 IP 或內部的服務名稱；失敗通知同樣不寄到被監看服務網域底下的信箱。判斷成功的方式也要選對，只看狀態碼時入口回一個錯誤頁也可能是 200，比對回應內容的做法見 第三方心跳監看與外部探測服務 的〈外部探測服務的挑選條件〉。

觀察者的位置：第三方服務、另一個失效域的主機（含互相監看）與另一個業者的排程平台

心跳監看與外部探測要避開的失效域不同：心跳監看的觀察者要避開送出心跳那台主機（跑 Alertmanager 的那一台）的失效域；外部探測量使用者路徑時要避開服務主機的失效域，兩台主機時用來分辨連線中斷的那一個另外要避開監控主機（見本節最後的清單）。只有一台主機時，跑 Alertmanager 的主機就是服務主機，兩種觀察者要避開的是同一台；監控搬到另一台主機之後，兩者分開。這個位置有幾種來源。

第三方服務。 心跳監看與外部探測都有現成的託管服務，它們跑在別人的機房與網路上。業者維運的意思是業者自己知道服務停了，購買服務的一方並不會因此收到通知：檢查項目被刪除、業者自己停擺，心跳都只是不再被看著。購買服務的一方能做的是定期演練（見〈心跳監看、外部探測與內部探測並排時的判讀〉的演練那一段），以及訂閱業者的狀態頁。代價是告警的內容（標籤、主機名）與被監看服務的公開網址會送到第三方，以及多了一個要管理的帳號與私密網址。

另一個失效域的主機。 心跳監看的邏輯不複雜（記下最後一次心跳的時間，距離它超過週期與寬限的總和就通知），開源的心跳監看服務也可以自架。自架的觀察者成立的前提有兩個。第一，觀察者所在的主機與它要避開的那台主機不共用失效域：換一個雲端業者，或一台在雲端、一台在地端，是分開的起點；分開之後還要逐項比對兩台仍共用的依賴（付款方式與帳號、通知用的郵件服務、DNS 業者），比對方式見 Failure Domain 的〈判讀方式〉。第二，觀察者自己停掉時有人知道，這又分成兩種情形。主機停掉：只多租一台主機專門跑觀察者、監控仍留在服務主機上時，由服務主機上的 Prometheus 探測那一台；監控搬到第二台時，由互相監看處理，服務主機上跑心跳監看程式，接收監控主機送出的心跳，監控主機讀取服務主機的指標（讀不到時，監控主機上那個讀取對象的 up 變成 0，這也是一種由觀察者主動發出的訊號），服務主機停掉時由監控主機上的 Alertmanager 通知值班的人，任一台主機停掉，另一台都會發現。監看程式這個程序停掉、主機照常運作：由監控主機對它發探測。兩邊的通知管道也要彼此獨立：服務主機上的監看程式直接寄 email 或走另一個推播服務，不經過監控主機上的 Alertmanager。心跳的接收端點不對外開放、監看程式怎麼被探測、兩台同時停掉的風險，見 小型服務的兩到三台主機配置 的〈兩台主機互相監看〉。

另一個業者的排程平台。 自己寫的觀察者不一定要跑在一台主機上，也可以是另一個業者的排程或無伺服器平台上、以組織自己的帳號執行的程式。它與主機的故障分屬不同失效域，帳號、付款方式與通知管道仍要逐項比對；資料留在自己的帳號裡，而那個業者也是要多管理的一個帳號。這種觀察者要能接收心跳並保存最後一次心跳的時間，它自己停掉時，可以由主機上的 Prometheus 定時探測它來發現；本篇沒有實作這一種。

兩種頻外訊號的位置分開選：

• 心跳監看：手上有一台與跑 Alertmanager 那台主機不共用失效域、它停掉時也會被發現的主機，就放在那台，告警內容留在自己手上，也不必多管理一個第三方的帳號；沒有，就用第三方服務，或另一個業者的排程平台。告警內容不能離開組織時，第三方的心跳服務也還有一種用法：Alertmanager 的 webhook 一律送整份告警 JSON，改由主機上的排程確認 Watchdog 還在之後對 ping 網址送一個不帶本文的請求，送到第三方的就只剩「還在」這個訊號。這條路繞過了 Alertmanager 送出告警的那一段，所以心跳不再涵蓋 Alertmanager 的送出；本篇沒有實作這種送法。
• 外部探測：量使用者路徑時放在服務主機的失效域以外，通常是第三方的外部探測服務；只有一台主機時就滿足了。兩台主機互相監看時，還要有一個探測負責分辨「兩台之間的連線斷了」與「服務主機停了」：監控主機讀不到服務主機時，兩者看起來相同。只是兩台之間的 VPN 斷掉時，監控主機對服務公開網址發的探測走網際網路、不走 VPN，照樣成功，已經分辨得出來（監控主機的流量若被 VPN 改走隧道，這一點就不成立）；兩地之間的網路路徑一起斷掉時，放在監控主機上的探測端與讀取一起失敗，值班的人會把它判成服務主機停了。所以這一個探測放在服務主機與監控主機兩者的失效域以外，它也是兩台同時停掉時唯一還看得到的觀察者。

心跳監看、外部探測與內部探測並排時的判讀

心跳監看、外部探測與主機內部對同一功能的探測各自站在不同的位置，故障發生時三者的組合指向不同段的失效。下表以單台主機加第三方服務的配置為準，並假設沒有收到送失敗通知的那個檢查項目寄來的通知。主機內部探測要打外部探測檢查的那一個功能，而且直接打應用程式、不經過反向代理（例如外部探測打一條測試短網址，內部也直接對應用程式要同一條短網址）；只看「有沒有任何告警成立」分不出失效在服務還是在路徑，而 4.27 那個範例的 Gatus 探的是健康端點，與外部探測不是同一個功能，要另外加這一條。內部探測若經過反向代理，入口元件的故障會落在「服務本身」那一列。

心跳中斷的兩列，主機內部探測的結果靠監控送出，監控停了或送不出去時結果到不了人手上，所以這一欄不能拿來判斷，這段時間沒有收到內部告警也不代表服務正常。表上沒有通知送不出去的那一種：三欄都可以是正常，訊號是送失敗通知的那個專用檢查項目寄來的 DOWN（檢查項目的名稱就指出是送失敗通知），它本身指出了失效所在。兩台主機互相監看時，心跳欄看的是服務主機上的監看程式有沒有收到監控主機送來的心跳：服務主機整台停掉時，監看程式跟著停，心跳欄不會有任何通知，主機停機的告警由監控主機發出；兩地之間的連線斷掉時，兩邊各自發出對方停機的通知，而外部探測成功。

只有主機內部的監控時，所有判斷都來自主機內部，排查從登入主機看程序與日誌開始。多了失效域以外的觀察者之後，各觀察者看到的組合先指出失效在哪一段，再決定下一步：指向服務本身時，照內部告警與應用程式的日誌查；指向路徑時，先查主機上入口元件的紀錄（反向代理的日誌、憑證續期的紀錄），沒有異常再往主機外查 DNS、網域與業者的狀態頁；指向主機整台或它的網路時，從主機外一層層確認哪裡斷，見 機器連不到或起不來；指向監控本身時，查 Prometheus 與 Alertmanager 的程序狀態（見 程序、服務與狀態怎麼判），再查規則、路由與主機對心跳監看服務的對外連線。

心跳監看與外部探測的失敗通知平時不會發出，所以接好之後要演練，而且要定期再演練，因為第三方那邊的檢查項目被刪除時同樣沒有任何訊號。兩種演練各自隔離一段路徑：停掉 Alertmanager 讓告警鏈中斷，確認心跳監看在週期加寬限之後通知；在外部探測服務上把探測的目標網址暫時改成不存在的路徑，不必停掉服務就模擬出使用者路徑的失敗，確認外部探測的失敗通知會到。演練完重新啟動 Alertmanager、把探測網址改回原值。心跳演練的實測時間線見 第三方心跳監看與外部探測服務 的〈心跳中斷的演練〉；演練的範圍、安全邊界與成功標準怎麼定，見 Game Day，驗證備援的一般原則見 4.25 觀測共命運失效 的〈驗證備援：不測的備援是薛丁格的備援〉。

延伸閱讀：觀察者改由第三方提供、主機變成兩台、失效範圍擴大到觀測系統與主機過載

• 觀察者改由第三方服務提供時，要挑的條件（服務的位置、通知管道、告警資料留在哪裡）、healthchecks 的 ping 網址與 /fail、Alertmanager 送心跳與送失敗通知的路由，見 第三方心跳監看與外部探測服務。
• 主機從一台變成兩台時，監控搬到另一個失效域、兩台之間的 VPN 與互相監看、雲端業者處理與不處理的故障，見 小型服務的兩到三台主機配置。
• 失效的範圍從一台主機擴大到觀測系統本身時，依賴耦合、反噬與供應商單點三種機制，狀態頁的失效域隔離與人在盲飛時的應對，見 4.25 觀測共命運失效。
• 主機沒有停而是過載時，監控自己也在等 CPU 的訊號與資源隔離，見 4.27 主機過載時的監控告警。

概念位置

失效域是冗餘與監控設計的單位。兩台主機放在同一個機房，機房斷電時一起停，冗餘只防得了單台主機的故障；監控與服務跑在同一台主機，主機停掉時監控跟著停，發不出告警。所以判斷一個備援或一個觀察者有沒有用，先問它與被保護、被觀察的對象共用了哪些依賴。觀察者落在失效域以外時，它送出的訊號稱為 Out-of-Band Signal。失效域與 Blast Radius 看的是同一件事的兩端：失效域問「哪些元件會一起停」，影響範圍問「它們停掉時哪些使用者與功能受影響」。

實體的依賴有由內而外的層次：程序、主機、機房（雲端的可用區）、區域、業者（業者全域的控制平面）。越往外的層，一次停掉的元件越多，發生的頻率通常也越低；在越外層把元件分開（不同主機、不同機房、不同區域），成本越高。帳號與計費、TLS 憑證、網域與 DNS、部署管線這類依賴不在這條序列上，它們橫跨各層：兩台在不同區域的主機，仍可能因為同一個帳號被停權、同一個網域過期而一起停。

可觀察訊號與例子

服務與 Prometheus、Alertmanager 放在同一台雲端主機上：主機被業者維護重開、或帳號被停權時，所有元件一起停，通知端什麼都沒收到，與「一切正常」看起來一樣。把 Alertmanager 的心跳送到另一個雲端業者上的監看服務，心跳中斷由那一邊通知，這條通知路徑就不在主機的失效域裡。

共用的依賴常常藏在設定裡：兩台「分開」的主機掛著同一個網路檔案系統、讀同一份祕密管理服務、用同一個 DNS 業者，三者任一個停掉，兩台一起受影響。狀態頁與主站共用 DNS 是同一種情形（見 Status Page）。

判讀方式

判斷兩個元件的失效域分開到什麼程度，逐項列出它們各自的依賴（主機、網路、電源、雲端帳號與付款方式、DNS、TLS 憑證、部署管線，以及通知管道：寄送通知的服務、收件信箱的網域、推播服務），共用的每一項都是一起停掉的原因。判讀的產出是剩下的共用依賴清單，以及每一項的處置。接不接受依兩件事判斷：這一項失效的頻率，以及兩者一起停掉的代價（停機代價怎麼估見 高可用的成本）。處置有三種：接受並寫明理由；把兩者分開；分不開時（例如兩台主機都服務同一個網域），改放一個在那一項以外的觀察者，讓它一起停掉時至少有人知道。列在紙上的依賴不一定完整：共用的依賴常在停掉其中一個元件時才浮現（另一個跟著出錯，或觀察者沒有發出通知），所以分到不同失效域之後的判斷，以實際停掉其中一個的結果為準。小型服務怎麼用兩到三台主機分開失效域，見 小型服務的兩到三台主機配置。