指标与 SLI

这一课你将能做到

1. 区分 Counter / Gauge / Histogram / Summary 四种指标类型，说清各自适合测什么、用错会怎样
2. 为判题接口写出 3 条 SLI（可用率、延迟、错误率），每条都有明确的分子和分母
3. 用 PromQL 写出 QPS、错误率、P99 延迟查询，并解释高基数标签为什么会拖垮时序库

为什么要学

没有指标，告警和 SLO 都无从谈起；选错指标类型，数字会「看起来有、算起来错」。典型翻车现场：把 Counter 的累计值当瞬时 QPS 直接配阈值告警，结果服务重启归零后告警狂叫又自动恢复；只看平均延迟觉得「系统很健康」，实际 5% 的用户判题结果等了 60 秒。

指标（Metrics） 把系统行为压缩成可聚合的数值时序；SLI（Service Level Indicator，服务水平指标） 是其中「对用户真正重要」的那几条。面试里「你们系统怎么度量健康」「P99 和平均值的区别」「标签基数怎么回事」都属于本课射程，是必须背到脱口而出的程度。

先建立图像

类型	行为（人话）	典型用途	常见坑
Counter	只增不减的累计计数器	请求总数、错误次数、判题提交量	拿裸累计值当「当前速率」
Gauge	可升可降的瞬时值	队列长度、连接池占用、在线 worker 数	对它用 rate()（通常不对）
Histogram	把观测值丢进一组桶	延迟、响应体大小 → 算 P95/P99	桶边界和业务延迟量级不符
Summary	客户端算好分位数	少见；一般改用 Histogram	分位数无法跨实例再聚合

一次判题提交（原始事件）
   ├─ Counter:   judge_submissions_total{result="accepted"} += 1
   ├─ Gauge:     judge_queue_depth = 42（Kafka 待判题消息数，瞬时值）
   └─ Histogram: judge_duration_seconds 观察本次判题耗时

SLI 不是「再采一套新指标」，而是从已有信号里选出用户最在意的定义：
  可用率 = 非 5xx 请求数 / 总请求数
  错误率 = 5xx 请求数 / 总请求数
  延迟   = P99 是否低于约定阈值（如提交接口 < 500ms）

跟着做

步骤 1：给判题接口选定三条 SLI

针对 POST /api/judge/submissions，在记事本写下：

SLI-1 可用率 = status!~"5.." 的请求数 / 总请求数（滚动 5 分钟窗口）
SLI-2 延迟   = http_server_requests_seconds 的 P99 < 500ms
SLI-3 错误率 = status=~"5.." 的请求数 / 总请求数

关键要求：每条 SLI 都有明确的分子和分母。写不出分子分母的「指标」只是图表，不是 SLI。

步骤 2：用 Micrometer 埋一个业务 Counter 和 Timer

在判题提交服务里：

@Service
public class SubmissionService {

    private final MeterRegistry registry;

    public SubmissionService(MeterRegistry registry) {
        this.registry = registry;
    }

    public SubmissionDto submit(SubmitRequest req) {
        // Counter：判题提交总量，标签只用低基数的 language
        registry.counter("judge_submissions_total",
                "language", req.getLanguage())   // java/python/cpp，种类有限
            .increment();

        // Timer：记录判题创建耗时（Timer 底层就是 Histogram）
        return Timer.builder("judge_submission_create")
            .register(registry)
            .record(() -> doSubmit(req));
    }
}