Prometheus 监控报告编写：SLI报告SLI 报告编写：理清 SLI、SLO、SLA 三者的关系，约定标签体系与

之前写过《第11篇监控报告编写：SLO/SLI 与数据分析方法》，但那一篇把 SLI 和 SLO 混在了一起，也没有细化 SLO 是如何定义和配置的。为了让两部分都讲透，这里把它拆成两篇：本篇只针对 SLI 报告，SLO 报告另起一篇。

本篇目标：理清 SLI 指标怎么选、状态怎么判、报告由哪些部分组成，并给出可直接落地的巡检报告模板与对应的 PromQL。

一、核心概念回顾

SLI、SLO、SLA 经常被混用，其实它们描述的是同一件事的三个层次：

概念	全称	定义	示例
SLI	Service Level Indicator	服务等级指标，对服务某方面表现的可量化测量	5xx 错误率 = 0.02%；P99 延迟 = 800ms
SLO	Service Level Objective	服务等级目标，对 SLI 设定的目标值和时间窗口	30 天内 5xx 错误率 ≤ 0.1%（可用性 99.9%）
SLA	Service Level Agreement	服务等级协议，对客户承诺的 SLO 及违约后果	可用性低于 99.9% 则赔偿

推导链：

业务目标 → SLA（对外承诺） → SLO（内部目标） → SLI（测量指标） → Prometheus 数据

二、SLI 报告 vs SLO 报告

对比维度	SLI 报告	SLO 报告
面向对象	SRE、运维、开发、值班人员	产品、业务、管理层、客户成功、SRE 负责人
核心问题	当前系统运行状态如何？哪里异常？	服务可靠性目标是否达成？错误预算还剩多少？
侧重点	指标当前值、趋势、异常、健康度评分	目标达成率、错误预算消耗、Burn Rate、合规风险
时间窗口	短窗口为主：5m、1h、当日	长窗口为主：7d、30d、90d
输出频率	日报、实时看板、告警	周报、月报、季度评审、发布门禁
指标范围	可覆盖大量 SLI：CPU、内存、JVM、QPS、延迟、错误率等	通常只选少数关键 SLI：可用性、延迟、吞吐
数据粒度	服务、实例、接口级明细	系统/服务级聚合，强调目标与预算
典型内容	指标表格、异常明细、Top 20 最差、趋势对比	SLO 达成率、错误预算余额、Burn Rate、风险等级
决策用途	故障排查、容量规划、日常巡检	发布决策、资源投入、SLA 合规、可靠性改进
与告警关系	阈值告警：CPU > 80%	预算告警：错误预算消耗 > 50%、Burn Rate 过高
本质	数据报告	目标管理报告

一句话概括：SLI 报告回答「现在怎么样」，SLO 报告回答「目标达标没有」。

三、先约定好标签体系

标签体系是数据分析的基础。在写任何 PromQL、排任何一张表之前，先把标签约定下来，否则后面每一章的口径都会漂移。

系统层：job_code（系统编码）、job_alias（系统名称），两者 1:1。
服务层：svc。
实例层：instance。
入口标识：ingress（布尔标签，ingress="true" 表示该服务是入口服务，一般是 Gateway）。
聚合时优先按 job_code，job_alias 仅用于展示。

不同层的指标需要下钻到的粒度不同，因此聚合维度按层区分：

层	覆盖指标	聚合维度
应用层	QPS、5xx/4xx 错误率、平均延迟、P99/最大延迟	`job_code, job_alias, svc`
主机层	CPU、内存、磁盘、网络错误率	`job_code, job_alias, svc, instance`
JVM	堆使用率、Full GC 次数/分	`job_code, job_alias, svc, instance`

应用层聚合到服务（svc），即同一服务跨实例合并。
主机层与 JVM 层需要下钻到实例（instance），因此聚合维度额外带上 instance。
各层都保留 job_alias 仅用于展示，job_code 是唯一的聚合主键。
入口服务筛选：系统级 SLI 只统计各系统的入口服务，即带 ingress="true" 的服务（一般是 Gateway）；服务级明细与主机/JVM 指标不施加该过滤。

四、状态判定规则

制定 SLI 报告涉及的标签以及各状态阈值，可根据实际情况调整。

