企业官网建设流程全解析

OneUptime 外部状态页监控（External Status Page Monitor）完整指南：监控第三方依赖服务可用性

【免费下载链接】oneuptimeComplete open-source monitoring and observability platform.项目地址: https://gitcode.com/GitHub_Trending/on/oneuptime

外部状态页监控是 OneUptime 监控体系中的一类特殊监控器，用于周期性地探测 AWS、GCP、Azure、GitHub、OpenAI、Anthropic 等第三方供应商公开的状态页（Status Page），并在上游服务发生中断或性能降级时第一时间发出告警。读完本文，你将掌握外部状态页监控的原理（Auto 检测顺序、组件组/组件名过滤机制）、完整配置步骤、监控标准（Criteria）与模板变量，以及结合源码理解其探测与判定实现。

概述：为什么要监控第三方状态页

现代应用往往依赖大量第三方服务：云厂商、SaaS 平台、LLM API、CDN、监控与告警工具本身。当这些上游服务发生故障时，你的应用体验会直接受影响。外部状态页监控器通过查询这些服务的公开状态页来持续评估其健康度，主要能力包括：

• 监控你的应用所依赖的第三方服务的可用性；
• 在上游供应商发生中断时收到告警（而不是等用户先发现问题）；
• 跟踪单个组件的状态（例如 "AWS EC2 us-east-1"）；
• 将监控范围限制在单个组件组（例如只监控 OpenAI 的 "APIs" 组），使状态页上其他不相关的 incident 不会误触发你的监控器；
• 在性能降级影响最终用户之前提前发现；
• 将你自身服务的 incident 与上游供应商的问题进行关联分析。

支持的供应商类型（Provider）

OneUptime 支持通过以下几种方式解析外部状态页：

对应实现见 ExternalStatusPageProviderType.ts，枚举值AtlassianStatuspage = "Atlassian Statuspage"、IncidentIo = "incident.io"、RSS、Atom、Auto。

Auto 自动检测顺序

当设置为Auto时，探测端会按以下顺序依次尝试识别状态页格式（对应 ExternalStatusPageMonitor.ts 中fetch()的检测分支）：

1. 首先尝试 incident.io 状态页 API（/proxy/<host>端点）；
2. 然后尝试 Atlassian Statuspage JSON API（/api/v2/status.json、/api/v2/components.json和/api/v2/incidents/unresolved.json）；
3. 若上述都失败，尝试将页面解析为 RSS 或 Atom feed；
4. 作为最终兜底方案，执行一次基础的 HTTP 可达性检查（tryBasicHttpCheck）。

注意：incident.io 必须排在第一位，因为部分 incident.io 状态页（例如https://status.openai.com）同时暴露了一个受限的 Atlassian 兼容端点，但该端点不包含组件组和活跃 incident 数据。先尝试 incident.io，可以确保使用更完整、具备组件组感知的数据。而真正的 Atlassian 状态页会对 incident.io 的 proxy 端点返回 404，从而自然落入 Atlassian 分支（源码中通过 404/403/401 响应直接返回null来切换检测路径）。

创建外部状态页监控器

在 OneUptime 仪表盘中按以下步骤创建：

1. 进入仪表盘中的监控（Monitors）页面；
2. 点击创建监控（Create Monitor）；
3. 选择外部状态页（External Status Page）作为监控类型；
4. 输入要监控的状态页 URL；
5. （可选）指定具体的供应商类型，或保留Auto；
6. （可选）填写组件组（Component Group），将范围限制到类似 "APIs" 的某个组；
7. （可选）填写组件名（Component Name），只过滤单个组件（若同时指定了组，则在组内过滤）；
8. 按需配置监控标准（Criteria）。

配置项详解

外部状态页监控的配置结构定义在 MonitorStepExternalStatusPageMonitor.ts，包含statusPageUrl、provider、componentGroupName、componentName、timeout、retries六个字段，默认值由getDefault()提供。

状态页 URL（statusPageUrl）

输入要监控的外部状态页地址。对于 Atlassian Statuspage 与 incident.io 驱动的站点，通常是根 URL（例如https://status.example.com）；对于 RSS/Atom feed，则直接输入 feed 的 URL。

