OneUptime 外部状态页监控（External Status Page Monitor）实战指南：自动追踪 AWS、GitHub、OpenAI 等第三方服务健康

OneUptime 外部状态页监控（External Status Page Monitor）实战指南：自动追踪 AWS、GitHub、OpenAI 等第三方服务健康

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

本篇技术指南以 OneUptime 开源监控平台中的「外部状态页监控（External Status Page Monitor）」功能为核心，完整讲解其工作原理、支持的状态页提供者类型、自动检测逻辑、创建步骤、配置项、监控指标与告警模板变量。读完本文，你将掌握如何把 AWS、GCP、Azure、GitHub、OpenAI、Anthropic 等上游服务的官方状态页纳入 OneUptime 监控体系，在第三方服务发生故障或性能降级时第一时间收到告警，并将上游事故与自身事故进行关联分析。

概述：为什么需要监控外部状态页

外部状态页监控的核心思想是：通过周期性查询第三方服务的公开状态页，来度量你所依赖的上游服务的健康程度。与直接探测服务端点不同，状态页监控获取的是服务方自己对外公布的运行状态、组件健康度与事故信息，能够提供更全面、更具权威性的视角。

在 OneUptime 中，使用外部状态页监控可以：

• 监控你的应用所依赖的第三方服务（如云厂商、SaaS、API 提供方）的可达性；
• 当上游提供方发生中断时及时获得告警，而不是等用户反馈才发现问题；
• 跟踪单个组件的状态，例如「AWS EC2 us-east-1」；
• 将监控范围收窄到某个组件分组（例如 OpenAI 的「APIs」），避免页面上其他无关事故干扰你的监控判断；
• 在性能降级（degraded performance）尚未影响到你的用户之前就提前察觉；
• 将你自己的事故与上游提供方的问题进行关联，加速根因定位。

从源码结构看，这一功能贯穿 OneUptime 的「探测端（Probe）执行采集、服务端（Server）评估判定、告警模板渲染」三层体系，下文将逐层展开。

支持的提供者（Provider）类型

OneUptime 支持通过以下方式监控外部状态页，对应的枚举定义位于 ExternalStatusPageProviderType.ts：

枚举源码中五种取值与文档完全对应：AtlassianStatuspage = "Atlassian Statuspage"、IncidentIo = "incident.io"、RSS = "RSS"、Atom = "Atom"、Auto = "Auto"。

自动检测（Auto）的完整流程

当提供者类型设置为Auto时，OneUptime 会按照以下顺序自动识别状态页模板（该逻辑实现于 Probe/Utils/Monitors/MonitorTypes/ExternalStatusPageMonitor.ts 的fetch()方法）：

1. 首先尝试 incident.io 的状态页 API：访问/proxy/<host>端点（例如对https://status.openai.com会请求https://status.openai.com/proxy/status.openai.com）；
2. 然后尝试 Atlassian Statuspage 的 JSON API：依次访问/api/v2/status.json、/api/v2/components.json和/api/v2/incidents/unresolved.json；
3. 如果以上都失败，尝试将页面解析为 RSS 或 Atom 订阅源；
4. 作为最后兜底，执行一次基础的 HTTP 可达性检查（4xx/5xx 会返回离线结果，而非抛出异常）。

注意：为什么 incident.io 必须先于 Atlassian 检测？一些 incident.io 状态页（如https://status.openai.com）同时暴露了与 Atlassian 兼容的/api/v2/status.json端点，但该兼容端点不提供组件分组和未解决事故数据。如果先做 Atlassian 检测，会"误判成功"但拿到降级的数据；而真正的 Atlassian 状态页会对 incident.io 的代理端点返回 404，从而自然落入 Atlassian 分支。因此源码中强制先探测 incident.io，确保拿到更丰富、具备分组感知的数据。这一顺序在源码注释中也有明确说明。

创建外部状态页监控

在 OneUptime 仪表盘中创建外部状态页监控的操作步骤如下：

1. 在 OneUptime 仪表盘中进入Monitors（监控器）；
2. 点击Create Monitor（创建监控器）；
3. 选择监控器类型为External Status Page（外部状态页）；
4. 输入要监控的状态页地址；
5. （可选）指定具体的提供者类型，或保持Auto自动检测；
6. （可选）输入组件分组（Component Group），将监控范围限制到某个分组（如「APIs」）；
7. （可选）输入组件名称（Component Name），进一步过滤到单个组件（若已设置分组，则在分组内过滤）；
8. 按需配置监控指标（Criteria）。