报告要给出「红黄绿」，就需先定义「多少算严重」。下表是本文的阈值定义，后面章节的判定窗口都以此表为准：

层级	指标	正常	警告	严重
应用层	5xx 错误率	≤0.01%	≤0.1%	>0.1%
应用层	P99/最大延迟	≤800ms	≤1500ms	>1500ms
应用层	平均延迟	≤200ms	≤500ms	>500ms
主机层	CPU 使用率	≤60%	≤80%	>80%
主机层	内存使用率	≤80%	80%~90%	>90%
主机层	磁盘使用率	≤70%	≤80%	>80%
主机层	网络错误率	≤0.01%	≤0.1%	>0.1%
JVM	堆使用率	≤60%	≤80%	>80%
JVM	Full GC 次数/分	0	≤2	>2

状态映射关系：

状态	条件
🟢 正常	所有指标均正常
🟡 警告	中间状态为警告
🔴 严重	只要有一个指标是严重，则为严重

状态判定按对应层的聚合粒度进行：应用层判到 svc，主机层与 JVM 判到 instance；系统级状态 = 该系统下所有服务/实例状态的「最差」取值。

三条展示原则

正文只放最差 Top N：多系统、多服务时全量展示会淹没重点。系统级可全量，服务级默认最差 20 条，完整数据放附件。
状态优先于评分：用 🟢🟡🔴 表达健康状态，比复杂健康度评分更直观，也更容易在团队内达成共识。
兼容无直方图：若 Spring Boot 未开启 percentiles-histogram，用 http_server_requests_seconds_max 替代 P99，并在报告中注明。

注：第六、七两章，是利用 AI 工具根据第三、四、五章所定义内容自动生成，使用的是 WorkBuddy 工具，其他工具一样能达到效果。

五、报告组成

序号	组成部分	目的	主要内容	展示规则
1	报告元信息	明确数据口径	报告日期、数据范围、Prometheus 数据源、生成时间、显示规则	固定头部
2	全局概览	一眼看整体健康	系统数、服务数、实例数、健康分布、全局关键 SLI、未恢复告警数	汇总卡片/小表
3	系统级 SLI 汇总	所有系统横向对比	每个系统一行：服务数、QPS、5xx、平均延迟、P99/最大延迟、最差服务、状态。其中QPS、5xx、平均延迟、P99/最大延迟均只针对入口网关服务，而不是统计所有服务	全部系统或最差 Top 20
4	服务级 SLI 明细	定位到具体服务	最差服务 Top N：系统、服务、QPS、5xx、4xx、平均延迟、P99/最大延迟、状态	默认最差 20 条
5	异常与告警	驱动处理动作	未恢复告警、异常指标、当前值、阈值、建议动作	按严重程度 Top 20
6	趋势对比	判断恶化/改善	与昨日/上周对比：5xx、P99、CPU、告警数	系统级，最差 Top 20
7	附录与下载	支撑下钻与复现	SLI 定义、阈值、标签说明、完整数据附件	附件 JSON/CSV

正文只放最差 Top N：多系统、多组服务时，全量展示会淹没重点。系统级可全量，服务级默认最差 20 条，完整数据放附件。
状态优先于评分：所有「状态」列统一使用 🟢🟡🔴，判定依据见第四章。
分层下钻：第 3、4 项为应用层指标，聚合维度 job_code, job_alias, svc；第 5 项中的主机/JVM 指标聚合维度为 job_code, job_alias, svc, instance。
兼容无直方图：若 Spring Boot 未开启 percentiles-histogram，用 http_server_requests_seconds_max 替代 P99，并在报告中注明。

六、巡检报告模板

默认同时生成 markdown 和 html 两种格式：html 可用于邮件/门户展示，markdown 用于归档与二次编辑。模板由 AI 工具生成，生成后可再调整。

模板严格按第五章的 7 个部分组织，字段与顺序一一对应；所有阈值、状态判定与第四章保持一致；聚合维度与第三章保持一致。

# SLI 巡检报告