供应商类型（provider）

选择状态页的供应商类型。若不确定，使用Auto（默认）让 OneUptime 自动识别；若已知页面格式，可直接指定Atlassian Statuspage、incident.io、RSS或Atom。显式指定可跳过 Auto 检测的尝试开销，并避免格式误判。

组件组过滤器（componentGroupName）

如果状态页将组件组织为组（Group），你可以将监控范围限制在单个组内。例如在https://status.openai.com上填写APIs，监控器就只关注 OpenAI 的 API 服务。

当指定了组件组后，活跃 incident 数量与整体状态只根据该组内的组件计算——影响无关组（例如 ChatGPT）的 incident 不会触发一个限制在 "APIs" 组的监控器。

组件组过滤仅对Atlassian Statuspage与incident.io供应商生效（RSS/Atom feed 不暴露组件组）。

源码中该逻辑位于buildScopedResponse()：先通过matchesFilter()对每个组件按其groupName（Atlassian 侧由group_id反查组名、incident.io 侧从 structure 中的 group 成员关系解析）过滤出目标组件，再仅针对目标组件统计 incident 数量与推导整体状态。

组件名过滤器（componentName）

如果状态页报告多个组件，可以填写组件名只监控特定组件。例如只想监控 AWS us-east-1 的 EC2，就填写EC2 us-east-1（必须是状态页上展示的精确组件名）。

• 当同时指定了组件组时，组件名过滤在组内生效，从而可以精确定位大组中的单个组件；
• 当两者都未指定时，监控范围内所有组件。

高级设置

超时（timeout）

等待状态页响应的最长时间（毫秒）。默认10000ms（10 秒）。源码中探测端以config.timeout ?? 10000作为兜底，并通过HttpMonitorExecutionContext的remainingTimeoutInMs()控制单次请求的剩余时间预算。

重试（retries）

请求失败时的重试次数。默认3 次重试。源码中重试间隔为 1 秒（executionContext.sleep(1000)），且满足两个前提才重试：错误类型不是"故障关闭"类（超时、BadDataException），并且当前重试次数小于options.retry ?? config.retries ?? 3。超时后返回的failureCause为"Request was tried N times and it timed out."，同时响应中会带上probeAttempts与totalAttempts记录每次尝试的明细。

监控标准（Criteria）

你可以基于以下维度配置判断第三方服务在线/离线的标准：

• 是否在线（Is Online）—— 状态页是否可访问并返回了状态数据；
• 整体状态（Overall Status）—— 状态页的整体状态指示值（例如operational、degraded_performance、partial_outage、major_outage）；
• 组件状态（Component Status）—— 监控范围内组件的状态（会考虑组件组/组件名过滤器）；
• 活跃事件（Active Incidents）—— 状态页上报的当前活跃 incident 数量（指定过滤时仅统计组/组件范围内的）；
• 响应时间（Response Time）—— 拉取状态页数据所花费的时间。

默认标准

默认情况下，OneUptime 会根据状态页真正有价值的指标——活跃 incident 与组件健康度——而非单纯的可用性来创建默认标准：

• 当监控范围内没有活跃 incident时，监控器标记为I drift（Operational，运行正常）；
• 当监控范围内至少存在一个活跃 incident，或范围内任意组件上报degraded_performance、partial_outage、major_outage、full_outage时，监控器标记为Down（故障）并创建 incident。

由于活跃 incident 计数与组件状态都遵守组件组/组件名过滤器，这些默认标准会自动聚焦在你真正关心的组件上，避免无关事件造成告警噪音。

标准判定实现位于 ExternalStatusPageMonitorCriteria.ts，它按checkOn分别处理五类条件：

• ExternalStatusPageIsOnline：对isOnline做布尔比较；
• ExternalStatusPageResponseTime：将阈值转为数字后做数值比较；
• ExternalStatusPageOverallStatus：对overallStatus做字符串比较；
• ExternalStatusPageComponentStatus：遍历componentStatuses，若任一组件状态命中阈值则返回Component "xxx": ...说明；
• ExternalStatusPageActiveIncidents：对activeIncidentCount做数值比较。