创建后，配置会被持久化为MonitorStepExternalStatusPageMonitor结构。其序列化/反序列化逻辑定义于 MonitorStepExternalStatusPageMonitor.ts，字段包括statusPageUrl、provider、componentGroupName、componentName、timeout、retries。

配置选项详解

状态页地址（Status Page URL）

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

提供者类型（Provider Type）

选择状态页的提供者类型。推荐使用Auto（默认值）让 OneUptime 自动识别模板；如果你明确知道页面类型，也可以手动指定Atlassian Statuspage、incident.io、RSS或Atom，以跳过自动检测环节。

组件分组过滤（Component Group Filter）

如果状态页将组件组织为分组，可以将监控器限制到某一个分组。例如在https://status.openai.com中，输入APIs即可将监控范围限定为 OpenAI 的 API 服务。

关键行为（见源码buildScopedResponse()）：当设置了组件分组时，「活跃事故数（active incident count）」和「整体状态（overall status）」只依据该分组内的组件计算——影响其他无关分组（例如 ChatGPT）的事故不会触发被限制到「APIs」分组的监控器。

组件分组过滤仅对Atlassian Statuspage和incident.io提供者生效（RSS/Atom 订阅源不暴露组件分组结构）。

组件名称过滤（Component Name Filter）

如果状态页报告多个组件，可以指定具体的组件名称以只监控该组件。例如只想监控 AWS us-east-1 区域的 EC2，就输入EC2 us-east-1（组件名称必须与状态页上显示的名称精确一致，匹配为不区分大小写的子串匹配，见源码matchesFilter()）。

当同时设置了组件分组时，组件名称过滤会在分组内部应用，从而精确定位一个较大分组中的单个组件。当两个过滤条件都未设置时，所有范围内的组件都会被监控。

高级选项

超时（Timeout）

等待状态页返回响应的最大时间（毫秒），默认值为10000 毫秒（10 秒）。该默认值在MonitorStepExternalStatusPageMonitorUtil.getDefault()中定义；若检测到超时，探测结果将标记isTimeout: true，failureCause会注明「请求尝试了 N 次后超时」。

重试（Retries）

首次尝试失败后重新发送请求的次数；0 表示只尝试 1 次。默认值为3 次重试，即最多共 4 次尝试（探测端在每次重试之间会Sleep.sleep(1000)暂停 1 秒）。需要特别说明的是：源码中retries为 0 是合法值，序列化时会被完整保留，不会被默认值覆盖（见MonitorStepExternalStatusPageMonitorUtil.fromJSON()中针对 retries 的专门处理）。

监控指标（Criteria）

你可以配置监控指标来决定外部服务何时被视为「运行中（Operational）」或「宕机（Down）」。指标基于以下维度（对应 CriteriaFilter.ts 中CheckOn枚举，前缀均为ExternalStatusPage*）：

• Is Online（是否在线）—— 状态页是否可达并返回状态数据；
• Overall Status（整体状态）—— 状态页的整体状态指示值，例如operational、degraded_performance、partial_outage、major_outage；
• Component Status（组件状态）—— 范围内组件的状态（遵循组件分组/组件名称过滤）；
• Active Incidents（活跃事故数）—— 状态页上当前活跃的事故数量（设置过滤条件时，仅统计分组/组件范围内的事故）；
• Response Time（响应时间）—— 获取状态页数据所花费的时长（毫秒）。

指标的实际判定逻辑位于 ExternalStatusPageMonitorCriteria.ts，它会根据checkOn字段分发到不同的比较器：布尔比较（在线状态）、数字比较（响应时间、活跃事故数）、字符串比较（整体状态、组件状态）。其中组件状态判定会遍历componentStatuses数组，任意一个组件命中阈值即视为条件满足，并返回带组件名的详细结果。

默认指标

默认情况下，OneUptime 依据对状态页真正重要的信号——活跃事故数与组件健康度——来判定，而不仅仅是页面可达性：

• 当范围内没有活跃事故时，监控器标记为Operational（运行中）；
• 当范围内至少存在一个活跃事故，或范围内某个组件报告degraded_performance、partial_outage、major_outage或full_outage时，监控器标记为Down（宕机），并创建一条事故（Incident）。