**报告日期**：2026-10-08
**数据范围**：2026-10-07 00:00 ~ 2026-10-07 23:59
**Prometheus 数据源**：http://prometheus:9090
**生成时间**：2026-10-08 08:00:12
**标签口径**：应用层按 `job_code, job_alias, svc` 聚合；主机层与 JVM 按 `job_code, job_alias, svc, instance` 聚合；`job_alias` 仅用于展示；系统级 SLI 仅统计 `ingress="true"` 的入口服务
**显示规则**：系统级全量展示；服务级、异常与告警、趋势对比默认展示最差 20 条；完整明细见附件

---

## 一、全局概览

| 指标 | 数值 |
|---|---:|
| 系统总数 | 36 |
| 服务总数 | 214 |
| 实例总数 | 486 |
| 健康分布 | 🟢 27 / 🟡 7 / 🔴 2 |
| 全局 5xx 错误率 | 0.07% |
| 全局 P99 延迟 | 620ms |
| 未恢复告警 | Critical 3 / Warning 12 |

> 健康分布按「四、状态判定规则」的系统级聚合判定；任一指标达到严重即为 🔴。

---

## 二、系统级 SLI 汇总

> 应用层指标，聚合维度 `job_code, job_alias, svc`。QPS、5xx、平均延迟、P99/最大延迟均只统计该系统中 `ingress="true"` 的**入口服务**（一般是 Gateway），不含内部服务间调用。

| 系统编码 | 系统名称 | 服务数 | QPS | 5xx | 平均延迟 | P99/最大延迟 | 最差服务 | 状态 |
|---|---|---:|---:|---:|---:|---:|---|---|
| RISK | 风控系统 | 2 | 600 | 1.20% | 1.5s | 3.2s | risk-eval | 🔴 严重 |
| CRM | 客户关系管理 | 3 | 900 | 0.15% | 450ms | 1.8s | crm-user | 🔴 严重 |
| INV | 库存中心 | 3 | 1200 | 0.08% | 300ms | 900ms | inv-sync | 🟡 警告 |
| DATA | 数据平台 | 6 | 400 | 0.05% | 250ms | 1.1s | data-etl | 🟡 警告 |
| ORDER | 订单中心 | 5 | 3200 | 0.02% | 120ms | 680ms | order-query | 🟡 警告 |
| USER | 用户中心 | 4 | 1800 | 0.03% | 110ms | 520ms | user-auth | 🟡 警告 |
| PAY | 支付中心 | 4 | 1500 | 0.01% | 90ms | 450ms | pay-callback | 🟢 正常 |
| GW | 统一网关 | 1 | 5000 | 0.00% | 35ms | 180ms | gateway | 🟢 正常 |

> 其余 28 个系统中 🟢 正常 25 个、🟡 警告 3 个，完整数据见附件。

---

## 三、服务级 SLI 最差 Top 20

> 应用层指标，聚合维度 `job_code, job_alias, svc`。

| 系统 | 服务 | QPS | 5xx | 4xx | 平均延迟 | P99/最大延迟 | 状态 |
|---|---|---:|---:|---:|---:|---:|---|
| RISK | risk-eval | 120 | 1.20% | 0.80% | 1.5s | 3.2s | 🔴 严重 |
| CRM | crm-user | 300 | 0.15% | 0.80% | 450ms | 1.8s | 🔴 严重 |
| CRM | crm-order | 180 | 0.06% | 0.40% | 320ms | 1.4s | 🟡 警告 |
| DATA | data-etl | 80 | 0.05% | 0.30% | 250ms | 1.1s | 🟡 警告 |
| DATA | data-sync | 120 | 0.03% | 0.20% | 220ms | 950ms | 🟡 警告 |
| INV | inv-sync | 200 | 0.08% | 0.50% | 300ms | 900ms | 🟡 警告 |
| CRM | crm-query | 250 | 0.04% | 0.20% | 200ms | 850ms | 🟡 警告 |
| ORDER | order-create | 300 | 0.02% | 0.10% | 150ms | 700ms | 🟡 警告 |
| INV | inv-query | 500 | 0.03% | 0.10% | 120ms | 600ms | 🟡 警告 |
| ORDER | order-query | 800 | 0.02% | 0.30% | 80ms | 450ms | 🟡 警告 |
| USER | user-auth | 900 | 0.03% | 0.10% | 70ms | 380ms | 🟡 警告 |
| USER | user-profile | 400 | 0.02% | 0.10% | 90ms | 500ms | 🟡 警告 |
| ORDER | order-cancel | 200 | 0.01% | 0.10% | 110ms | 520ms | 🟢 正常 |
| PAY | pay-callback | 400 | 0.01% | 0.20% | 95ms | 420ms | 🟢 正常 |
| USER | user-login | 500 | 0.01% | 0.10% | 60ms | 300ms | 🟢 正常 |
| PAY | pay-query | 600 | 0.01% | 0.10% | 80ms | 360ms | 🟢 正常 |
| INV | inv-deduct | 700 | 0.01% | 0.10% | 60ms | 300ms | 🟢 正常 |
| DATA | data-query | 100 | 0.01% | 0.10% | 180ms | 800ms | 🟢 正常 |
| PAY | pay-notify | 300 | 0.00% | 0.10% | 70ms | 340ms | 🟢 正常 |
| GW | gateway | 5000 | 0.00% | 0.20% | 35ms | 180ms | 🟢 正常 |

