OneUptime Website Monitor 实战指南网站可用性监控的配置、判定规则与重试原理【免费下载链接】oneuptimeComplete open-source monitoring and observability platform.项目地址: https://gitcode.com/GitHub_Trending/on/oneuptime本篇指南围绕 OneUptime 开源可观测平台的Website Monitor网站监控器展开系统讲解如何通过周期性的 HTTP 探测来监控任意网站或网页的可用性、性能与响应正确性。读完本文你将掌握从创建监控器、配置动态 URL 占位符、TLS/mTLS 高级选项到基于状态码/响应时间/响应体/响应头的多维度判定规则以及底层 Probe 探针的重试与重定向实现原理可直接用于生产环境的网站监控建设。什么是 Website MonitorOneUptime 的 Website Monitor 通过向目标 URL 周期性地发送 HTTP 请求并解析响应结果来判断网站是否正常工作。它是 OneUptime 监控体系中覆盖最广、最常见的监控类型之一典型能力包括监控网站运行时间Uptime与可用性跟踪响应时间与性能变化校验 HTTP状态码是否符合预期检查响应头是否满足条件在用户感知到故障之前提前发现停机。从源码结构看Website Monitor 的探测逻辑位于 Probe/Utils/Monitors/MonitorTypes/WebsiteMonitor.ts其核心入口是静态方法ping()它接收 URL 与一组探测选项重试次数、超时、是否跟随重定向、自签名证书开关、mTLS 证书等最终返回包含状态码、响应时间、响应体、响应头、失败原因与每次尝试记录的ProbeWebsiteResponse对象。创建 Website Monitor在 OneUptime Dashboard 中创建 Website Monitor 的步骤如下进入 OneUptime Dashboard 的Monitors监控器页面点击Create Monitor创建监控器选择Website作为监控类型输入需要监控的网站 URL按需配置监控判定标准Monitoring Criteria。创建后监控器会交由 Probe探针按调度周期执行 HTTP 探测探测结果用于生成可用性状态、响应时间曲线与事件/告警。配置选项详解Website URL网站 URL填写要监控网站的完整 URL必须包含协议前缀例如https://example.com。URL 会被完整解析并用于实际的 HTTP 请求构造对应源码中URL.fromString(...)与HttpMonitorRequest.prepare(...)的处理流程。动态 URL 占位符Dynamic URL Placeholders当被监控的 URL 位于 CDN 或缓存代理之后时监控器可能拿到缓存响应而无法真正触达源站。为了在每次检查时绕过缓存可以在 URL 中使用动态占位符每次探测请求都会被替换为唯一值。支持的占位符如下占位符说明示例值{{timestamp}}替换为当前 Unix 时间戳秒1719500000{{random}}替换为一个随机的唯一字符串a3f8b2c1d4e5f6a7b8c9d0e1f2a3b4c5示例将监控 URL 配置为https://example.com/health?cb{{timestamp}}每次检查时实际请求的 URL 会变成https://example.com/health?cb1719500000 https://example.com/health?cb1719500005 ...也可以使用{{random}}让每次请求携带唯一字符串https://example.com/health?nocache{{random}}这类“缓存击穿”技巧对于验证 CDN 背后源站真实健康状态、规避中间层缓存污染监控数据非常实用。高级选项Advanced Options不跟随重定向Do Not Follow Redirects默认情况下OneUptime 会跟随 HTTP 重定向301、302 等直接返回最终目标的响应。如果希望监控重定向响应本身而非最终落点请开启该选项。源码中当doNotFollowRedirects为真时ping()会在拿到首个响应后立即返回if (options.doNotFollowRedirects) { return result; }不再解析 3xx 响应中的Location头继续请求。在跟随重定向的默认路径下代码会通过HttpMonitorRequest.getRedirectRequest(...)解析重定向目标并在跨源cross-origin重定向时主动剥离 TLS 客户端身份includeTlsIdentity false避免把客户端证书泄露给第三方域名。允许自签名证书Allow Self-Signed Certificates开启该选项可跳过 TLS 证书校验。适用于目标服务器使用自签名或不受信任证书的场景例如内部预发布环境。对应源码中tls.allowSelfSignedCertificates配置项它会在构造 HTTPS Agent 时放宽证书校验策略。客户端证书 / mTLSClient Certificate当目标端点要求双向 TLS 认证mutual TLS时开启Use client certificatemTLS并提供以下材料Client Certificate (PEM)—— 要出示的 PEM 格式客户端证书Client Private Key (PEM)—— 与之匹配的 PEM 格式私钥Client Private Key Passphrase可选—— 仅当私钥本身加密时才需要。这等价于 curl 中的--cert与--key参数curl --cert client.crt --key client.key https://api.example.com/health对于敏感信息建议将证书与私钥存放为 Monitor Secrets 监控密钥并通过{{monitorSecrets.name}}占位符引用。Monitor Secrets 在服务端解析渲染后的值永远不会出现在 Dashboard 前端避免凭据泄露。mTLS 行为在测试 Probe/Tests/Utils/Monitors/MonitorTypes/WebsiteMonitor.mtls.test.ts 中有专门覆盖。失败重试Retries on FailureRetries on Failure 统计的是首次尝试之后的额外重试次数设为0表示只检查一次设为2表示最多执行三次请求。默认值为3最大值为3。超时不会被重试因为请求超时本身已经覆盖了该次尝试。源码中对这一语义有精确的对应MonitorRetry.canRetry(...)结合DEFAULT_RETRIES_WHEN_UNSET 4未显式设置重试次数时保留历史默认的 5 次尝试决定是否进行下一次尝试同时TimeoutException被明确排除在可重试错误之外。测试用例 Probe/Tests/Utils/Monitors/MonitorTypes/WebsiteMonitor.retries.test.ts 验证了完整矩阵连接持续失败时retry: 0恰好执行 1 次尝试retry: 2恰好执行 3 次尝试未设置 retry 值时保持 5 次尝试[1, 2, 3, 4, 5]连续 503 响应时同样按配置重试3 次尝试每次responseCode均为 503响应时间超过 10 秒时也会触发额外重试responseTimeInMS 10000分支目标解析被拒绝DNS 解析失败、命中私有地址策略拦截时即使配置了 retry 也不会重试因为这类“守卫拒绝”与普通网络故障语义不同重试会让尝试次数泄露 DNS 失败与策略拦截之间的区别这与 EgressGuard 出口守卫 的设计目标一致。此外探针在判定监控器失败后还会执行OnlineCheck.canProbeMonitorWebsiteMonitors()自检如果探针自身网络已不可达则不会把探针的故障误报为网站停机。监控判定标准Monitoring Criteria你可以配置判定标准确定网站何时被视为在线online、受限degraded或离线offline判定维度包括响应状态码Response Status Code—— 检查 HTTP 状态码是否符合预期值如 200、301响应时间Response Time—— 监控响应时间是否超过阈值响应体Response Body—— 检查响应体是否包含或匹配特定内容响应头Response Headers—— 验证特定响应头是否存在或是否符合预期值。时间段评估Evaluating over a period of timeEvaluate this criteria over a period of time在一段时间内评估该标准是判定表单上的独立开关而不是过滤条件。开启后监控器将比较过去一段时间的检查窗口而非仅使用最近一次检查的值在Evaluate中选择聚合方式Average平均值、Sum求和、Maximum Value最大值、Minimum Value最小值、All Values所有值、Any Value任意值在For the last (in minutes)中设定评估时间窗口分钟。需要注意的语义All Values只有在窗口内真正被数据覆盖时才匹配。刚刚创建的监控器或检查记录中断的监控器没有足够的历史数据来评判“最近 N 分钟”的表现此时该判定标准会等待而不是用仅有的一次读数强行匹配Any Value则对应“只要某一次检查出现违规就立即触发”的需求仍然会即时触发。If No Data无数据时选项控制当窗口内无法支撑判定标准时的行为Ignore默认—— 判定标准不匹配。适用于普通的阈值告警场景Trigger—— 将缺失数据本身视为问题。适用于心跳式检查此时“沉默”本身就是一种故障Treat As Zero—— 将窗口视为单个零值。适用于计数器场景此时“没有事件”确实意味着零。从源码看 Website Monitor 的探测流程在 Probe/Utils/Monitors/MonitorTypes/WebsiteMonitor.ts 中ping()的完整探测流程可以归纳为初始化执行上下文创建HttpMonitorExecutionContext默认超时 5000ms可通过timeout覆盖并记录开始时间选择请求方法默认使用GET若开启isHeadRequest则使用HEAD构造并发送请求通过HttpMonitorRequest.prepare(...)准备请求注入 TLS 选项、计时收集器再由WebsiteRequest.fetch(...)实际发送HEAD 回退若目标服务器拒绝 HEAD 请求而接受 GET代码会重新进入循环以 GET 方式重试currentMethod HTTPMethod.GET; continue;重定向处理默认跟随 301/302 等重定向跨源时剥离 TLS 身份开启doNotFollowRedirects则立即返回首个响应记录每次尝试每次尝试无论成功或失败都会写入probeAttempts包含尝试序号、发起/接收时间、响应时间、状态码与失败原因慢响应与失败重试响应时间超过 10 秒或连接失败时在MonitorRetry.canRetry(...)允许且执行上下文仍有时间预算的前提下等待 1 秒后递归重试在线自检对普通网络类失败先确认探针自身在线避免探针故障被误判为监控目标停机返回结构化结果最终返回ProbeWebsiteResponse其中httpTimings携带HttpPhaseTimings分阶段计时信息DNS/TLS/TTFB 等供 Dashboard 展示性能细节。整个实现体现了生产级监控的关键设计可观测性每次尝试都被记录、健壮性HEAD→GET 回退、超时与失败重试、安全性SSRF 防护与 TLS 身份剥离与防误报探针在线自检。总结OneUptime 的 Website Monitor 是一个从配置到执行都相当完整的网站监控方案动态 URL 占位符解决缓存场景下的真实源站探测mTLS 与自签名证书选项覆盖内部服务与安全接入需求可配置的监控判定标准支持从单次检查到时间段聚合的多维度评估而底层 Probe 的重试、重定向、HEAD 回退与探针自检机制则为监控数据的准确性提供了源码级保障。结合 英文版文档 与 Website Monitor 源码 继续深入你可以进一步理解监控事件如何触发告警、状态页更新与后续自动化流程。【免费下载链接】oneuptimeComplete open-source monitoring and observability platform.项目地址: https://gitcode.com/GitHub_Trending/on/oneuptime创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 OneUptime Website Monitor 实战指南：网站可用性监控的配置、判定规则与重试原理
OneUptime Website Monitor 实战指南网站可用性监控的配置、判定规则与重试原理【免费下载链接】oneuptimeComplete open-source monitoring and observability platform.项目地址: https://gitcode.com/GitHub_Trending/on/oneuptime本篇指南围绕 OneUptime 开源可观测平台的Website Monitor网站监控器展开系统讲解如何通过周期性的 HTTP 探测来监控任意网站或网页的可用性、性能与响应正确性。读完本文你将掌握从创建监控器、配置动态 URL 占位符、TLS/mTLS 高级选项到基于状态码/响应时间/响应体/响应头的多维度判定规则以及底层 Probe 探针的重试与重定向实现原理可直接用于生产环境的网站监控建设。什么是 Website MonitorOneUptime 的 Website Monitor 通过向目标 URL 周期性地发送 HTTP 请求并解析响应结果来判断网站是否正常工作。它是 OneUptime 监控体系中覆盖最广、最常见的监控类型之一典型能力包括监控网站运行时间Uptime与可用性跟踪响应时间与性能变化校验 HTTP状态码是否符合预期检查响应头是否满足条件在用户感知到故障之前提前发现停机。从源码结构看Website Monitor 的探测逻辑位于 Probe/Utils/Monitors/MonitorTypes/WebsiteMonitor.ts其核心入口是静态方法ping()它接收 URL 与一组探测选项重试次数、超时、是否跟随重定向、自签名证书开关、mTLS 证书等最终返回包含状态码、响应时间、响应体、响应头、失败原因与每次尝试记录的ProbeWebsiteResponse对象。创建 Website Monitor在 OneUptime Dashboard 中创建 Website Monitor 的步骤如下进入 OneUptime Dashboard 的Monitors监控器页面点击Create Monitor创建监控器选择Website作为监控类型输入需要监控的网站 URL按需配置监控判定标准Monitoring Criteria。创建后监控器会交由 Probe探针按调度周期执行 HTTP 探测探测结果用于生成可用性状态、响应时间曲线与事件/告警。配置选项详解Website URL网站 URL填写要监控网站的完整 URL必须包含协议前缀例如https://example.com。URL 会被完整解析并用于实际的 HTTP 请求构造对应源码中URL.fromString(...)与HttpMonitorRequest.prepare(...)的处理流程。动态 URL 占位符Dynamic URL Placeholders当被监控的 URL 位于 CDN 或缓存代理之后时监控器可能拿到缓存响应而无法真正触达源站。为了在每次检查时绕过缓存可以在 URL 中使用动态占位符每次探测请求都会被替换为唯一值。支持的占位符如下占位符说明示例值{{timestamp}}替换为当前 Unix 时间戳秒1719500000{{random}}替换为一个随机的唯一字符串a3f8b2c1d4e5f6a7b8c9d0e1f2a3b4c5示例将监控 URL 配置为https://example.com/health?cb{{timestamp}}每次检查时实际请求的 URL 会变成https://example.com/health?cb1719500000 https://example.com/health?cb1719500005 ...也可以使用{{random}}让每次请求携带唯一字符串https://example.com/health?nocache{{random}}这类“缓存击穿”技巧对于验证 CDN 背后源站真实健康状态、规避中间层缓存污染监控数据非常实用。高级选项Advanced Options不跟随重定向Do Not Follow Redirects默认情况下OneUptime 会跟随 HTTP 重定向301、302 等直接返回最终目标的响应。如果希望监控重定向响应本身而非最终落点请开启该选项。源码中当doNotFollowRedirects为真时ping()会在拿到首个响应后立即返回if (options.doNotFollowRedirects) { return result; }不再解析 3xx 响应中的Location头继续请求。在跟随重定向的默认路径下代码会通过HttpMonitorRequest.getRedirectRequest(...)解析重定向目标并在跨源cross-origin重定向时主动剥离 TLS 客户端身份includeTlsIdentity false避免把客户端证书泄露给第三方域名。允许自签名证书Allow Self-Signed Certificates开启该选项可跳过 TLS 证书校验。适用于目标服务器使用自签名或不受信任证书的场景例如内部预发布环境。对应源码中tls.allowSelfSignedCertificates配置项它会在构造 HTTPS Agent 时放宽证书校验策略。客户端证书 / mTLSClient Certificate当目标端点要求双向 TLS 认证mutual TLS时开启Use client certificatemTLS并提供以下材料Client Certificate (PEM)—— 要出示的 PEM 格式客户端证书Client Private Key (PEM)—— 与之匹配的 PEM 格式私钥Client Private Key Passphrase可选—— 仅当私钥本身加密时才需要。这等价于 curl 中的--cert与--key参数curl --cert client.crt --key client.key https://api.example.com/health对于敏感信息建议将证书与私钥存放为 Monitor Secrets 监控密钥并通过{{monitorSecrets.name}}占位符引用。Monitor Secrets 在服务端解析渲染后的值永远不会出现在 Dashboard 前端避免凭据泄露。mTLS 行为在测试 Probe/Tests/Utils/Monitors/MonitorTypes/WebsiteMonitor.mtls.test.ts 中有专门覆盖。失败重试Retries on FailureRetries on Failure 统计的是首次尝试之后的额外重试次数设为0表示只检查一次设为2表示最多执行三次请求。默认值为3最大值为3。超时不会被重试因为请求超时本身已经覆盖了该次尝试。源码中对这一语义有精确的对应MonitorRetry.canRetry(...)结合DEFAULT_RETRIES_WHEN_UNSET 4未显式设置重试次数时保留历史默认的 5 次尝试决定是否进行下一次尝试同时TimeoutException被明确排除在可重试错误之外。测试用例 Probe/Tests/Utils/Monitors/MonitorTypes/WebsiteMonitor.retries.test.ts 验证了完整矩阵连接持续失败时retry: 0恰好执行 1 次尝试retry: 2恰好执行 3 次尝试未设置 retry 值时保持 5 次尝试[1, 2, 3, 4, 5]连续 503 响应时同样按配置重试3 次尝试每次responseCode均为 503响应时间超过 10 秒时也会触发额外重试responseTimeInMS 10000分支目标解析被拒绝DNS 解析失败、命中私有地址策略拦截时即使配置了 retry 也不会重试因为这类“守卫拒绝”与普通网络故障语义不同重试会让尝试次数泄露 DNS 失败与策略拦截之间的区别这与 EgressGuard 出口守卫 的设计目标一致。此外探针在判定监控器失败后还会执行OnlineCheck.canProbeMonitorWebsiteMonitors()自检如果探针自身网络已不可达则不会把探针的故障误报为网站停机。监控判定标准Monitoring Criteria你可以配置判定标准确定网站何时被视为在线online、受限degraded或离线offline判定维度包括响应状态码Response Status Code—— 检查 HTTP 状态码是否符合预期值如 200、301响应时间Response Time—— 监控响应时间是否超过阈值响应体Response Body—— 检查响应体是否包含或匹配特定内容响应头Response Headers—— 验证特定响应头是否存在或是否符合预期值。时间段评估Evaluating over a period of timeEvaluate this criteria over a period of time在一段时间内评估该标准是判定表单上的独立开关而不是过滤条件。开启后监控器将比较过去一段时间的检查窗口而非仅使用最近一次检查的值在Evaluate中选择聚合方式Average平均值、Sum求和、Maximum Value最大值、Minimum Value最小值、All Values所有值、Any Value任意值在For the last (in minutes)中设定评估时间窗口分钟。需要注意的语义All Values只有在窗口内真正被数据覆盖时才匹配。刚刚创建的监控器或检查记录中断的监控器没有足够的历史数据来评判“最近 N 分钟”的表现此时该判定标准会等待而不是用仅有的一次读数强行匹配Any Value则对应“只要某一次检查出现违规就立即触发”的需求仍然会即时触发。If No Data无数据时选项控制当窗口内无法支撑判定标准时的行为Ignore默认—— 判定标准不匹配。适用于普通的阈值告警场景Trigger—— 将缺失数据本身视为问题。适用于心跳式检查此时“沉默”本身就是一种故障Treat As Zero—— 将窗口视为单个零值。适用于计数器场景此时“没有事件”确实意味着零。从源码看 Website Monitor 的探测流程在 Probe/Utils/Monitors/MonitorTypes/WebsiteMonitor.ts 中ping()的完整探测流程可以归纳为初始化执行上下文创建HttpMonitorExecutionContext默认超时 5000ms可通过timeout覆盖并记录开始时间选择请求方法默认使用GET若开启isHeadRequest则使用HEAD构造并发送请求通过HttpMonitorRequest.prepare(...)准备请求注入 TLS 选项、计时收集器再由WebsiteRequest.fetch(...)实际发送HEAD 回退若目标服务器拒绝 HEAD 请求而接受 GET代码会重新进入循环以 GET 方式重试currentMethod HTTPMethod.GET; continue;重定向处理默认跟随 301/302 等重定向跨源时剥离 TLS 身份开启doNotFollowRedirects则立即返回首个响应记录每次尝试每次尝试无论成功或失败都会写入probeAttempts包含尝试序号、发起/接收时间、响应时间、状态码与失败原因慢响应与失败重试响应时间超过 10 秒或连接失败时在MonitorRetry.canRetry(...)允许且执行上下文仍有时间预算的前提下等待 1 秒后递归重试在线自检对普通网络类失败先确认探针自身在线避免探针故障被误判为监控目标停机返回结构化结果最终返回ProbeWebsiteResponse其中httpTimings携带HttpPhaseTimings分阶段计时信息DNS/TLS/TTFB 等供 Dashboard 展示性能细节。整个实现体现了生产级监控的关键设计可观测性每次尝试都被记录、健壮性HEAD→GET 回退、超时与失败重试、安全性SSRF 防护与 TLS 身份剥离与防误报探针在线自检。总结OneUptime 的 Website Monitor 是一个从配置到执行都相当完整的网站监控方案动态 URL 占位符解决缓存场景下的真实源站探测mTLS 与自签名证书选项覆盖内部服务与安全接入需求可配置的监控判定标准支持从单次检查到时间段聚合的多维度评估而底层 Probe 的重试、重定向、HEAD 回退与探针自检机制则为监控数据的准确性提供了源码级保障。结合 英文版文档 与 Website Monitor 源码 继续深入你可以进一步理解监控事件如何触发告警、状态页更新与后续自动化流程。【免费下载链接】oneuptimeComplete open-source monitoring and observability platform.项目地址: https://gitcode.com/GitHub_Trending/on/oneuptime创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考