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 与上游供应商的问题进行关联分析。支持的供应商类型ProviderOneUptime 支持通过以下几种方式解析外部状态页供应商类型说明Auto默认自动检测状态页格式Atlassian Statuspage由 Atlassian Statuspage 驱动的状态页JSON APIincident.io由 incident.io 驱动的状态页例如https://status.openai.comRSS提供 RSS feed 的状态页Atom提供 Atom feed 的状态页对应实现见 ExternalStatusPageProviderType.ts枚举值AtlassianStatuspage Atlassian Statuspage、IncidentIo incident.io、RSS、Atom、Auto。Auto 自动检测顺序当设置为Auto时探测端会按以下顺序依次尝试识别状态页格式对应 ExternalStatusPageMonitor.ts 中fetch()的检测分支首先尝试 incident.io 状态页 API/proxy/host端点然后尝试 Atlassian Statuspage JSON API/api/v2/status.json、/api/v2/components.json和/api/v2/incidents/unresolved.json若上述都失败尝试将页面解析为 RSS 或 Atom feed作为最终兜底方案执行一次基础的 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 仪表盘中按以下步骤创建进入仪表盘中的监控Monitors页面点击创建监控Create Monitor选择外部状态页External Status Page作为监控类型输入要监控的状态页 URL可选指定具体的供应商类型或保留Auto可选填写组件组Component Group将范围限制到类似 APIs 的某个组可选填写组件名Component Name只过滤单个组件若同时指定了组则在组内过滤按需配置监控标准Criteria。配置项详解外部状态页监控的配置结构定义在 MonitorStepExternalStatusPageMonitor.ts包含statusPageUrl、provider、componentGroupName、componentName、timeout、retries六个字段默认值由getDefault()提供。状态页 URLstatusPageUrl输入要监控的外部状态页地址。对于 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()对每个组件按其groupNameAtlassian 侧由group_id反查组名、incident.io 侧从 structure 中的 group 成员关系解析过滤出目标组件再仅针对目标组件统计 incident 数量与推导整体状态。组件名过滤器componentName如果状态页报告多个组件可以填写组件名只监控特定组件。例如只想监控 AWS us-east-1 的 EC2就填写EC2 us-east-1必须是状态页上展示的精确组件名。当同时指定了组件组时组件名过滤在组内生效从而可以精确定位大组中的单个组件当两者都未指定时监控范围内所有组件。高级设置超时timeout等待状态页响应的最长时间毫秒。默认10000ms10 秒。源码中探测端以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 driftOperational运行正常当监控范围内至少存在一个活跃 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_BYTES512KB、EXTERNAL_STATUS_PAGE_XML_MAX_ELEMENT_COUNT5000、EXTERNAL_STATUS_PAGE_XML_MAX_DEPTH64三重结构约束防止攻击者控制的 XML 在共享 Probe 进程中撑爆内存。状态词表归一化getStatusRank()将 Atlassian 与 incident.io 的状态词汇统一映射为严重度等级operational0 →major_outage/full_outage/critical4未知的非 operational 状态一律视为降级用于推导 scoped 后的整体状态。探测机在线性校验当请求因网络错误非配置类错误失败时会先调用OnlineCheck.canProbeMonitorWebsiteMonitors()确认 Probe 自身网络是否正常避免 Probe 本机 DNS/网络故障导致所有状态页被误报为不可达。相关回归测试见 Probe/Tests/Utils/Monitors/MonitorTypes/ExternalStatusPageMonitor.ssrf.test.ts 与 ExternalStatusPageMonitorTimeout.test.ts。监控响应数据结构每次探测产生的响应结构定义在 ExternalStatusPageMonitorResponse.ts关键字段包括字段说明isOnline状态页是否在线overallStatus整体状态指示值componentStatuses组件状态数组name、status、description、groupNameactiveIncidentCount活跃 incident 数量应用过滤后responseTimeInMs响应时间毫秒failureCause失败原因provider/componentGroupName/componentName回显本次实际查询范围供摘要视图与模板展示流行状态页 URL 速查表以下是一份经过整理的热门服务状态页清单可直接用于创建监控器服务状态页 URLAWShttps://health.aws.amazon.com/health/statusGoogle Cloud Platformhttps://status.cloud.google.comMicrosoft Azurehttps://status.azure.comGitHubhttps://www.githubstatus.comOpenAIhttps://status.openai.comAnthropichttps://status.anthropic.comCloudflarehttps://www.cloudflarestatus.comDatadoghttps://status.datadoghq.comPagerDutyhttps://status.pagerduty.comTwiliohttps://status.twilio.comStripehttps://status.stripe.comSlackhttps://status.slack.comAtlassian (Jira, Confluence)https://status.atlassian.comVercelhttps://www.vercel-status.comNetlifyhttps://www.netlifystatus.comDigitalOceanhttps://status.digitalocean.comHerokuhttps://status.heroku.comMongoDB Atlashttps://status.cloud.mongodb.comFastlyhttps://status.fastly.comNew Relichttps://status.newrelic.comSentryhttps://status.sentry.ioCircleCIhttps://status.circleci.com提示以上多数服务使用 Atlassian Statuspage 或 incident.io因此Auto供应商类型会自动识别它们无需手动指定。Incident 与告警模板变量从外部状态页监控器创建 incident 或告警时可使用以下模板变量变量说明{{isOnline}}状态页是否在线true/false{{responseTimeInMs}}响应时间毫秒{{failureCause}}失败原因如有{{overallStatus}}整体状态指示值{{activeIncidentCount}}活跃 incident 数量指定过滤时限制在过滤范围内{{componentStatuses}}组件状态的 JSON 数组name、status、description、groupName{{provider}}识别出的供应商Atlassian Statuspage、incident.io、RSS、Atom{{componentGroup}}监控器限定的组件组如有{{componentName}}监控器限定的组件名如有这些变量的取值映射在 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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考