OneUptime 网站监控Website Monitor实战指南配置、动态占位符、重试与监控判定标准【免费下载链接】oneuptimeComplete open-source monitoring and observability platform.项目地址: https://gitcode.com/GitHub_Trending/on/oneuptime导读本文围绕 OneUptime 开源可观测性平台中的Website Monitor网站监控功能展开讲解如何通过定期 HTTP 请求监控任意网站或网页的可用性、性能与响应行为覆盖监控器创建流程、URL 动态占位符、重定向/自签名证书/mTLS 等高级选项以及基于状态码、响应时间、响应体与响应头的监控判定标准。读完本文你将掌握从创建第一个网站监控器到配置精确在线/降级/离线判定规则、再到结合源码理解其底层探测与重试机制的完整能力。一、Website Monitor 是什么Website Monitor 是 OneUptime 的监控器类型之一。它的核心工作原理是Probe探针按调度周期向目标网站 URL 发起 HTTP 请求并基于响应结果评估监控对象的健康状态。正如 website-monitor.md 所述OneUptime 会定期向你的网站 URL 发送 HTTP 请求并检查它是否返回了正确的响应。通过网站监控你可以实现监控网站的正常运行时间uptime与可用性availability追踪响应时间与性能表现校验 HTTP 状态码是否符合预期检查响应头response headers是否正确在用户感知到故障之前发现停机。从源码结构看网站监控的探测逻辑实现在 Probe/Utils/Monitors/MonitorTypes/WebsiteMonitor.ts 中其ping方法负责发起请求、记录尝试probeAttempts、计算响应时间通过process.hrtime并在失败时整理友好错误信息与RequestFailedDetails。它支持GET与HEAD两种请求方式isHeadRequest为 true 时使用 HEAD且当服务器拒绝 HEAD 时会自动回退到 GET并集成了 HTTP 各阶段耗时DNS、连接、TLS、TTFB 等的计时采集这些数据可作为后续性能监控与诊断的依据。二、创建 Website Monitor在 OneUptime Dashboard 中创建网站监控器的步骤如下进入 OneUptime Dashboard 的Monitors监控器页面点击Create Monitor创建监控器在监控器类型中选择Website网站输入要监控的网站 URL按需配置监控判定标准Monitoring Criteria与高级选项。创建完成后Probe 便会按设定的检查间隔开始向目标 URL 发起探测请求。三、配置选项详解3.1 Website URL在 URL 字段中输入要监控的网站完整地址必须包含协议例如https://example.com协议http://或https://是必须的Probe 会依据协议判断连接方式并据此标记isSecure在 WebsiteMonitor.ts 中通过url.protocol Protocol.HTTPS判定。使用 HTTPS 时TLS 证书校验默认开启。3.2 动态 URL 占位符Dynamic URL Placeholders当监控位于 CDN 或缓存代理后面的 URL 时监控器可能拿到的是缓存响应而不是源站origin server的真实响应。为了在每次检查时强制穿透缓存可以使用动态 URL 占位符——每次探测请求发起前占位符会被替换为唯一值。支持的占位符占位符说明示例值{{timestamp}}替换为当前 Unix 时间戳秒1719500000{{random}}替换为随机唯一字符串a3f8b2c1d4e5f6a7b8c9d0e1f2a3b4c5示例配置带占位符的监控 URLhttps://example.com/health?cb{{timestamp}}每次监控检查时URL 会被替换为https://example.com/health?cb1719500000 https://example.com/health?cb1719500005 ...也可以使用{{random}}在每次请求时生成唯一字符串https://example.com/health?nocache{{random}}源码实现印证占位符的替换逻辑位于 Probe/Utils/Monitors/Monitor.ts 的resolveUrlPlaceholders方法。它先检测 URL 中是否包含{{timestamp}}或{{random}}都不包含则直接返回原 URL随后将timestamp替换为Math.floor(Date.now() / 1000)秒级 Unix 时间戳将random替换为通过ObjectID.generate().toString().replace(/-/g, )生成的去连字符 UUID 字符串最后用替换后的字符串重新构造 URL。这意味着占位符可以出现在 URL 的任意位置路径、查询参数等且每次探测请求都会拿到不同的值。3.3 高级选项不跟随重定向Do Not Follow Redirects默认情况下OneUptime 会跟随 HTTP 重定向301、302 等。如果希望监控的是重定向响应本身而非最终目的地请开启此选项。源码中对应doNotFollowRedirects参数在 WebsiteMonitor.ts 中当该选项开启时收到响应后直接返回不再进入重定向解析循环。重定向跟随逻辑由HttpMonitorRequest.getRedirectRequest实现会基于状态码与响应头判断是否需要继续跟随并跟踪已跟随次数redirectsFollowed当跨域crosses origin时会停止向新域名携带原 TLS 客户端身份includeTlsIdentity false避免客户端证书被发送给不可信主机。允许自签名证书Allow Self-Signed Certificates开启此选项可跳过 TLS 证书校验。当目标服务器使用自签名或不受信任的 TLS 证书时例如内部预发布环境非常有用。该选项对应allowSelfSignedCertificates参数会被传递到HttpMonitorRequest.prepare的 TLS 配置中见 WebsiteMonitor.ts作用于底层 HTTP agent 的证书校验行为。注意开启后会降低安全级别请仅在信任目标服务器环境的场景下使用。客户端证书mTLS如果端点要求双向 TLS 认证mutual TLS请开启Use client certificate (mTLS)并配置以下内容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三个值分别对应tlsClientCertificate、tlsClientKey、tlsClientKeyPassphrase参数会作为 TLS 身份信息注入HttpMonitorRequest.prepare见 WebsiteMonitor.ts由底层 HTTPS agent 在握手阶段出示。对于敏感值建议将证书与私钥存为 Monitor Secrets监控器密钥并以{{monitorSecrets.name}}引用。Monitor Secrets 在服务端解析渲染后的值永远不会出现在 Dashboard 中避免密钥通过前端暴露。失败重试Retries on FailureRetries on Failure统计的是首次尝试之后的额外重试次数0表示只执行 1 次检查2表示最多执行 3 次1 次初始 2 次重试默认值为3最大值为3。超时不会被重试因为请求超时本身已经覆盖了这一次尝试重试只会徒劳占用时间窗口。源码实现印证重试语义由 Probe/Utils/Monitors/MonitorRetry.ts 统一保证。canRetry使用 1 基的尝试编号attemptNumber与解析后的重试数比较attemptNumber resolveRetries(retries)才继续重试。resolveRetries使用??语义而非||——显式配置的0是真实答案绝不会回退到默认值只有undefined、null、非有限数或负数才会落到defaultRetries。在 WebsiteMonitor.ts 中当调用方未配置重试时默认值为4注释说明这是为了保持与“重试计入首次之后”语义之前相同的总尝试次数 5 次。另外两个值得注意的源码细节在成功路径中如果响应时间超过 10 秒只要仍有重试配额且执行上下文允许等待会再给一次机会见 WebsiteMonitor.ts在失败路径中BadDataException与TimeoutException不会触发重试前者是配置本身非法、后者是超时已被排除在重试之外其余网络类失败才进入MonitorRetry.canRetry判断见 WebsiteMonitor.ts。四、监控判定标准Monitoring Criteria你可以配置判定标准基于以下维度决定网站何时被判定为在线Online、降级Degraded或离线OfflineResponse Status Code响应状态码—— 检查 HTTP 状态码是否匹配预期值例如 200、301Response Time响应时间—— 监控响应时间是否超过阈值Response Body响应体—— 检查响应体是否包含或匹配特定内容Response Headers响应头—— 验证特定响应头是否存在或匹配预期值。从探测端看ProbeWebsiteResponse见 WebsiteMonitor.ts完整携带了statusCode、responseBody、responseHeaders、responseTimeInMS等字段正是这些判定标准所需的数据来源当请求失败时还会附带failureCause、requestFailedDetails以及每次尝试的probeAttempts明细方便定位失败原因。4.1 在时间段内评估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)最近多少分钟决定时间窗口长度。4.2 All Values 与 Any Value 的语义差异All Values只在窗口内确实被完整数据覆盖时才匹配。一个刚创建的监控器或者检查记录已停止的监控器并没有足够的历史数据来对“最近 N 分钟”下结论此时该标准会等待而不是用仅有的一次读数去匹配。Any Value则是“只要单次检查一发生越界就立刻告诉我”的设置它仍然会立即触发。简单归纳需要“连续 N 分钟内所有检查都满足条件才判定”的场景用All Values需要“任何一次检查触发越界就告警”的场景用Any Value心跳类告警的实时性诉求。4.3 If No Data窗口内无数据时怎么办当时间窗口内没有足够数据支撑该判定标准时If No Data选项决定处理方式选项行为适用场景Ignore默认该标准不匹配普通阈值告警静默等待数据恢复Trigger把缺失数据本身当作问题触发心跳式heartbeat检查静默本身就是一种故障Treat As Zero把整个窗口视为一个零值参与比较计数器类指标“没有事件”确实意味着零这三档语义非常实用默认的Ignore适合绝大多数阈值告警避免因短暂数据缺口产生误报Trigger适合“探活”类场景——一旦在窗口内收不到任何检查数据例如目标彻底失联导致检查记录中断立即视为故障Treat As Zero则适合对“事件计数”类数据做聚合判定把无数据正确解释为计数为零。五、与源码对应的行为总结文档中的配置/行为源码位置关键实现动态 URL 占位符替换Probe/Utils/Monitors/Monitor.tsresolveUrlPlaceholders使用正则替换{{timestamp}}与{{random}}请求发起、重试、计时Probe/Utils/Monitors/MonitorTypes/WebsiteMonitor.tsping方法HEAD/GET、重定向跟随、process.hrtime计时、10 秒慢响应追加重试重试语义0 表示只跑一次Probe/Utils/Monitors/MonitorRetry.tscanRetry用 1 基尝试号比较resolveRetries用??保护显式 0不跟随重定向 / mTLS / 自签名证书WebsiteMonitor.tsdoNotFollowRedirects、tlsClientCertificate、tlsClientKey、allowSelfSignedCertificates注入HttpMonitorRequest.prepare响应数据采集状态码/响应体/响应头/耗时WebsiteMonitor.tsProbeWebsiteResponse结构体字段即判定标准的输入相关的探测端测试用例也验证了这些行为例如 WebsiteMonitor.retries.test.ts、WebsiteMonitor.mtls.test.ts、WebsiteMonitor.ssrf.test.ts 与 WebsiteMonitorTargetResolution.test.ts有兴趣深入源码的读者可以直接查看这些测试了解各选项的边界行为。六、小结Website Monitor 是 OneUptime 覆盖网站可用性与性能监控的入口能力通过 Probe 周期性 HTTP 探测 可组合的判定标准将“在线/降级/离线”的判定从单次请求扩展到时间窗口聚合动态 URL 占位符解决了 CDN/代理缓存导致的探测失真问题mTLS、自签名证书与失败重试等高级选项则覆盖了内部环境与认证类端点的监控需求。配合 Monitor Secrets 管理敏感凭据网站监控可以安全、可靠地融入你的可观测性体系。【免费下载链接】oneuptimeComplete open-source monitoring and observability platform.项目地址: https://gitcode.com/GitHub_Trending/on/oneuptime创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
OneUptime 网站监控Website Monitor实战指南配置、动态占位符、重试与监控判定标准【免费下载链接】oneuptimeComplete open-source monitoring and observability platform.项目地址: https://gitcode.com/GitHub_Trending/on/oneuptime导读本文围绕 OneUptime 开源可观测性平台中的Website Monitor网站监控功能展开讲解如何通过定期 HTTP 请求监控任意网站或网页的可用性、性能与响应行为覆盖监控器创建流程、URL 动态占位符、重定向/自签名证书/mTLS 等高级选项以及基于状态码、响应时间、响应体与响应头的监控判定标准。读完本文你将掌握从创建第一个网站监控器到配置精确在线/降级/离线判定规则、再到结合源码理解其底层探测与重试机制的完整能力。一、Website Monitor 是什么Website Monitor 是 OneUptime 的监控器类型之一。它的核心工作原理是Probe探针按调度周期向目标网站 URL 发起 HTTP 请求并基于响应结果评估监控对象的健康状态。正如 website-monitor.md 所述OneUptime 会定期向你的网站 URL 发送 HTTP 请求并检查它是否返回了正确的响应。通过网站监控你可以实现监控网站的正常运行时间uptime与可用性availability追踪响应时间与性能表现校验 HTTP 状态码是否符合预期检查响应头response headers是否正确在用户感知到故障之前发现停机。从源码结构看网站监控的探测逻辑实现在 Probe/Utils/Monitors/MonitorTypes/WebsiteMonitor.ts 中其ping方法负责发起请求、记录尝试probeAttempts、计算响应时间通过process.hrtime并在失败时整理友好错误信息与RequestFailedDetails。它支持GET与HEAD两种请求方式isHeadRequest为 true 时使用 HEAD且当服务器拒绝 HEAD 时会自动回退到 GET并集成了 HTTP 各阶段耗时DNS、连接、TLS、TTFB 等的计时采集这些数据可作为后续性能监控与诊断的依据。二、创建 Website Monitor在 OneUptime Dashboard 中创建网站监控器的步骤如下进入 OneUptime Dashboard 的Monitors监控器页面点击Create Monitor创建监控器在监控器类型中选择Website网站输入要监控的网站 URL按需配置监控判定标准Monitoring Criteria与高级选项。创建完成后Probe 便会按设定的检查间隔开始向目标 URL 发起探测请求。三、配置选项详解3.1 Website URL在 URL 字段中输入要监控的网站完整地址必须包含协议例如https://example.com协议http://或https://是必须的Probe 会依据协议判断连接方式并据此标记isSecure在 WebsiteMonitor.ts 中通过url.protocol Protocol.HTTPS判定。使用 HTTPS 时TLS 证书校验默认开启。3.2 动态 URL 占位符Dynamic URL Placeholders当监控位于 CDN 或缓存代理后面的 URL 时监控器可能拿到的是缓存响应而不是源站origin server的真实响应。为了在每次检查时强制穿透缓存可以使用动态 URL 占位符——每次探测请求发起前占位符会被替换为唯一值。支持的占位符占位符说明示例值{{timestamp}}替换为当前 Unix 时间戳秒1719500000{{random}}替换为随机唯一字符串a3f8b2c1d4e5f6a7b8c9d0e1f2a3b4c5示例配置带占位符的监控 URLhttps://example.com/health?cb{{timestamp}}每次监控检查时URL 会被替换为https://example.com/health?cb1719500000 https://example.com/health?cb1719500005 ...也可以使用{{random}}在每次请求时生成唯一字符串https://example.com/health?nocache{{random}}源码实现印证占位符的替换逻辑位于 Probe/Utils/Monitors/Monitor.ts 的resolveUrlPlaceholders方法。它先检测 URL 中是否包含{{timestamp}}或{{random}}都不包含则直接返回原 URL随后将timestamp替换为Math.floor(Date.now() / 1000)秒级 Unix 时间戳将random替换为通过ObjectID.generate().toString().replace(/-/g, )生成的去连字符 UUID 字符串最后用替换后的字符串重新构造 URL。这意味着占位符可以出现在 URL 的任意位置路径、查询参数等且每次探测请求都会拿到不同的值。3.3 高级选项不跟随重定向Do Not Follow Redirects默认情况下OneUptime 会跟随 HTTP 重定向301、302 等。如果希望监控的是重定向响应本身而非最终目的地请开启此选项。源码中对应doNotFollowRedirects参数在 WebsiteMonitor.ts 中当该选项开启时收到响应后直接返回不再进入重定向解析循环。重定向跟随逻辑由HttpMonitorRequest.getRedirectRequest实现会基于状态码与响应头判断是否需要继续跟随并跟踪已跟随次数redirectsFollowed当跨域crosses origin时会停止向新域名携带原 TLS 客户端身份includeTlsIdentity false避免客户端证书被发送给不可信主机。允许自签名证书Allow Self-Signed Certificates开启此选项可跳过 TLS 证书校验。当目标服务器使用自签名或不受信任的 TLS 证书时例如内部预发布环境非常有用。该选项对应allowSelfSignedCertificates参数会被传递到HttpMonitorRequest.prepare的 TLS 配置中见 WebsiteMonitor.ts作用于底层 HTTP agent 的证书校验行为。注意开启后会降低安全级别请仅在信任目标服务器环境的场景下使用。客户端证书mTLS如果端点要求双向 TLS 认证mutual TLS请开启Use client certificate (mTLS)并配置以下内容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三个值分别对应tlsClientCertificate、tlsClientKey、tlsClientKeyPassphrase参数会作为 TLS 身份信息注入HttpMonitorRequest.prepare见 WebsiteMonitor.ts由底层 HTTPS agent 在握手阶段出示。对于敏感值建议将证书与私钥存为 Monitor Secrets监控器密钥并以{{monitorSecrets.name}}引用。Monitor Secrets 在服务端解析渲染后的值永远不会出现在 Dashboard 中避免密钥通过前端暴露。失败重试Retries on FailureRetries on Failure统计的是首次尝试之后的额外重试次数0表示只执行 1 次检查2表示最多执行 3 次1 次初始 2 次重试默认值为3最大值为3。超时不会被重试因为请求超时本身已经覆盖了这一次尝试重试只会徒劳占用时间窗口。源码实现印证重试语义由 Probe/Utils/Monitors/MonitorRetry.ts 统一保证。canRetry使用 1 基的尝试编号attemptNumber与解析后的重试数比较attemptNumber resolveRetries(retries)才继续重试。resolveRetries使用??语义而非||——显式配置的0是真实答案绝不会回退到默认值只有undefined、null、非有限数或负数才会落到defaultRetries。在 WebsiteMonitor.ts 中当调用方未配置重试时默认值为4注释说明这是为了保持与“重试计入首次之后”语义之前相同的总尝试次数 5 次。另外两个值得注意的源码细节在成功路径中如果响应时间超过 10 秒只要仍有重试配额且执行上下文允许等待会再给一次机会见 WebsiteMonitor.ts在失败路径中BadDataException与TimeoutException不会触发重试前者是配置本身非法、后者是超时已被排除在重试之外其余网络类失败才进入MonitorRetry.canRetry判断见 WebsiteMonitor.ts。四、监控判定标准Monitoring Criteria你可以配置判定标准基于以下维度决定网站何时被判定为在线Online、降级Degraded或离线OfflineResponse Status Code响应状态码—— 检查 HTTP 状态码是否匹配预期值例如 200、301Response Time响应时间—— 监控响应时间是否超过阈值Response Body响应体—— 检查响应体是否包含或匹配特定内容Response Headers响应头—— 验证特定响应头是否存在或匹配预期值。从探测端看ProbeWebsiteResponse见 WebsiteMonitor.ts完整携带了statusCode、responseBody、responseHeaders、responseTimeInMS等字段正是这些判定标准所需的数据来源当请求失败时还会附带failureCause、requestFailedDetails以及每次尝试的probeAttempts明细方便定位失败原因。4.1 在时间段内评估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)最近多少分钟决定时间窗口长度。4.2 All Values 与 Any Value 的语义差异All Values只在窗口内确实被完整数据覆盖时才匹配。一个刚创建的监控器或者检查记录已停止的监控器并没有足够的历史数据来对“最近 N 分钟”下结论此时该标准会等待而不是用仅有的一次读数去匹配。Any Value则是“只要单次检查一发生越界就立刻告诉我”的设置它仍然会立即触发。简单归纳需要“连续 N 分钟内所有检查都满足条件才判定”的场景用All Values需要“任何一次检查触发越界就告警”的场景用Any Value心跳类告警的实时性诉求。4.3 If No Data窗口内无数据时怎么办当时间窗口内没有足够数据支撑该判定标准时If No Data选项决定处理方式选项行为适用场景Ignore默认该标准不匹配普通阈值告警静默等待数据恢复Trigger把缺失数据本身当作问题触发心跳式heartbeat检查静默本身就是一种故障Treat As Zero把整个窗口视为一个零值参与比较计数器类指标“没有事件”确实意味着零这三档语义非常实用默认的Ignore适合绝大多数阈值告警避免因短暂数据缺口产生误报Trigger适合“探活”类场景——一旦在窗口内收不到任何检查数据例如目标彻底失联导致检查记录中断立即视为故障Treat As Zero则适合对“事件计数”类数据做聚合判定把无数据正确解释为计数为零。五、与源码对应的行为总结文档中的配置/行为源码位置关键实现动态 URL 占位符替换Probe/Utils/Monitors/Monitor.tsresolveUrlPlaceholders使用正则替换{{timestamp}}与{{random}}请求发起、重试、计时Probe/Utils/Monitors/MonitorTypes/WebsiteMonitor.tsping方法HEAD/GET、重定向跟随、process.hrtime计时、10 秒慢响应追加重试重试语义0 表示只跑一次Probe/Utils/Monitors/MonitorRetry.tscanRetry用 1 基尝试号比较resolveRetries用??保护显式 0不跟随重定向 / mTLS / 自签名证书WebsiteMonitor.tsdoNotFollowRedirects、tlsClientCertificate、tlsClientKey、allowSelfSignedCertificates注入HttpMonitorRequest.prepare响应数据采集状态码/响应体/响应头/耗时WebsiteMonitor.tsProbeWebsiteResponse结构体字段即判定标准的输入相关的探测端测试用例也验证了这些行为例如 WebsiteMonitor.retries.test.ts、WebsiteMonitor.mtls.test.ts、WebsiteMonitor.ssrf.test.ts 与 WebsiteMonitorTargetResolution.test.ts有兴趣深入源码的读者可以直接查看这些测试了解各选项的边界行为。六、小结Website Monitor 是 OneUptime 覆盖网站可用性与性能监控的入口能力通过 Probe 周期性 HTTP 探测 可组合的判定标准将“在线/降级/离线”的判定从单次请求扩展到时间窗口聚合动态 URL 占位符解决了 CDN/代理缓存导致的探测失真问题mTLS、自签名证书与失败重试等高级选项则覆盖了内部环境与认证类端点的监控需求。配合 Monitor Secrets 管理敏感凭据网站监控可以安全、可靠地融入你的可观测性体系。【免费下载链接】oneuptimeComplete open-source monitoring and observability platform.项目地址: https://gitcode.com/GitHub_Trending/on/oneuptime创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
