UptimeLens 監控
透過 UptimeLens MCP 伺服器，在客戶自己的資源上設定與執行 UptimeLens 正常運行時間監控。此技能能將監控要求（如「監控此 URL」、「此次部署後應注意什麼？」、「什麼服務故障？」、「開啟一個事件」）轉換為正確的 MCP 工具呼叫序列。
使用時機
在監控設定與事件管理層面使用：
- 建立 HTTP/HTTPS 監控，並在部署後或針對新服務建議應監控的項目。
- 檢查目前哪些服務故障，並進行初步調查（狀態歷史、每項探測的根本原因、回應時間/可用性）。
- 排程維護時窗，讓部署或計畫性工作不會觸發人為通知。
- 建立監控依賴關係，使下游檢查在上游已故障時不會發出警報。
- 開啟、更新或解決事件。
當請求是關於回應傳呼（而非監控）時，請轉交：如需確認或暫停啟用中的升級通報、輪值交接，或檢查升級執行情況，請使用 uptimelens-on-call 技能。如需針對事件進行深入、引導式的根本原因調查，建議優先使用唯讀的 triage_incident MCP 提示（以及 get_root_cause 工具），而非在此編寫完整的分析腳本。
先決條件
- 已將 UptimeLens MCP 伺服器連線至此客戶端。讀取工具適用於所有方案。
- 寫入動作（
create_monitor、update_monitor、pause_monitor、resume_monitor、register_monitor_dependency、delete_monitor_dependency、create_incident、post_incident_update、resolve_incident、cancel_incident、reopen_incident、save_postmortem、add_incident_action_item、create_maintenance、delete_maintenance）需要使用讀寫 API Token 以及專業版（Pro）或更高方案。使用唯讀 Token 時，寫入工具將完全不會列出；在免費版方案中則會回傳FeatureNotAvailable。 - 部分讀取工具亦受方案限制。
get_root_cause（付費方案）與get_incident_analytics（Pro+）是硬性限制 — 低於對應方案會回傳FeatureNotAvailable錯誤；請比照下方寫入工具先決條件處理（告知使用者方案不符，不要重試）。query_metrics的百分位數是軟性限制 — 低於團隊版（Team）方案時，百分位數欄位會回傳 null，而非錯誤。
若某個寫入工具缺少或回傳 FeatureNotAvailable，請告知使用者哪一項先決條件未滿足，不要重試。
工具
這些工具來自 UptimeLens MCP 伺服器。請以完整名稱 UptimeLens:<tool> 引用 — 將 UptimeLens 替換為此客戶端中該連線所賦予的名稱，否則可能找不到該工具。
讀取（探索與上下文）：
UptimeLens:get_overview— 從這裡開始查詢「目前什麼服務故障？」：依狀態分類的監控數量、24 小時正常運行時間、進行中的事件，以及分組的個別故障 — 四十個以相同方式、針對相同目標故障的監控會以一次中斷而非四十筆資料呈現。當你需要完整的清單（名稱、標籤、ID）時，請改用list_monitors。UptimeLens:list_monitors— 監控項目及其目前健康狀態；可依status（正常/降級/故障/未確認故障/未知/未監控/維護中）、名稱或標籤進行篩選。這是查詢monitorId以用於其他大部分工具的主要來源，也是回答「什麼服務故障？」的答案。UptimeLens:get_monitor— 單一監控的設定與目前健康狀態（不含憑證）。UptimeLens:list_status_changes— 監控項目的正常/故障/降級歷史記錄及其持續時間；這是get_root_cause所需statusChangeId的來源。UptimeLens:get_status_change— 單一狀態變更及其上下文（前次與下次變更、涵蓋此期間的事件與升級執行）以及每個位置的檢查摘要：失敗次數、firstDownAt，以及最常見的errorCategory。可用於判斷中斷從何處開始以及如何確認；適用於所有方案。UptimeLens:get_root_cause— 針對單一狀態變更的每項探測網路診斷：DNS/連線/TLS 時間、路由追蹤、TLS 版本、SSL 憑證剩餘天數、錯誤類別。這是最豐富的「為什麼會故障」資料來源（付費方案）。UptimeLens:query_metrics— 針對單一監控在指定期間內的回應時間與正常運行時間統計（期間總結，非完整序列；百分位數為團隊版以上方案專有）。UptimeLens:get_monitor_availability— 單一監控的 SLA 檢視：正常運行時間百分比、停機時間、事件次數、MTTR、MTBF、回應時間統計。注意事項：如果uptimePct不存在，表示該期間沒有任何測量結果 — 並非 100%，所以請說該監控未被測量；longestIncidentSec是事件的實際時間，可能超過測量到的totalDowntimeSec— 這是正常現象，並非資料錯誤；uptimePct四捨五入至小數點後兩位，因此極短的停機時間可能顯示為 100.00 但同時有正數的停機時間；如果mtbfSec/mttrSec不存在，並非表示為零。UptimeLens:get_uptime_report— 針對整個帳戶在指定期間內的同類問題：時間加權正常運行時間、停機時間、針對 SLA 目標的錯誤預算，以及故障原因（causes）和確認來源所在位置（locations）。可使用預設期間（last_month、last_30d等）或明確日期。用於回答「上個月表現如何？」；單一監控請使用get_monitor_availability。UptimeLens:list_monitor_dependencies— 監控所依賴的上游監控（必須正常運作才能觸發其警報）。UptimeLens:list_monitor_dependents— 相反的查詢：依賴於此監控的監控 — 即其受影響範圍，用於區分根本原因與症狀。UptimeLens:list_incidents— 事件清單，最新者優先；預設為最近 7 天，除非傳入startDate/endDate。可依status、monitorId或source篩選。UptimeLens:get_incident— 單一事件的詳細資訊及其更新時間線與受影響的監控。UptimeLens:get_incident_analytics— 在日期範圍內的整體事件指標（MTTR、數量/趨勢、嚴重性/來源分佈、熱門監控）— Pro+。UptimeLens:list_maintenance— 維護時窗；status=active可回答「目前有任何項目在維護中嗎？」。UptimeLens:list_status_pages/UptimeLens:get_status_page— 向客戶發佈的狀態頁面以及哪些監控會顯示在頁面上（在決定涵蓋範圍時很有用）。
寫入（變更狀態 — 請參閱「寫入前請確認」）：
UptimeLens:create_monitor— 從 URL 建立 HTTP/HTTPS 監控。請參閱「create_monitor 能做與不能做的事」。UptimeLens:update_monitor— 編輯現有監控的名稱和/或檢查間隔（需提供id，以及name和/或intervalSeconds，至少一項）。所有其他設定（URL、類型、身份驗證、標頭、閾值、區域）皆保持不變，且無法透過 MCP 變更。此操作可逆且具有等冪性。UptimeLens:pause_monitor/UptimeLens:resume_monitor— 停止或重新啟動單一監控的主動監控。輸入：id。可逆且具有等冪性。UptimeLens:register_monitor_dependency— 宣告子→父依賴關係：當父監控故障時，子監控的下行警報將被抑制。輸入：monitorId（子監控）、parentId。僅限直接父監控；禁止循環或自依賴。UptimeLens:delete_monitor_dependency— 透過其記錄id（來自list_monitor_dependencies）移除依賴關係邊；不會刪除任何監控。UptimeLens:create_incident— 開啟一個事件。請參閱「事件以草稿形式開啟」。UptimeLens:post_incident_update— 新增時間線更新（調查中/已識別/監控中）並附上訊息。除非傳入notifySubscribers=true（且僅當事件已發佈），否則不會以電子郵件通知訂閱者。UptimeLens:resolve_incident— 將事件標記為已解決。除非傳入notifySubscribers=true（且僅當事件已發佈），否則不會以電子郵件通知訂閱者。可透過reopen_incident逆轉。UptimeLens:cancel_incident— 以錯誤警報/重複/測試為由取消事件；終結性操作（無法重新開啟），不納入分析。預設為靜默。UptimeLens:reopen_incident— 重新開啟一個先前已解決的事件（已取消的事件無法重新開啟）。UptimeLens:save_postmortem— 以 Markdown 格式寫入（或覆寫）事件的事後檢討報告主體；可選status為草稿或審查中。這是postmortem_draft提示輸出的去處 — 沒有此步驟，草稿僅存在於對話中。發佈仍須由人類在儀表板中操作。UptimeLens:add_incident_action_item— 為事件新增後續行動項目（標題，加上可選的類型、優先級與截止日期）。這是事後檢討報告中真正會帶來改變的一半。UptimeLens:create_maintenance/UptimeLens:delete_maintenance— 排程或取消一個維護時窗，此期間將抑制該時窗內監控的警報。
核心工作流程：設定監控（特別是在部署後）
探索優先：幾乎每次寫入操作都需要一個 ID，或是一個唯有當前庫存才能提供的決策。請複製以下核對清單並逐一執行：
設定監控：
- [ ] 1. 檢視當前涵蓋範圍 (list_monitors) — 查看現有項目、缺少哪些項目、以及哪些項目已故障
- [ ] 2. 針對新的 URL/服務：檢查 list_monitors 是否有重複（create_monitor 不具等冪性）
- [ ] 3. 與使用者確認 URL，然後執行 create_monitor（僅限 HTTP/HTTPS）
- [ ] 4. 如有相關性，設定拓撲（register_monitor_dependency：將新檢查放在其上層之下）
- [ ] 5. 如果正在進行部署/維護，則消除噪音（為該時窗執行 create_maintenance）
步驟 1 — 庫存。 呼叫 list_monitors。若要回答「目前什麼故障？」，請傳入 status=["down"]（若使用者意指「不健康」，則可加入 degraded/unconfirmed-down）。這也是您發現缺口的方式：使用者剛部署的服務在監控清單中找不到對應項目。
步驟 2-3 — 謹慎建立。 create_monitor 不具等冪性 — 對同一個 URL 呼叫兩次會建立兩個監控。請先檢查 list_monitors 是否已存在，並在建立前與使用者確認確切的 URL。請參閱下方限制。
步驟 4 — 拓撲（選擇性）。 如果新的監控位於您已監控項目的下游（例如位於閘道後方的應用程式、位於資料庫後方的服務），請使用 register_monitor_dependency，將新監控設為 monitorId，上游設為 parentId，以免當上游為真正問題時子監控仍發出傳呼。
步驟 5 — 消除部署噪音（選擇性）。 如果使用者正在部署或進行計畫性工作，請對受影響的監控執行 create_maintenance，並設定時窗，使工作本身不會觸發傳呼。
create_monitor 能做與不能做的事
create_monitor 是一種快速新增功能：提供一個 URL，它會建立一個 HTTP/HTTPS 監控（若未指定 scheme，則預設為 https），名稱預設為主機名稱，檢查間隔與警報群組則使用租戶預設值。
它無法透過 MCP 做到：建立非 HTTP 監控（TCP/UDP、DNS、ping/ICMP、SSH、SMTP 等）、設定身份驗證、自訂標頭、關鍵字/主體斷言、特定檢查間隔或警報群組。針對上述任何需求，請告知使用者到儀表板完成設定 — 不要假裝 MCP 可以設定它們。建立之後，update_monitor 可以變更監控的名稱與檢查間隔（僅此兩項 — 其他所有設定仍須在儀表板中進行）。沒有 delete_monitor 工具：若要移除監控，請引導使用者至儀表板。
事件以草稿形式開啟
create_incident 開啟的總是未發佈的草稿：它不會顯示在任何狀態頁面上，也不會通知訂閱者。需由人類在儀表板中發佈。當您建立事件時請說明這一點，讓使用者知道事件尚未公開。post_incident_update、resolve_incident、cancel_incident 和 reopen_incident 僅在您明確傳入 notifySubscribers=true 時才會以電子郵件通知訂閱者 — MCP 的預設是靜默的，因為發送給客戶的客戶的郵件無法收回。（儀表板的行為相反：在那裡有人類按下按鈕。）cancel_incident 是終結性操作（錯誤警報/重複/測試）且無法重新開啟；resolve_incident 可透過 reopen_incident 逆轉。對於「這不是真實事件」的情況使用 cancel，對於「此事已結束」的情況使用 resolve。
寫入前請確認
讀取與建議可以自由進行。在任何寫入操作之前，請說明您即將進行的動作並取得使用者的同意 — 這些操作會改變監控內容、傳呼內容或記錄內容：
- 建立監控：說出確切的 URL。由於不具等冪性，請確認尚未有監控涵蓋該 URL（您已檢查過
list_monitors）。 - 暫停/恢復：暫停會停止監控，因此在暫停期間真正的故障不會觸發傳呼 — 請確認使用者有意要將其靜音。
- 維護：說出受影響的監控與確切的時窗（RFC3339 格式；預設為 UTC，或傳入 IANA
timezone，例如Europe/Istanbul— 週期性時窗會自動處理日光節約時間）；在此期間，警報將被抑制。 - 事件開啟/更新/解決/取消：說出事件名稱，對於解決/取消，請說明是否要求寄送電子郵件給訂閱者（
notifySubscribers=true）— 預設不會寄送郵件。
偏好最不令人意外的操作，以建議為主而非大規模建立，且絕不在沒有逐事件確認的情況下大量開啟或解決事件。
常見情境
「監控 https://api.example.com。」
執行 list_monitors（檢查是否已受監控）→ 確認 URL → 執行 create_monitor(url)。如果使用者需要身份驗證、關鍵字檢查或非 HTTP 協議，請先建立基本的 HTTP 監控，並告知他們在儀表板中完成這些設定。
「我剛剛部署了計費服務 — 我應該監控什麼？」
執行 list_monitors 以檢視當前涵蓋範圍 → 識別缺口（沒有監控的新公開端點/健康檢查）並向使用者建議它們，而非默默地建立 → 經確認後，為每一個執行 create_monitor → 如果新監控位於您已監控項目的後方，請執行 register_monitor_dependency 將其置於該上游之下。請注意哪些項目無法自動建立（非 HTTP、身份驗證、關鍵字），並將這些交由儀表板處理。
「目前什麼服務故障？」
優先使用 get_overview — 它會回答...
（原文過長，已截斷）