監控項目

監控項目就是您希望被盯著的一樣東西，以及判定它是否健康的規則。共有三十種。其中大多數會從我們的網路發出請求並判斷回應；另有兩種則是等待您那端把東西送過來；還有四種會收集您的路由器匯出到您自己私有探針上的流量資料。

各種類型

網站與網路

類型	檢查內容
`http`	某個 URL 是否有回應，包含狀態碼、回應時間，以及選擇性指定、必須出現在回應內容中的一段文字。
`ping`	某台主機是否回應 ICMP。
`tcp`	某個連接埠是否接受連線。
`udp`	送出的資料包是否收到回覆。
`dns`	某個名稱是否能解析，並可選擇檢查解析結果是否為您預期的記錄。

憑證與網域

類型	檢查內容
`ssl_cert`	憑證還剩多久到期，以及憑證鏈是否有效。
`tls_audit`	九次交握：每一個 TLS 版本、各個弱加密套件家族、金鑰長度，以及安全性標頭。我們無法執行的探測會回報為未測試，而不是視為通過——請見下文。
`domain_expiry`	網域註冊還剩多久到期。
`blacklist`	某個位址或網域是否出現在主要的封鎖名單上。

郵件

類型	檢查內容
`smtp`, `imap`, `pop3`	伺服器是否能以自己的協定完成一次真正的對話，並協商 STARTTLS。它從不進行驗證：要證明登入可用，就得為每個監控項目保存一組能用的信箱密碼。
`mail_posture`	其他人是否能信任該網域寄出的郵件——SPF、DKIM、DMARC。

基礎架構協定

它們之所以存在，是因為對連接埠做 tcp 檢查，幾乎無法說明它們的狀況。SMSC 在不再讓任何人完成 bind 之後，仍會長時間接受 TCP 連線；SIP 堆疊可能在通訊端維持開啟的情況下卡住；憑證早已過期的 XMPP 伺服器，照樣能完成 TCP 交握。

類型	檢查內容
`snmp`	輪詢一組 OID，逐一與門檻值比較，每項檢查各有自己的嚴重程度。
`smpp`	完成 bind 與 unbind。它從不送出訊息。
`sip`	送出 `OPTIONS`。非 2xx 的最終回應算是效能降低，而不是停機：Proxy 對陌生來源回覆 405，表示它運作正常，只是拒絕了我們。
`xmpp`	開啟一個串流並協商 STARTTLS。
`grpc`	呼叫 `grpc.health.v1.Health/Check`。gRPC 把狀態放在 HTTP/2 trailer 裡，因此失敗的呼叫照樣回應 200 OK——這正是 `http` 監控無法取代它的原因。Pro 方案及以上。

資料庫

Pro 及以上。對 5432 通訊埠做 tcp 檢查只能證明有東西接受了連線，而資料庫每一種值得關心的故障都會讓通訊端繼續開著：處於崩潰復原中的 Postgres、被外洩連線的應用占滿的連線上限、密碼已過期的角色、被改名的資料庫、沒有掛載上的資料目錄。所以這些檢查會建立連線、完成登入，並向伺服器問一個最簡單的問題。

類型	檢查什麼
`postgres`	連線、驗證並執行 `select version()`。資料庫名稱為必填，因為 Postgres 沒有不指定資料庫就能連線這回事。
`mysql`	同上，並涵蓋 MariaDB——同一套通訊協定，而不是第二種檢查。
`redis`	連線、驗證並傳送 `PING`。仍在載入資料的副本會回應 `-LOADING`，這會作為獨立的原因回報，而不是逾時。
`mongodb`	連線、驗證並執行 `ping` 指令。支援 `mongodb+srv` 位址，這也是存取託管 MongoDB 的常用方式。
`mssql`	透過 TDS 連線、登入並執行 `select @@version`。

它們都不讀取也不寫入任何資料。這是可用性檢查，不是合成交易：請給它一個除連線之外什麼都做不了的帳號。

憑證以明文儲存，因為執行檢查的探測器會原樣收到該設定。因此這五種只會在獲准處理個人資料的探測器上執行，這與 snmp 和 smpp 的限制相同。