同时，条件还支持基于监控间隔（monitoringInterval）的Over Time（随时间评估）过滤，由 EvaluateOverTime.ts 提供样本窗口计算，避免刚启动的监控器因窗口未覆盖完整而被误判为持续违反。

探测端实现与安全设计

外部状态页探测由 Probe 服务执行，核心实现为 ExternalStatusPageMonitor.ts，值得关注的设计点：

• SSRF 与响应体预算：请求通过HttpMonitorExecutionContext统一管理（HttpMonitorRequest.prepare()处理域名解析与 egress 防护），并设置maxContentLength: -1配合流式读取与累计预算，防止恶意大响应耗尽 Probe 进程内存；XML 解析（fast-xml-parser）还受EXTERNAL_STATUS_PAGE_XML_MAX_RESPONSE_BYTES（512KB）、EXTERNAL_STATUS_PAGE_XML_MAX_ELEMENT_COUNT（5000）、EXTERNAL_STATUS_PAGE_XML_MAX_DEPTH（64）三重结构约束，防止攻击者控制的 XML 在共享 Probe 进程中撑爆内存。
• 状态词表归一化：getStatusRank()将 Atlassian 与 incident.io 的状态词汇统一映射为严重度等级（operational=0 →major_outage/full_outage/critical=4），未知的非 operational 状态一律视为降级，用于推导 scoped 后的整体状态。
• 探测机在线性校验：当请求因网络错误（非配置类错误）失败时，会先调用OnlineCheck.canProbeMonitorWebsiteMonitors()确认 Probe 自身网络是否正常，避免 Probe 本机 DNS/网络故障导致所有状态页被误报为不可达。
• 相关回归测试见 Probe/Tests/Utils/Monitors/MonitorTypes/ExternalStatusPageMonitor.ssrf.test.ts 与 ExternalStatusPageMonitorTimeout.test.ts。

监控响应数据结构

每次探测产生的响应结构定义在 ExternalStatusPageMonitorResponse.ts，关键字段包括：

流行状态页 URL 速查表

以下是一份经过整理的热门服务状态页清单，可直接用于创建监控器：

提示：以上多数服务使用 Atlassian Statuspage 或 incident.io，因此Auto供应商类型会自动识别它们，无需手动指定。

Incident 与告警模板变量

从外部状态页监控器创建 incident 或告警时，可使用以下模板变量：

这些变量的取值映射在 MonitorTemplateUtil.ts 中实现：当monitorType === MonitorType.ExternalStatusPage时，将isOnline、responseTimeInMs、failureCause、overallStatus、activeIncidentCount、provider、componentGroup、componentName以及每个组件的name/status/description/groupName组装进模板存储映射，供模板引擎在渲染时解析。

最佳实践

• 优先使用 Auto 供应商类型：除非你确切知道页面的格式，Auto 检测对绝大多数状态页都能正确识别；
• 按组件组收窄范围：如果只依赖供应商的某一部分（例如 OpenAI 的 "APIs"），请限定组件组，避免无关 incident 造成告警噪音；
• 监控具体组件：如果只依赖某些具体服务（例如某个 AWS 区域），使用组件名过滤；
• 配置 incident 关联（Correlation）：当你的监控器发现问题、而上游状态页也同时显示问题时，关联分析能帮助更快定位根因；
• 与其他监控器组合使用：将外部状态页监控器与你自己服务的 API/Website 监控器搭配，实现端到端的完整可见性——上游故障与自身服务故障互为佐证，避免误报与漏报。

参考资料

• 本文对应官方文档：external-status-page-monitor.md
• 配置结构定义：MonitorStepExternalStatusPageMonitor.ts
• 供应商类型枚举：ExternalStatusPageProviderType.ts
• 探测端核心实现：Probe/Utils/Monitors/MonitorTypes/ExternalStatusPageMonitor.ts
• 标准判定实现：Common/Server/Utils/Monitor/Criteria/ExternalStatusPageMonitorCriteria.ts
• 响应数据结构：ExternalStatusPageMonitorResponse.ts

【免费下载链接】oneuptimeComplete open-source monitoring and observability platform.项目地址: https://gitcode.com/GitHub_Trending/on/oneuptime