> 共 214 个服务，正文展示最差 20 条；完整明细见附件。

---

## 四、异常与告警

> 应用层行聚合维度 `job_code, job_alias, svc`；主机层与 JVM 行聚合维度 `job_code, job_alias, svc, instance`（对象列以实例名标识）。

| 系统 | 对象 | 维度 | 指标 | 当前值 | 阈值 | 状态 | 建议动作 |
|---|---|---|---|---|---|---|---|
| RISK | risk-eval | 应用层 | 5xx 错误率 | 1.20% | >0.1% 严重 | 🔴 严重 | 检查风控规则引擎与下游依赖 |
| CRM | crm-user | 应用层 | P99 延迟 | 1.8s | >1500ms 严重 | 🔴 严重 | 排查 DB 慢查询与连接池 |
| CRM | crm-order | 应用层 | P99 延迟 | 1.4s | ≤1500ms 警告 | 🟡 警告 | 排查下游调用与线程池 |
| DATA | data-etl | 应用层 | P99 延迟 | 1.1s | ≤1500ms 警告 | 🟡 警告 | 检查批处理资源与调度 |
| INV | inv-sync | 应用层 | P99 延迟 | 900ms | ≤1500ms 警告 | 🟡 警告 | 检查同步任务与锁竞争 |
| ORDER | order-create | 应用层 | 平均延迟 | 320ms | ≤500ms 警告 | 🟡 警告 | 排查慢接口与下游耗时 |
| ORDER | host-order-02 | 主机层 | 内存使用率 | 92% | >90% 严重 | 🔴 严重 | 检查内存泄漏或扩容 |
| ORDER | host-order-02 | 主机层 | CPU 使用率 | 82% | >80% 严重 | 🔴 严重 | 排查定时任务或流量突增 |
| INV | host-inv-03 | 主机层 | 磁盘使用率 | 82% | >80% 严重 | 🔴 严重 | 清理日志或扩容磁盘 |
| CRM | host-crm-01 | 主机层 | 内存使用率 | 85% | 80%~90% 警告 | 🟡 警告 | 关注堆外内存与缓存增长 |
| GW | host-gw-01 | 主机层 | 网络错误率 | 0.02% | ≤0.1% 警告 | 🟡 警告 | 检查网卡丢包与链路质量 |
| DATA | data-etl:8080 | JVM | 堆使用率 | 72% | ≤80% 警告 | 🟡 警告 | 检查缓存与大对象 |
| PAY | pay-callback:8080 | JVM | Full GC 次数/分 | 3 | >2 严重 | 🔴 严重 | 排查内存分配与 GC 参数 |

> 按严重程度排序，正文展示 Top 20；完整告警列表见附件。

---

## 五、趋势对比

> 与昨日同口径对比；应用层指标按 `job_code, job_alias, svc` 聚合后回卷到系统级，CPU 按 `job_code, job_alias, svc, instance` 聚合后回卷到系统级。

