HTTP(S) - 关键字监视器对两个可达目标重复触发 Axios 30 秒超时;来自同一个容器的独立请求成功

我发现了这些相关问题/推请

我发现这些相关但并不相同的报告:

• 275, 白天“ 超时48000ms 的 “ 超时数 ” , 但站点仍然在上? ” —— 类似 Axios 超时, 而单独的检查成功, 但不同的( Windows/ Docker 桌面) 环境和超时值 。

• 4534,`将卷发作为HTTP(s)显示器后端的能力 ' ——报告Node.js HTTP在卷发成功时对目标超时。 这是一个关闭的特性请求, 而不是这个错误 。
• 第3752号,`在读完ETIMEDOUT后粘住监测器 ' ——不同的行为:我的监测器重新试取并恢复;它们不会被卡住。

安全政策

• 我阅读并同意了Uptime Kuma的安全政策。

说明

两台 " HTTP(S) -- -- 关键字 " 显示器在第一次尝试时多次产生 " 超过30 000米的超时 " ,然后在重试时恢复。 在以下几个方面继续这样做:

• 将 " Uptime Kuma " 从2.5.0更新为2.5.4;
• 重新启动 " Uptime Kuma " 服务/集装箱;
• 简化两个监测的URL; 使用30秒请求超时,60秒重试间隔,5分钟心跳间隔.

这两个公共目标可以到达,在孤立的进程中检查时,从运行的Uptime Kuma集装箱 迅速返回预期关键词。 每个目标进行20个请求的Axios控制测试,使用显示器的超时,重定向限制,状态码规则,和类似浏览器的"Acept"标题,完成20/20关键字匹配,没有出错. 观测到的最大控制测试时间为147米和93米。

这不是一个广泛的全例问题。 该案例有55个监视器. 在最新的24小时窗口中,只有3个显示器有任何 " 等待 " 心跳;这两个显示器是唯一一个有10个或10个以上待发心跳的显示器,其他每个显示器最多都有一个。

我还没有一个最小的确定性独立复制。 我报告生产行为和上述控制 是为了了解 哪些额外的诊断能区分 久生的熊猫进程/Axios行为 和特定目标网络处理

是否有一种建议的方法来捕捉请求一级的诊断,仅针对这些没有记录反应机构或证书的监控ID? 特别是,我要确定为什么长期监测程序在同一个集装箱中一个孤立的Axios程序取得成功时才会出现。

• 复制步骤

1. 如下所部署环境所描述的 " 上行 " 库马2.5.4。
2. 创建这两个 " HTTP(S) -- -- 关键字 " 显示器:

• 监视器 * URL * 关键词 * Interval * 重复间隔 * 重复 * 请求超时 * 。

---

LHB iServ + https://lhb-do-edu.de/iserv/auth/login + iServ → 300 s → 60 s → 2 s 30 s → LHB webUntis 服务器 : : https://lhb-do.webuntis.com/WebUntis/ : : : : : : : : : : : : : : : : : : : : : : : : : : : : :

1. 对两个显示器,使用 " GET " 、验证TLS、接受状态代码 . . . . . . .