使用 SLO 运维 Runifold

运维信号

把 Runifold 当作因果执行系统运维，而不只是 HTTP Client。衡量根 Run 成功率与延迟、 Model Duration 与 First Chunk、Agent Turn、Tool 与 Delegation Failure、Workflow Queue 与 Lease、MCP Stage、预算耗尽和持久 Store 健康。

每个 Terminal Failure 都应保留规范 Error Kind 与 Run Tree 关联。“Provider Error”太宽， 无法支持可执行目标。

观测层

OtelModel 观测规范模型调用与路由，OtelJournal 导出语义 Run 证据，OtelRuntime 连接配置好的 OpenTelemetry 边界。Workflow Budget 与 Task Governance Module 增加 Projection、Supervisor、Cleanup 与 Retention Metric。

在稳定 Library Boundary 上埋点。只包装最外层 HTTP Handler 会隐藏慢 Tool、重复 Turn、 Fallback Attempt 与等待时间。

默认目标

内置 Runbook 从下面的基线开始：

这些是保守示例，不是普遍承诺。如果直接 Model、持久 Workflow、Queue Delay 或 Realtime Session 是用户可见产品，应分别定义目标。

故障处理流程

失败升高时，先按规范 Error Kind 拆分，沿 Exemplar 进入 Run Tree，再检查 Provider、 Tool、Child、Store 与 Effect 边界。延迟问题要拆分 Queue、Model Time、First Chunk、 Turn 与 Callable Duration。预算压力先比较各资源维度，再提高上限。

不能用“打开全面重试”处理事故。先确认 Retry Safety、Stream Commit State、幂等性、 剩余 Deadline 与下游容量。

基数与内容

Prometheus Label 只包含有界 Status、Error Kind、Stage 与 Route Class。Run ID、 Invocation ID、Agent 或 Tool Name、Request ID、Tenant 与用户扩展属于 Trace 或受控日志， 不能成为 Label。

OpenTelemetry 默认脱敏。只有明确目的、访问控制、Retention、删除与事故审阅后，才启用 Prompt 或 Output Capture。可观测系统不能成为第二个不受治理的数据仓库。

安装内置观测资产

从服务实际使用的 Runifold 版本导出 SLO 资产，避免 Dashboard 查询与指标名漂移：

use std::fs;
 
fs::create_dir_all("artifacts/observability")?;
fs::write(
    "artifacts/observability/prometheus-rules.yaml",
    runifold::otel::slo::PROMETHEUS_RULES,
)?;
fs::write(
    "artifacts/observability/grafana-dashboard.json",
    runifold::otel::slo::GRAFANA_DASHBOARD,
)?;

部署前校验 Prometheus 规则，把 Dashboard 先导入预发布数据源，并主动产生一次 成功、超时、Tool 失败和预算耗尽。如果面板为空，先核对埋点和标签名，不要 直接放宽告警。把 SLO 目标、燃烧率对应动作、负责人和回滚条件与部署资产放在 一起管理。