| 系统 | 5xx 昨日 | 5xx 今日 | P99 昨日 | P99 今日 | CPU 昨日 | CPU 今日 | 告警 昨日 | 告警 今日 | 趋势判断 |
|---|---:|---:|---:|---:|---:|---:|---:|---:|---|
| RISK | 0.80% | 1.20% | 2.8s | 3.2s | 68% | 82% | 2 | 4 | 恶化 |
| CRM | 0.10% | 0.15% | 1.5s | 1.8s | 61% | 73% | 1 | 3 | 恶化 |
| DATA | 0.03% | 0.05% | 900ms | 1.1s | 55% | 62% | 0 | 2 | 恶化 |
| INV | 0.06% | 0.08% | 850ms | 900ms | 58% | 60% | 1 | 1 | 略恶化 |
| USER | 0.02% | 0.03% | 480ms | 520ms | 52% | 54% | 0 | 1 | 略恶化 |
| ORDER | 0.02% | 0.02% | 670ms | 680ms | 60% | 59% | 0 | 0 | 平稳 |
| GW | 0.00% | 0.00% | 175ms | 180ms | 35% | 34% | 0 | 0 | 平稳 |

> 「告警」为未恢复告警数。如需与上周对比，按同一表格追加「上周」列即可。

---

## 六、附录与下载

**标签说明**

| 层级/层 | 标签或维度 | 说明 |
|---|---|---|
| 系统层 | `job_code` | 系统编码，聚合主键 |
| 系统层 | `job_alias` | 系统名称，仅用于展示，与 `job_code` 1:1 |
| 服务层 | `svc` | 服务名 |
| 实例层 | `instance` | 实例/主机标识 |
| 服务标识 | `ingress` | `ingress="true"` 表示入口服务（一般是 Gateway），用于系统级 SLI 汇总 |
| 应用层聚合维度 | `job_code, job_alias, svc` | QPS、5xx/4xx、平均延迟、P99/最大延迟 |
| 主机层/JVM 聚合维度 | `job_code, job_alias, svc, instance` | CPU、内存、磁盘、网络、堆使用率、Full GC |

**阈值定义**

| 指标 | 正常 | 警告 | 严重 |
|---|---|---|---|
| 5xx 错误率 | ≤0.01% | ≤0.1% | >0.1% |
| P99/最大延迟 | ≤800ms | ≤1500ms | >1500ms |
| 平均延迟 | ≤200ms | ≤500ms | >500ms |
| CPU 使用率 | ≤60% | ≤80% | >80% |
| 内存使用率 | ≤80% | 80%~90% | >90% |
| 磁盘使用率 | ≤70% | ≤80% | >80% |
| 网络错误率 | ≤0.01% | ≤0.1% | >0.1% |
| 堆使用率 | ≤60% | ≤80% | >80% |
| Full GC 次数/分 | 0 | ≤2 | >2 |

**附件**：
- `sli_detail_2026-10-07.csv`：全部系统与服务明细
- `sli_detail_2026-10-07.json`：结构化原始数据

> 若 Spring Boot 未开启直方图，P99 列自动替换为「最大延迟」，并在报告元信息中注明。

*本报告由 SLI 巡检系统自动生成。*

七、涉及的PromQL

本章由 AI 工具自动生成，若你重新用 AI 跑一遍，需检查生成的 PromQL 是否正确。小节顺序按第四章「状态判定规则」的层级排布：应用层 → 主机层 → JVM → 告警 → 趋势。

1. 应用层（`job_code, job_alias, svc`）

# QPS
sum by (job_code, job_alias, svc) (
  rate(http_server_requests_seconds_count[5m])
)

# 5xx 错误率（%）
sum by (job_code, job_alias, svc) (
  rate(http_server_requests_seconds_count{status=~"5.."}[5m])
)
/
sum by (job_code, job_alias, svc) (
  rate(http_server_requests_seconds_count[5m])
) * 100

# 4xx 错误率（%）
sum by (job_code, job_alias, svc) (
  rate(http_server_requests_seconds_count{status=~"4.."}[5m])
)
/
sum by (job_code, job_alias, svc) (
  rate(http_server_requests_seconds_count[5m])
) * 100

# 平均延迟（ms）
sum by (job_code, job_alias, svc) (
  rate(http_server_requests_seconds_sum[5m])
)
/
sum by (job_code, job_alias, svc) (
  rate(http_server_requests_seconds_count[5m])
) * 1000

