成功率之外，還有哪些資訊？KamuiDash 如何量測服務可用性

即使最近 30 天的成功率很高，最後一次檢查若已過時，就無法判斷服務目前是否正常。即使收到 HTTP 200，也還需要確認：回傳的是否為預期頁面？

KamuiDash 在服務狀態頁公開定期功能檢查的結果，作為 SLI（服務水準指標）。個人方案未訂定 SLA，但使用者可以查看實際觀測結果，以及量測所依據的條件。

本文說明成功的判定條件、缺測的處理方式，以及如何避免持續將過時的結果顯示為「正常」。

先確認，這個數字量測的是什麼

目前公開的應用程式實績，來自單一執行個體的參考應用程式，以及兩個執行個體的儀表板登入頁面。這並非所有使用者應用程式或請求的彙總成功率。

其他功能也透過預先定義的監控操作進行檢查。伺服器即使正在執行，若無法儲存檔案，儲存空間仍不能算是可用。

這種定期執行功能檢查的方式稱為合成監控。即使使用者流量很少，也能依照固定條件確認服務是否運作。

我們每分鐘存取一次應用程式的公開頁面，並以在 10 秒內收到 HTTP 200 與預期內容作為成功條件。只看狀態碼，可能會漏掉回傳錯誤頁面的情況。

若收到的只是快取頁面，就無法確認應用程式在該時點是否能回應。因此，監控請求會加入避開快取的設定；若從回應標頭判定為快取回應，就不將其列入有效量測。

登入頁面的檢查不包含實際登入操作。另外，單一與兩個執行個體的配置觀測的是不同應用程式，並非只比較執行個體數量影響的實驗。

同樣是 99.0%，觀測範圍也可能不同

成功率是有效檢查中成功的比例。

我們將失敗與缺測分開處理。觀測到回應異常或逾時時，計為失敗；若監控工作未執行，或快取回應被排除等，沒有可供判斷的結果，就列為缺測。

以下兩個說明範例都預計執行 1,000 次檢查。範例 A 每次都有結果，範例 B 則有 100 次缺測。

缺測不計入分子或分母，因此 990 ÷ 1,000 與 891 ÷ 900 都是 99.0%。但範例 B 剩下 100 次檢查對應的狀態仍無從得知。因此，每日詳細資訊也會顯示有效檢查次數與預期檢查次數。沒有觀測結果的期間，不會以正常狀態補齊。

若服務包含多種操作，我們會顯示各操作成功率中的最低值。例如，儲存成功率為 99%，讀取與刪除皆為 100%，則顯示 99%。這樣可避免大量成功的讀取，將儲存操作的問題稀釋在平均值中。

用語補充：SLI 是實際觀測結果，SLO 是維運目標。狀態頁顯示的實測值與目標值，並不代表服務水準協議（SLA）所提供的服務品質保證。

「目前正常」也有有效期限

歷史成功率與目前是否可用，是不同的資訊。最後一次檢查若已過時，就無法只憑過去的正常結果判斷目前狀態。

在應用程式的 HTTP 監控中，最後一次量測結果超過 3 分鐘，就會將目前狀態改為「未知」。

若無法取得狀態資料，也不會繼續保留先前的正常顯示。「未知」並非斷定發生故障，而是表示目前沒有足夠資訊可以判斷狀態。

此時仍會保留歷史成功率與最後一次確認的時間。將目前狀態與歷史實績分開，才能如實呈現已確認的資訊。

量測與事故報告，各自扮演不同角色

自動檢查能確認的是，操作是否符合預定條件。至於原因、影響範圍與處理進度，則由維運人員記錄，與數據一同呈現。

為了在應用程式發生問題時，仍有地方可以查詢狀況，公開狀態頁的交付與應用程式執行環境分開。除了對公開頁面進行 HTTP 檢查，資料庫操作也會在服務端執行，再將結果傳送至監控端。

量測依排程執行，不受頁面瀏覽次數影響。應用程式 HTTP 監控以「監控目標與每分鐘的量測時段」唯一識別一筆紀錄，避免工作重跑時重複計數。

閱讀狀態頁時，建議一起確認的資訊

在 KamuiDash 的服務狀態頁，可以搭配查看以下三項資訊。

1. 成功率與統計期間

   應用程式涵蓋最近 30 天，其他服務涵蓋包含今天的 30 個日曆日。若服務有多種操作，會顯示其中最低的操作成功率。

2. 目前狀態與最後檢查時間

   除了歷史成功率，也能確認用來判斷目前狀態的結果，是何時取得的。

3. 每日歷史與事故報告

   每日詳細資訊列出有效與預期檢查次數。若有事故或維護報告，也請參考影響範圍與處理經過。

每分鐘一次的觀測，可能會漏掉兩次檢查之間的短暫中斷。成功率反映的是定期檢查結果，無法精確表示實際停機秒數。

除了成功率，還要知道量測了什麼，以及最近確認到什麼時點。KamuiDash 的狀態頁將這些條件一併呈現，讓使用者了解服務的運作實況。

前往 KamuiDash 服務狀態頁查看實績 →