由于活跃事故数与组件状态均遵循组件分组/组件名称过滤，这些默认指标会自动只关注对你重要的组件。源码中还定义了状态严重程度排名getStatusRank()：operational=0、under_maintenance/maintenance=1、degraded_performance/degraded=2、partial_outage=3、major_outage/full_outage/critical=4，整体状态取范围内最差组件的状态；若所有组件均正常但范围内存在活跃事故，则整体状态推导为degraded_performance。

热门状态页地址速查

以下为精选的、可直接用于监控的热门服务状态页地址：

提示：上表中的大多数服务使用的是 Atlassian Statuspage 或 incident.io，因此保持提供者类型为Auto即可被自动识别，无需手动指定。

事故与告警模板变量

当由外部状态页监控器创建事故或发送告警时，可以在模板中使用以下变量（对应 MonitorTemplateUtil.ts 中ExternalStatusPage分支的模板数据组装逻辑）：

这些变量的数据结构与探测端返回的 ExternalStatusPageMonitorResponse.ts 一一对应：isOnline、overallStatus、componentStatuses（含name/status/description/groupName）、activeIncidentCount、responseTimeInMs、failureCause、provider、componentGroupName、componentName，以及rawBody、isTimeout、probeAttempts、totalAttempts等补充字段。其中probeAttempts记录了每次尝试的探测时间、响应时间与失败原因，可用于排障。

探测端实现细节与可靠性设计

外部状态页的采集由 OneUptime 的 Probe（探测端）执行，核心实现位于 Probe/Utils/Monitors/MonitorTypes/ExternalStatusPageMonitor.ts。除文档所述功能外，源码中还体现了以下工程细节：

• 结构化解析：Atlassian 分支会先拉取/api/v2/status.json获取页面级状态，再拉取/api/v2/components.json解析组件及分组归属（通过group_id关联分组名），最后拉取/api/v2/incidents/unresolved.json获取未解决事故及其影响组件列表；incident.io 分支则通过/proxy/<host>端点获取summary、structure、ongoing_incidents等结构化数据。
• 安全防护（fail-closed）：针对 XML 订阅源设定了严格的解析上限——响应体最大 512KB、最多 5000 个元素、最大深度 64 层，防止攻击者构造的深层 XML 拖垮共享的探测进程；同时探测请求经过 egress guard（出口守卫）约束，禁止访问非预期目标。
• SSRF 与可达性校验：当探测失败时，若失败原因指向网络层（如 DNS 解析失败、地址策略拒绝），探测端会先调用OnlineCheck.canProbeMonitorWebsiteMonitors()确认探测端自身是否在线，避免因探测端自身网络故障而把所有状态页误报为宕机；而结构化数据非法（如配置错误）则直接 fail-closed。
• 重试与超时模型：每次尝试共享同一个执行上下文（deadline 与响应体预算），重试会创建新的尝试并释放旧上下文；超时错误会被专门识别并标记isTimeout。相关行为有专门的测试覆盖，如 ExternalStatusPageMonitorTimeout.test.ts 与 ExternalStatusPageMonitor.ssrf.test.ts。
• 监控指标评估：采集结果回传后，由服务端的ExternalStatusPageMonitorCriteria结合「随时间评估（EvaluateOverTime）」机制进行判定，支持基于历史样本的窗口型指标（例如"最近 N 分钟内的所有采样值"），并处理监控器刚启动、样本不足以覆盖窗口的边界情况。

最佳实践

• 默认使用 Auto 提供者类型——除非你明确知道状态页的模板格式；自动检测对绝大多数状态页都能正确工作。
• 只依赖部分提供方时，收窄到组件分组——例如只关心 OpenAI 的「APIs」，就限制到该分组，避免无关事故产生噪音告警。
• 监控具体组件——如果只依赖特定服务（例如某个具体的 AWS 区域），使用组件名称过滤精准监控。
• 建立事故关联——当你的监控器发现问题且上游状态页也显示问题时，关联分析能显著加快根因定位。
• 与其他监控器组合使用——将外部状态页监控器与你自己部署的 API/网站监控器搭配，可以获得"上游依赖 + 自身服务"的完整可观测视角：自身监控负责发现症状，外部状态页监控负责解释根因。

通过本文的配置步骤与源码级原理说明，你可以立即在 OneUptime 中把常用的第三方服务状态页纳入监控，并借助组件分组过滤、默认指标与告警模板变量，构建一套低噪音、高可解释性的上游依赖监控方案。

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