# P99 延迟（ms）——已开启直方图时
histogram_quantile(
  0.99,
  sum by (job_code, job_alias, svc, le) (
    rate(http_server_requests_seconds_bucket[5m])
  )
) * 1000

# P95 延迟（ms）——已开启直方图时
histogram_quantile(
  0.95,
  sum by (job_code, job_alias, svc, le) (
    rate(http_server_requests_seconds_bucket[5m])
  )
) * 1000

# 最大延迟（ms）——未开启直方图时替代 P99
max by (job_code, job_alias, svc) (
  http_server_requests_seconds_max
) * 1000

# 自动回退：有 bucket 用 P99，无 bucket 用最大延迟
histogram_quantile(
  0.99,
  sum by (job_code, job_alias, svc, le) (
    rate(http_server_requests_seconds_bucket[5m])
  )
) * 1000
or
max by (job_code, job_alias, svc) (
  http_server_requests_seconds_max
) * 1000

系统级 SLI 汇总：系统级一行只统计该系统的入口服务，因此在服务级结果之上再加一层 ingress="true" 过滤，并按系统回卷。以 QPS 与 5xx 错误率为例，平均延迟、P99/最大延迟同理：

# 系统级 QPS（仅入口服务）
sum by (job_code, job_alias) (
  rate(http_server_requests_seconds_count{ingress="true"}[5m])
)

# 系统级 5xx 错误率（%，仅入口服务）
sum by (job_code, job_alias) (
  rate(http_server_requests_seconds_count{ingress="true", status=~"5.."}[5m])
)
/
sum by (job_code, job_alias) (
  rate(http_server_requests_seconds_count{ingress="true"}[5m])
) * 100

2. 主机层（`job_code, job_alias, svc, instance`）

# CPU 使用率（%）
100 - (
  avg by (job_code, job_alias, svc, instance) (
    rate(node_cpu_seconds_total{mode="idle"}[5m])
  ) * 100
)

# 内存使用率（%）
(
  1 - sum by (job_code, job_alias, svc, instance) (node_memory_MemAvailable_bytes)
    / sum by (job_code, job_alias, svc, instance) (node_memory_MemTotal_bytes)
) * 100

# 磁盘使用率（%）
(
  1 - sum by (job_code, job_alias, svc, instance, mountpoint) (
    node_filesystem_avail_bytes{fstype!~"tmpfs|overlay"}
  )
    / sum by (job_code, job_alias, svc, instance, mountpoint) (
    node_filesystem_size_bytes
  )
) * 100

# 系统负载 / 核数
sum by (job_code, job_alias, svc, instance) (node_load1)
/
count by (job_code, job_alias, svc, instance) (
  node_cpu_seconds_total{mode="idle"}
)

# 网络接收错误率（%）
sum by (job_code, job_alias, svc, instance) (
  rate(node_network_receive_errs_total[5m])
)
/
sum by (job_code, job_alias, svc, instance) (
  rate(node_network_receive_packets_total[5m])
) * 100

# 网络发送错误率（%）
sum by (job_code, job_alias, svc, instance) (
  rate(node_network_transmit_errs_total[5m])
)
/
sum by (job_code, job_alias, svc, instance) (
  rate(node_network_transmit_packets_total[5m])
) * 100

3. JVM 运行时（`job_code, job_alias, svc, instance`）

# 堆使用率（%）
sum by (job_code, job_alias, svc, instance) (
  jvm_memory_used_bytes{area="heap"}
)
/
sum by (job_code, job_alias, svc, instance) (
  jvm_memory_max_bytes{area="heap"}
) * 100

# Full GC 次数/分钟
sum by (job_code, job_alias, svc, instance) (
  increase(jvm_gc_pause_seconds_count{action="end of major GC"}[1m])
)

# GC 暂停时间（5 分钟累计，秒）
sum by (job_code, job_alias, svc, instance) (
  rate(jvm_gc_pause_seconds_sum[5m])
)

# 活跃线程数
sum by (job_code, job_alias, svc, instance) (
  jvm_threads_live_threads
)

# HikariCP 连接池使用率（%）
sum by (job_code, job_alias, svc, instance) (
  hikaricp_connections_active
)
/
sum by (job_code, job_alias, svc, instance) (
  hikaricp_connections_max
) * 100