這意味著兩種位置之一。你自己的私有探測器，這也是這些檢查的設計目標：它執行在你自己網路內的硬體上，設定因此從不離開你的基礎設施；而且它通常是唯一能夠存取到值得監控的資料庫的東西——位於 VPC、專線或白名單之後的資料庫，對任何外部網路（包括我們的網路）都是不可達的。否則就是我們自己在歐盟的觀測點，用於確實可公開存取的資料庫。

容器

Pro 及以上。檢查容器發布的連接埠，回答的是它前面的代理。在重新啟動策略之下反覆當機的容器每次只上線幾秒，失敗的 HEALTHCHECK 不會關閉連接埠，因記憶體耗盡被終止後又重啟，看起來只像一次慢請求。這三件事 Docker 引擎都知道。

類型	檢查內容
`docker`	依名稱或 ID 向引擎查詢一個容器。執行中即為正常；`HEALTHCHECK` 不健康，或容器已暫停、已結束、因記憶體耗盡被終止，即為中斷；健康檢查仍在啟動中，或重新啟動策略在最近五分鐘內重啟過它，即為降級。它從不啟動、停止或執行任何東西。

能存取引擎 API 就等於擁有那台主機的 root 權限，所以端點及其用戶端憑證都是憑據，這一類型只在獲准處理個人資料的探針上執行。只有以 DOCKER_SOCKET_ENABLED=true 啟動的探針才會開啟 unix socket——這是你在自己引擎旁邊的私有探針上設定的，我們的探針從不設定；在其他任何地方，檢查都會棄權，而不是把你的容器回報為中斷。帶用戶端憑證的 tcp:// 或 https:// 端點在兩者上都可用。

網路流量

Business 及以上方案。可用性檢查能告訴您連線有回應；它無法告訴您連線已經飽和、某個備份工作在中午把它塞滿，或流向您 Web 層的流量悄悄降到了零。您的路由器和交換器本來就在統計這些，而且可以匯出。這些類型收集這份匯出，把它轉成速率、依協定的分布，以及最繁忙的連接埠和位址。

類型	檢查內容
`netflow`	來自路由器的 NetFlow v5 與 v9，UDP 2055 連接埠。範本隨到隨學；早於其範本抵達的記錄會被計數並丟棄，絕不靠猜測。
`jflow`	來自 Juniper 路由器的 J-Flow，線路上就是 NetFlow，使用同一連接埠。
`ipfix`	IPFIX，接替 NetFlow v9 的 IETF 標準，UDP 4739 連接埠——包括可變長度欄位與廠商專屬欄位。
`sflow`	來自交換器的 sFlow v5，UDP 6343 連接埠：抽樣的封包標頭，穿過 VLAN 標籤解析到 IPv4 或 IPv6，並依交換器回報的抽樣率換算回來。

每個門檻都是選填的——最大位元速率、最小位元速率、最大封包速率。高於或低於其中之一即為降級。都不設定時，監控項目只記錄並繪製流量圖表，不會因數值告警。匯出器停止傳送的時間超過您允許的上限即為中斷；傳送錯誤協定的匯出器——把 sFlow 傳給 NetFlow 監控項目——同樣中斷，並附上說明原因的訊息。

這些類型只在您自己的私有探針上執行。流量匯出走 UDP，不帶任何驗證：放在我們共用網路上的收集器只能信任傳送方位址，而任何人都能偽造或冒用這個位址。放在您網路內部的探針，只有您自己的路由器能連到。您的流量記錄也留在您那邊——其中包含您網路上人員的位址，所以探針在記錄抵達之處完成彙總，只把速率和前十名排行表傳給我們。請以 FLOW_COLLECTOR_ENABLED=true 啟動探針，發布 UDP 連接埠，將路由器指向它，並在建立監控項目時選擇這個探針。

會主動回報給我們的東西

類型	檢查內容
`heartbeat`	cron 工作或批次程序在結束時呼叫一個 URL。超過間隔仍然毫無動靜，就是失敗。請把它用在其他方式都看不到的地方——每晚的備份、每小時的匯入。
`server_agent`	安裝在您自己機器上的小型代理程式，回報 CPU、記憶體與磁碟。請從監控項目頁面上的連結，用 `curl` 自行取得它。

執行頻率

間隔由您決定，下限則由您的方案決定。Free 每分鐘檢查一次，Starter 每 45 秒，Pro 每 30 秒，Business 每 15 秒，Enterprise 每 5 秒。

有四種類型不論方案為何，都有自己的下限，因為答案不會每分鐘改變，問得更頻繁只是雜訊，而且會增加別人伺服器的負擔：

