uptimelens/claude-plugins

UptimeLens 监控 (UptimeLens Monitoring)

通过 UptimeLens MCP 服务器，在客户自己的资源上设置并运行 UptimeLens 正常运行时间监控。此技能将监控请求（例如“监控此URL”、“此部署后应关注什么？”、“什么服务挂了？”、“打开一个事件”）转换为正确的 MCP 工具调用序列。

使用时机

用于产品中监控设置和事件簿记方面：

• 创建 HTTP/HTTPS 监控器，并在部署后或针对新服务推荐监控覆盖范围。
• 检查当前哪些服务中断，并进行初步调查（状态历史、按探针分析的根因、响应时间/可用性）。
• 安排维护窗口，以便部署或计划中的工作不会发出告警。
• 建模监控器依赖关系，以便当上游监控器已经中断时，下游检查不会发出告警。
• 打开、更新或解决事件。

当请求是关于响应告警而非监控时，请移交处理：如需确认或暂停正在进行的升级、值班交接或检查升级运行情况，请使用 uptimelens-on-call 技能。对于深入、引导式的事件根因调查，应优先使用只读的 triage_incident MCP 提示（以及 get_root_cause 工具），而非在此自行编写整个分析脚本。

前提条件

1. UptimeLens MCP 服务器已连接到此客户端。所有套餐均支持读取工具。
2. 写入操作（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 令牌和 Pro 计划或更高版本。使用只读令牌时，写入工具甚至不会列出；在免费计划上，它们会返回 FeatureNotAvailable。
3. 某些读取工具受套餐限制。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（up/degraded/down/unconfirmed-down/unknown/not-monitored/in-maintenance）、名称或标签进行筛选。这是几乎所有其他操作中 monitorId 的来源，也是回答“什么服务挂了？”的答案。
• UptimeLens:get_monitor — 一个监控器的配置和当前健康状况（无凭据）。
• UptimeLens:list_status_changes — 一个监控器的 up/down/degraded 历史记录及其持续时间；这是 get_root_cause 所需的 statusChangeId 的来源。
• UptimeLens:get_status_change — 一个状态变更及其上下文（前一个和后一个变更，覆盖该时间段的 incident 和升级运行）以及该变更前后各检查点的按位置汇总：失败次数、firstDownAt 和最频繁的 errorCategory。用于确定中断从何处开始以及如何确认；所有套餐均可使用。
• UptimeLens:get_root_cause — 针对一个状态变更的每个探针网络诊断：DNS/连接/TLS 时间、路由追踪、TLS 版本、SSL 剩余天数、错误类别。这是最丰富的“为什么中断”信息源（付费套餐）。
• UptimeLens:query_metrics — 一个监控器在一段时间内的响应时间和正常运行时间统计信息（周期摘要，不是完整序列；百分位数为 Team+ 套餐）。
• 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 为 draft 或 in_review。这是 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 监控器（未提供协议时默认使用 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。因为不是幂等的，所以确认还没有已存在的监控器（你已经检查了 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——它能回答中断的概要信息。