4. 告警统计

告警序列 ALERTS 由 Prometheus 告警规则产生，默认仅带 job_code（及 severity）等标签；如需下钻到服务/实例，需在告警规则中补齐 svc/instance 标签。

# 未恢复告警数（按系统）
sum by (job_code) (
  ALERTS{alertstate="firing"}
)

# 未恢复告警数（按系统 + 严重程度）
sum by (job_code, severity) (
  ALERTS{alertstate="firing"}
)

# 未恢复告警数（按系统 + 服务，需告警规则已带 svc 标签）
sum by (job_code, job_alias, svc) (
  ALERTS{alertstate="firing"}
)

5. 趋势对比（昨日 / 上周）

对应第五章第 6 项，用于对比 5xx、P99、CPU 与告警数。应用层指标按 job_code, job_alias, svc 聚合，主机层指标按 job_code, job_alias, svc, instance 聚合；如需系统级趋势，可在结果上再按 job_code 汇总。昨日用 offset 1d，上周同期用 offset 1w，其余结构不变。

# 5xx 错误率（昨日，%）
sum by (job_code, job_alias, svc) (
  rate(http_server_requests_seconds_count{status=~"5.."}[5m] offset 1d)
)
/
sum by (job_code, job_alias, svc) (
  rate(http_server_requests_seconds_count[5m] offset 1d)
) * 100

# P99 延迟（昨日，ms）
histogram_quantile(
  0.99,
  sum by (job_code, job_alias, svc, le) (
    rate(http_server_requests_seconds_bucket[5m] offset 1d)
  )
) * 1000

# CPU 使用率（昨日，%）
100 - (
  avg by (job_code, job_alias, svc, instance) (
    rate(node_cpu_seconds_total{mode="idle"}[5m] offset 1d)
  ) * 100
)

# 未恢复告警数（昨日，按系统）
sum by (job_code) (
  ALERTS{alertstate="firing"} offset 1d
)

# 上周同期：将上述 offset 1d 替换为 offset 1w 即可

八、两种报告编写方式

写报告重复性很强、也很费时间，但它又是很必要的产物。数据齐了、模板定了，剩下的就是让它自动跑起来。下面给出两种自动化路径。

1. 利用 AI 工具自动生成报告

当公司内部已部署 AI 工具时，这是最省力的方式。关键操作只有几步：

把第三到七章直接转成 SKILL：标签体系、状态判定规则、报告组成、报告模板、PromQL 这五章合起来，就是一份完整的技能定义。也上传了一份 SKILL 供参考：sli-inspection-report
人工检查 SKILL 是否符合要求：核对阈值、聚合维度、Top N 规则是否与第五、四、三章一致。
直接调用 SKILL 生成报告：跑一次即可产出 markdown 与 html 两份报告。

2. 开发 Python 脚本自动生成报告

适用于公司内部没有部署 AI 工具、或 AI 能力较弱支撑不了报告生成的情况。此时可以退而用脚本，但生成的效果会差一些。

做法是：用 AI 工具把上一步的 SKILL 转成可执行的 Python 脚本，在公司内网执行脚本、查看输出效果即可。

九、小结

本篇核心要点：

先定义，后生成：第三、四、五章是「定义」（标签体系、状态判定规则、报告组成），第六、七章是「按定义生成的结果」（模板、PromQL）。口径只写一遍，全篇引用。
聚合维度按层区分：应用层 job_code, job_alias, svc，主机层与 JVM job_code, job_alias, svc, instance；job_alias 只用于展示，job_code 是唯一主键；系统级 SLI 只统计 ingress="true" 的入口服务。
状态判定只有一份阈值表：🟢 全正常、🟡 有警告、🔴 有一个严重即为严重；系统级状态取最差。
正文只放最差 Top N：服务级、异常与告警、趋势对比默认 20 条，完整明细进附件。
两种落地方式：有 AI 工具就把这几章转成 SKILL 直接生成，没有就把 SKILL 转成 Python 脚本在内网跑。

SLI 报告解决的是「今天怎么样」，SLO 报告解决的是「目标达标没有」。

Prometheus 监控报告编写：SLI报告