agents24 可观测性插件库基于 SLI/SLO 与错误预算的可靠性目标落地指南【免费下载链接】agentsMulti-harness agentic plugin marketplace for Claude Code, Codex, Cursor, OpenCode, GitHub Copilot, and Google Antigravity项目地址: https://gitcode.com/GitHub_Trending/agents24/agents本指南以 slo-implementation 技能 为核心系统讲解如何用 SLI服务等级指标、SLO服务等级目标和错误预算Error Budget建立可度量的可靠性体系并通过 Prometheus 记录规则、多窗口烧速率告警与 Grafana 仪表盘完成从定义到观测、从告警到决策的完整闭环。读完本文你将掌握一套可直接复制到 Prometheus 与 Grafana 环境中的 SLO 配置模板以及基于错误预算驱动发布决策与排期的方法论。SLO 在整个可观测性插件库中的定位在 agents24 的observability-monitoring插件中可观测性能力被拆分为多个相互协作的技能与命令prometheus-configuration负责指标采集、grafana-dashboards负责可视化、distributed-tracing负责链路追踪而slo-implementation则负责定义可靠性目标并持续度量。从 grafana-dashboards 技能 的Related Skills一节可以看到各技能之间通过明确引用互相衔接SLO 仪表盘正是建立在slo-implementation产出的记录规则之上。配套的 slo-implement 命令 则为 Agent 提供了从服务分层、SLI 选择、错误预算计算到 SLO 报告生成的一整套可执行框架本文会将其中的关键实现与技能文档互相印证。SLI / SLO / SLA 三层体系技能文档开篇给出了三者最核心的层级关系这也是实施 SRE 实践必须先厘清的概念边界SLA (Service Level Agreement) ↓ Contract with customers —— 与客户签订的合同 SLO (Service Level Objective) ↓ Internal reliability target —— 内部可靠性目标 SLI (Service Level Indicator) ↓ Actual measurement —— 实际测量指标理解要点SLA 是合同违约可能带来赔偿等法律与商业后果通常由商务与法务确认SLO 是内部目标是团队自己设定的、可达成也可被错误预算消耗的可靠性阈值SLI 是测量本身是好事发生的次数占总次数比例这类可直接计算的指标。三者构成自下而上的支撑关系先有可度量的 SLI才能据此设定 SLO只有内部稳定达成 SLO才有底气对外承诺 SLA。这也是 slo-implement 命令 中SLI 选择与测量 → 目标设定 → 错误预算的执行顺序依据。定义 SLI三种常见指标类型技能文档给出了三类最常见、也最适合用 PromQL 表达的 SLI。所有 SLI 都遵循同一个思想用好事件数 / 总事件数的比率衡量服务质量。1. 可用性 SLIAvailability统计 5xx 以外的成功请求占比周期取 28 天以平滑短期波动# Successful requests / Total requests sum(rate(http_requests_total{status!~5..}[28d])) / sum(rate(http_requests_total[28d]))2. 延迟 SLILatency统计响应时间低于阈值此处为 500ms的请求占比。注意它依赖 histogram 桶le0.5与计数指标_count的组合# Requests below latency threshold / Total requests sum(rate(http_request_duration_seconds_bucket{le0.5}[28d])) / sum(rate(http_request_duration_seconds_count[28d]))3. 持久性 SLIDurability适用于存储类服务衡量成功写入占总写入的比例# Successful writes / Total writes sum(storage_writes_successful_total) / sum(storage_writes_total)从源码看 SLI 的工程化封装在 slo-implement 命令 中上述 SLI 被进一步工程化SLIImplementation类按api / web / batch / streaming四种服务类型分发 SLI 生成逻辑APIAvailabilitySLI负责执行可用性查询LatencySLI支持p50/p95/p99多阈值并行计算ErrorRateSLI则把错误细分为客户端错误4xx、服务端错误5xx、超时504与业务错误error_typebusiness_logic分别度量。其中还给出了一个非常实用的生产细节——排除健康检查与指标端点对 SLI 的干扰sum(rate(http_requests_total{ status!~5.., endpoint!~/health|/metrics }[time_range])) / sum(rate(http_requests_total{ endpoint!~/health|/metrics }[time_range])) * 100/health与/metrics这类内部探活流量会稀释真实用户请求的占比纳入 SLI 统计往往造成看起来达标、实际用户感知下降的假象。设定 SLO 目标目标值与窗口常用可用性目标换算表技能文档给出了从 99% 到 99.99% 的停机时间换算这是设定目标时最常用的参考表SLO %月停机时间年停机时间99%7.2 小时3.65 天99.9%43.2 分钟8.76 小时99.95%21.6 分钟4.38 小时99.99%4.32 分钟52.56 分钟从表格可以直观看到每增加一个 9允许的停机时间约下降一个数量级而对应的工程投入多活、冗余、容量规划却非线性上升。因此在设定目标时需综合考虑用户期望User expectations业务需求Business requirements当前性能基线Current performance可靠性的成本Cost of reliability竞品基准Competitor benchmarks用 YAML 表达 SLO 定义技能文档提供的 SLO 定义文件同时承载了目标值、窗口与 SLI 表达式slos: - name: api_availability target: 99.9 window: 28d sli: | sum(rate(http_requests_total{status!~5..}[28d])) / sum(rate(http_requests_total[28d])) - name: api_latency_p95 target: 99 window: 28d sli: | sum(rate(http_request_duration_seconds_bucket{le0.5}[28d])) / sum(rate(http_request_duration_seconds_count[28d]))注意两个细节一是target直接填百分比数值99.9 对应可用性99 对应95% 请求快于 500ms这一比例目标二是window: 28d意味着用滚动 28 天窗口评估合规性这决定了错误预算的总池子大小。按服务层级匹配目标slo-implement 命令 中的SLOFramework类给出了按服务重要性分层的参考目标可作为目标设定的起点层级典型服务可用性目标p99 延迟错误率critical支付、认证99.95%100ms0.001essential搜索、商品目录99.9%500ms0.01standard推荐、分析99.5%1000ms0.05best_effort批处理、报表99.0%2000ms0.1它的_determine_service_tier()方法会根据服务特征用户影响、业务冲击、依赖关系自动推荐层级并给出选择依据避免团队盲目追求四个 9。错误预算把可靠性换算成可消费的额度计算公式Error Budget 1 - SLO Target配套示例SLO99.9% 可用性错误预算0.1% 每月 43.2 分钟当前错误0.05% 每月 21.6 分钟剩余预算50%错误预算策略分级响应技能文档给出典型的预算消耗分级响应策略error_budget_policy: - remaining_budget: 100% action: Normal development velocity - remaining_budget: 50% action: Consider postponing risky changes - remaining_budget: 10% action: Freeze non-critical changes - remaining_budget: 0% action: Feature freeze, focus on reliability这套策略的实质是把发布权与可靠性表现绑定预算充足时保持正常迭代速度预算告急时收缩变更预算耗尽则冻结功能开发、全力修复可靠性。错误预算的工程化追踪slo-implement 命令 中的ErrorBudgetManager类把上述公式落地为可编程的预算追踪器按窗口总分钟数乘以允许停机比例得到总预算如 30 天窗口、99.9% 目标 → 43.2 分钟再根据实际可用时间计算已消耗分钟数、剩余预算百分比、烧速率burn rate与预计耗尽天数并给出五档状态判定healthy烧速率 ≤ 1attention1 烧速率 ≤ 1.5warning1.5 烧速率 ≤ 2critical2 烧速率exhausted剩余预算 ≤ 0SLODecisionFramework类则进一步把预算状态与发布风险评估矩阵化例如exhausted状态下一律block高风险发布而healthy状态下高风险发布仅需review。这套矩阵让该不该发版从主观判断变成可审计的规则。落地 Prometheus记录规则与合规指标有了 SLI 表达式与 SLO 目标下一步是用Recording Rules记录规则把昂贵的实时查询预计算为低频查询的指标既降低查询开销也让告警与仪表盘共用同一组指标。SLI 记录规则groups: - name: sli_rules interval: 30s rules: # Availability SLI - record: sli:http_availability:ratio expr: | sum(rate(http_requests_total{status!~5..}[28d])) / sum(rate(http_requests_total[28d])) # Latency SLI (requests 500ms) - record: sli:http_latency:ratio expr: | sum(rate(http_request_duration_seconds_bucket{le0.5}[28d])) / sum(rate(http_request_duration_seconds_count[28d]))SLO 合规与错误预算记录规则groups: - name: slo_rules interval: 5m rules: # SLO compliance (1 meeting SLO, 0 violating) - record: slo:http_availability:compliance expr: sli:http_availability:ratio bool 0.999 - record: slo:http_latency:compliance expr: sli:http_latency:ratio bool 0.99 # Error budget remaining (percentage) - record: slo:http_availability:error_budget_remaining expr: | (sli:http_availability:ratio - 0.999) / (1 - 0.999) * 100 # Error budget burn rate - record: slo:http_availability:burn_rate_5m expr: | (1 - ( sum(rate(http_requests_total{status!~5..}[5m])) / sum(rate(http_requests_total[5m])) )) / (1 - 0.999)对关键表达式逐一解读合规指标expr: sli:...:ratio bool 0.999中的bool修饰符把比较结果强制转为 0 或 1方便做时间占比统计剩余预算百分比(实际比例 - 目标) / (1 - 目标) * 100当实际比例等于目标时为 0高于目标为正数、低于目标为负数负值即超支;烧速率短窗口5m内的实际错误率除以允许错误率(1 - 0.999)得到以多快的倍数消耗预算。多窗口烧速率指标仅凭单一窗口的烧速率容易误报瞬时抖动触发、随后恢复因此 slo-implement 命令 中的 SLO 监控实现进一步按服务维度生成了service:success_rate_5m/30m/1h、service:latency_p50/p95/p99_5m与service:error_budget_burn_rate_1h等多窗口系列指标为多窗口告警提供数据基础。SLO 告警多窗口多烧速率模式技能文档的告警规则技能文档基于快烧 慢烧两种经典场景给出告警模板groups: - name: slo_alerts interval: 1m rules: # Fast burn: 14.4x rate, 1 hour window # Consumes 2% error budget in 1 hour - alert: SLOErrorBudgetBurnFast expr: | slo:http_availability:burn_rate_1h 14.4 and slo:http_availability:burn_rate_5m 14.4 for: 2m labels: severity: critical annotations: summary: Fast error budget burn detected description: Error budget burning at {{ $value }}x rate # Slow burn: 6x rate, 6 hour window # Consumes 5% error budget in 6 hours - alert: SLOErrorBudgetBurnSlow expr: | slo:http_availability:burn_rate_6h 6 and slo:http_availability:burn_rate_30m 6 for: 15m labels: severity: warning annotations: summary: Slow error budget burn detected description: Error budget burning at {{ $value }}x rate # Error budget exhausted - alert: SLOErrorBudgetExhausted expr: slo:http_availability:error_budget_remaining 0 for: 5m labels: severity: critical annotations: summary: SLO error budget exhausted description: Error budget remaining: {{ $value }}%这里的数字含义值得展开14.4x 快烧1 小时按 14.4 倍速率烧预算约消耗整月预算的 2%0.1% ÷ 28天 × 1小时 × 14.4 ≈ 2%用于捕捉突发故障severity: critical直接寻呼6x 慢烧6 小时按 6 倍速率消耗约 5% 预算用于捕捉温水煮青蛙式的持续劣化severity: warning开单跟踪预算耗尽error_budget_remaining 0且持续 5 分钟代表本窗口已超支需要立即响应。每个告警都同时要求短窗口与长窗口的烧速率超过阈值and逻辑这正是多窗口设计的核心价值——短窗口保证灵敏、长窗口过滤瞬态噪音两者同时满足才触发。完整版四窗口组合references/details.md 给出了将快烧与慢烧合并为一条告警的完整写法rules: - alert: SLOBurnRateHigh expr: | ( slo:http_availability:burn_rate_1h 14.4 and slo:http_availability:burn_rate_5m 14.4 ) or ( slo:http_availability:burn_rate_6h 6 and slo:http_availability:burn_rate_30m 6 ) labels: severity: critical而 slo-implement 命令 的告警配置则按服务维度serviceapi给出了带team标签与更完整description含预算消耗比例说明的版本并说明告警可路由到不同接收端。配合 monitor-setup 命令 中的 Alertmanager 配置可按severity: critical路由到 PagerDuty、warning路由到 Slack实现分级触达。SLO 仪表盘让预算状态一眼可见技能文档给出了推荐的 Grafana 仪表盘结构自上而下四块信息┌────────────────────────────────────┐ │ SLO Compliance (Current) │ │ ✓ 99.95% (Target: 99.9%) │ ├────────────────────────────────────┤ │ Error Budget Remaining: 65% │ │ ████████░░ 65% │ ├────────────────────────────────────┤ │ SLI Trend (28 days) │ │ [Time series graph] │ ├────────────────────────────────────┤ │ Burn Rate Analysis │ │ [Burn rate by time window] │ └────────────────────────────────────┘仪表盘核心查询# Current SLO compliance sli:http_availability:ratio * 100 # Error budget remaining slo:http_availability:error_budget_remaining # Days until error budget exhausted (at current burn rate) (slo:http_availability:error_budget_remaining / 100) * 28 / (1 - sli:http_availability:ratio) * (1 - 0.999)第三行查询是预计耗尽天数的推算用剩余预算占比除以当前实际错误比例折算出的消耗速度得出以当前速率还能支撑多少天——这是每周评审时最具决策价值的一个数字。从源码看面板配置细节slo-implement 命令 中的create_slo_dashboard()函数给出了可编程生成 Grafana 面板的完整 JSON 结构其中两个细节值得借鉴SLO Summary 面板stat 类型用绝对阈值给合规值着色—— 99.5红色、99.5~99.9黄色、≥ 99.9绿色单位设为percentError Budget Status 面板gauge 类型剩余预算公式为100 * (1 - ((1 - success_rate/100) / (1 - slo_target/100)))红色阈值 20%、黄色 50%、绿色 50% 以上min: 0, max: 100Burn Rate Trend 面板同时绘制 1h / 6h / 24h 三条烧速率曲线并对 14.4 阈值配置内置告警条件。评审流程与最佳实践分层评审节奏references/details.md 给出三类评审周期形成周复盘 → 月总结 → 季度调整的治理节奏每周评审当前 SLO 合规情况、错误预算状态、趋势分析、故障影响每月评审SLO 达成度、错误预算消耗、故障事后复盘postmortem、SLO 调整每季度评审SLO 是否仍然相关、目标调整、流程改进、工具链增强。十条最佳实践从面向用户的服务开始Start with user-facing services使用多个 SLI可用性、延迟等设定可达成而非 100% 的 SLO用多窗口告警降低噪音持续一致地跟踪错误预算定期评审 SLO记录 SLO 决策过程与业务目标对齐自动化 SLO 报告用 SLO 指导优先级排序报告自动化slo-implement 命令 中的SLOReporter类将月度报告生成自动化用avg_over_time聚合月度可用性、用quantile_over_time聚合月度延迟分位数然后输出包含执行摘要、SLO 达成表格、故障分析与改进建议的 HTML 报告——这正对应最佳实践中自动化 SLO 报告一条。进阶SLO as Code 与渐进式目标对于希望把 SLO 纳入 GitOps 流程的团队slo-implement 命令 还提供了两个进阶模式SLO as Code以声明式 YAML 定义 SLO将烧速率告警直接内嵌在 SLO 对象中支持版本管理与评审apiVersion: slo.dev/v1 kind: ServiceLevelObjective metadata: name: api-availability namespace: production spec: service: api-service indicator: type: ratio counter: metric: http_requests_total filters: - status_code ! 5xx total: metric: http_requests_total objectives: - displayName: 30-day rolling window window: 30d target: 0.999 alerting: burnRates: - severity: critical shortWindow: 1h longWindow: 5m burnRate: 14.4 - severity: warning shortWindow: 6h longWindow: 30m burnRate: 3渐进式目标implement_progressive_slos()给出了四阶段达标路线——第 1 月建立基线99.0%、第 2 月初步改进99.5%、第 3 月生产就绪99.9%、此后持续卓越99.95%。对于尚未建立可靠性基线的服务这是比一步到位更稳妥的落地方式。与本插件库其他能力的协作方式作为 observability-monitoring 插件 的技能之一slo-implementation与其他模块的分工与衔接如下能力在本插件中的位置与 SLO 的关系指标采集与记录规则prometheus-configuration 技能提供 SLI 表达式所依赖的原始指标可视化grafana-dashboards 技能承载 SLO 合规、预算与烧速率面板全面监控搭建monitor-setup 命令覆盖 Prometheus 抓取、Alertmanager 路由等前置设施SLO 落地执行slo-implement 命令本文引用的框架类SLOFramework、SLIImplementation、ErrorBudgetManager 等均来自此命令从 monitor-setup 命令 中的 Prometheus 配置可以看到指标抓取依赖http_requests_total、http_request_duration_seconds等由应用埋点其MetricsCollector类使用 prom-client 的 Histogram/Counter 实现暴露的指标——这些正是本文所有 PromQL 表达式的数据来源。实践时建议按照埋点 → 抓取 → 记录规则 → 告警 → 仪表盘的顺序将 SLO 能力叠加在已有的监控地基之上。综上本技能提供了一条从概念SLI/SLO/SLA到配置PromQL 与 YAML、从度量记录规则到行动烧速率告警与错误预算决策的完整实施路径与插件库中的 Prometheus、Grafana 能力共同构成可落地的可靠性工程闭环。【免费下载链接】agentsMulti-harness agentic plugin marketplace for Claude Code, Codex, Cursor, OpenCode, GitHub Copilot, and Google Antigravity项目地址: https://gitcode.com/GitHub_Trending/agents24/agents创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考