支持基于指标的 SLOs (不仅仅是监控 uptime)

您的功能请求是否与问题有关? 目前,OneUptime 中的 SLO 只能基于 Monitor Uptime 构建 — SLI 始终是"监控器状态不处于恶劣状态的时间百分比"。无法直接基于连续度量值(延迟、错误率或任何自定义可靠性数值)构建 SLO,尽管团队在其他地方定义 SLO 的方式通常就是如此。 这对于两个常见的相关用例来说是一个真正的限制:

1. 延迟/性能 SLO。网站/API 监控器已经支持基于响应时间的标准(在阈值以上标记监控器为恶劣/离线状态),并且响应时间已经作为指标内部进行跟踪。但是,无法直接基于该指标构建 SLO — 目前要接近延迟 SLO 的唯一方法是通过标准规则将响应时间转换为离线/恶劣状态的离散监控器状态,然后在该结果状态上构建普通 Monitor-Uptime SLO。这行之有效,但它将连续测量折合为通过/不通过门槛 — SLO 数学中没有 p95/p99 跟踪,无法了解速度如何,仅仅是"是否超过线"。 2. 外部计算的 SLI(例如,正确性百分比、写入延迟或任何自定义可靠性信号,在 OneUptime 外部计算)。无法将计算值直接输入到 SLO 中。最接近的工作绕行需要两个独立、不协调的路径:通过 OTLP 将值推送为自定义指标(这对于仪表板可视化工作可行,但指标不会触发警报或 SLO),并单独将相同值发送到一个接收请求监控器,其中包含一个在阈值以上将其状态切换为恶劣/离线的标准规则,以通过与上述状态转换技巧相同的方式获得警报和 SLO。这确实可行,但这意味着需要计算值一次,并推送两次,没有对"真实数值"(仅在仪表板图块上可见)和"阈值衍生的状态"(SLO 实际看到的唯一内容)之间的调整 — 并且推送到接收请求监控器的原始值似乎根本没有作为可视化的时间序列数据保留,因此也无法从该路径中进行可视化。 两种情况都指向了同一个基本缺陷: SLO 只能消耗监控器的离线/恶劣/良好状态,而不能直接消耗连续指标值。