類型	最頻繁的檢查
`blacklist`	每小時
`ssl_cert`	每六小時
`domain_expiry`, `mail_posture`, `tls_audit`	每天兩次

間隔不等於您多快得知服務中斷

這一段值得讀兩遍。單一次檢查失敗並不會開啟事件。監控項目必須連續失敗三次——這就是 confirmations 設定，預設值是三——之後才會通知任何人。

不過，這並不是間隔的三倍。當一次檢查失敗，下一次檢查會被提前，而不是等完整個間隔，因此一個五分鐘的監控項目，確認中斷所需的時間遠少於十五分鐘。一筆結果只能讓下一次檢查提前，絕不會讓它延後。

如果您寧可早一點被叫醒、偶爾白忙一場，就把 confirmations 調低。對於您明知會忽好忽壞的目標，則調高它。

檢查會在各地點之間輪替

我們從數個地點進行檢查，每個間隔用一個，輪流進行。一個五分鐘的監控項目搭配三個觀測點，代表每個觀測點每十五分鐘看它一次，而監控項目本身仍然每五分鐘被檢查一次。

這正是確認機制有意義的原因：連續三次失敗，是從三個不同地點看到的三次失敗，所以某個探針單純連不上您的伺服器並不礙事——下一個區域會成功，連續失敗的計數也就歸零。

一處失敗而另一處正常，算是效能降低，而不是停機。停機應該是指您的網站無法連線，而不是某一個觀測點看不到它。它仍然計為失敗，事件也照樣會開啟，嚴重程度為效能降低。

防火牆不是服務中斷

在某個地點被封鎖的網站，會讓來自那裡的每一次檢查都失敗，而在其他各地一切正常。若把這算成停機時間，您的可用性數字就會變成在描述我們的路由，而不是在描述您的服務。

因此，從未連上過某個監控項目的區域，在三次失敗之後就會被排除在該監控項目之外。而曾經連得上、如今連不上的區域，則會永久繼續計入——因為從那裡看這是真正的中斷，隱瞞它只會更糟。

如果是網站周圍的世界變了——政府封鎖、路由消失、後來才加上的地區限制——您可以在監控項目的頁面上對它重新校正。這會捨棄該監控項目所有區域的歷史紀錄，讓目前的行為成為新的基準。它是以單一監控項目為單位，而且是刻意設計的，因為光靠量測無法分辨永久封鎖與永久中斷。

檢查在哪裡執行，以及我們往那裡送出什麼

有些觀測點位於歐洲經濟區之外。設定中可能含有個人資料的檢查——帶有請求標頭、帶有請求內容的檢查——只會從歐洲經濟區內部執行。這是由排程器強制執行，而不是靠規範約束，而且每次建置都會對真實資料庫進行測試。snmp、smpp 以及五種資料庫檢查也以同樣方式受限，因為在它們當中，憑證資料本身就是協定。

未測試不等於通過

就 tls_audit 而言，每項探測有三種結果而不是兩種：支援、拒絕，或未測試。Node 的 OpenSSL 3 既未編入 RC4 也未編入 3DES，因此這兩個家族永遠無法由我們的機群提出——而在這些項目下保持沉默，會被讀成「我們查過了，它們已經關閉」，這恰好是在 TLS 稽核最常被用來查證的發現項目上，給出虛假的全部正常。

相依關係

告訴監控項目它相依於什麼——資料庫、閘道、上游 API——如此一來，當被相依的對象停機時，它後面的那些項目會被標記為連帶結果，而不是各自開啟事件。只有一個事件，而不是四十個，而且頁面指出的是根本原因，不是症狀。

維護時段

排定一個時段，只要它還開著，就不會呼叫任何人。請在您明知會讓服務下線的部署時使用它。預設情況下檢查照樣執行、照樣記錄，因此這些分鐘與其他時間一樣計入可用性數字——時段拿掉的是警示，而不是歷史紀錄。關掉「繼續檢查」，時段開啟期間就不會進行任何檢查，歷史紀錄中留下的是一段空白，而不是一次下滑。維護時段可以按日、按週或按月重複，而且每一次發生都會攔下警示，不只是第一次。

暫停

已暫停的監控項目不會被檢查，也不會計入任何統計。它會保留歷史紀錄，所以暫停之後再恢復並不會遺失資料。