指标 vs 日志

Prometheus 擅长时间序列与聚合；日志 保留单次请求的上下文与堆栈。两者互补，不能互相替代。

学习目标

• 按场景选择 metrics 或 logs 作为第一排查手段
• 知道 trace-id 如何串联 logs 与 traces
• 理解 metrics 高基数限制与 logs 采样策略

核心内容

决策表

问题	首选	原因
过去 1 小时 QPS 是否翻倍？	Metrics	rate() 一眼看趋势
某 userId 报名为何 500？	Logs	需 stack trace、参数
网关到 DB 哪一跳慢？	Traces	跨服务时序（见 sc-observability）
磁盘将满？	Metrics	node_filesystem_avail_bytes
谁改了配置导致异常？	Logs / 审计	结构化 log 含操作者

典型工作流

Grafana 告警 HighErrorRate 触发
    → PromQL 确认 uri=/api/enroll 5xx 升高
    → Loki/ELK 搜 trace-id 或 status=500 + uri
    → 定位 NullPointerException 行号
    → 修复发布；metrics 验证 error rate 回落

Spring Boot 默认 logback 输出到 stdout；K8s 用 kubectl logs 或集群日志栈采集（kubernetes-essentials）。

关联字段

sc-observability 强调 trace-id 写入 MDC：

# logback-spring.xml 概念：pattern 含 %X{traceId}
logging:
  pattern:
    console: "%d{ISO8601} [%X{traceId}] %-5level %logger - %msg%n"

metrics 的 uri label 与 logs 的 request path 应对齐命名，便于跳转。

勿用 logs 做聚合

用 grep 数 5xx 行数不如 rate(http_server_requests_seconds_count{status=~"5.."}) 准确且便宜。指标聚合、日志取证 是分工底线。

练习

• 虚构一次「错误率升但单接口」事故，写 4 步排查顺序（含 metrics 与 logs）
• 说明为何把 user_id 放进 Prometheus label 危险，放进 log 字段却可行
• 在 backend 日志里找一条 HTTP 访问 log，对照 Grafana 同一时间点的 QPS

小结

Metrics 回答「多少、多快、多坏」；Logs 回答「这一次发生了什么」。 下一课把 Spring Cloud 可观测性与本 track 串起来。