查询不跑一遍就不知道
一句话总结
PromQL 即使写错，也可能不报错，只返回空结果。因此，只有在真实指标上运行，才能知道查询是否正确。
为什么必须使用真正的 Prometheus
前面的模块编写了多条 PromQL，但那些实验环境中根本没有 Prometheus，所以无法确认查询是否给出预期答案。
PromQL 即使语法正确，也经常会悄悄返回空结果。因为不是错误而是空结果，很难察觉。
- 范围选择器短于采集周期时，
rate()没有足够的点可计算 - 标签名称写错一个，就没有匹配的时间序列
- 记录规则从注册之后才开始计算，所以历史区间为空
up == 0 捕获不到的情况
这是最有价值的陷阱。up == 0 只在目标存在但没有响应时为真。
如果整个 Pod 消失，目标会从服务发现中移除，up 时间序列本身也会消失。不存在并不等于 0，所以告警不会触发。
“全都死了却没有任何告警”就是这样发生的。
up == 0 대상이 있는데 응답이 없다
absent(up{job="x"}) 그 job 의 대상이 아예 없다
count(up{job="x"}) < 3 예상보다 적다 ← 실무에서 가장 쓸모 있다
配置没有生效的位置
ConfigMap 卷由 kubelet 定期同步（约 60 秒）。传播完成前执行 reload，会再次读取旧配置，但**reload 仍返回 200**。于是人会误以为配置本身有错，转而修改错误的位置。
而使用 subPath 挂载时，更新根本不会传播。
让告警真正有用的规则
告警一多，人就不再看，它们也就等于不存在。遵守以下四点，可以过滤掉大多数无用告警。
针对症状，而不是原因。 “CPU 超过 80%”不是叫醒人的理由，“支付错误率超过 5%”才是。原因指标放在仪表板，告警只针对用户正在经历的问题。
务必添加 for。 因瞬时尖峰叫醒人，会失去信任。
- alert: HighErrorRate
expr: |
sum(rate(http_requests_total{status=~"5.."}[5m]))
/ sum(rate(http_requests_total[5m])) > 0.05
for: 10m # 10분 동안 계속 참일 때만
labels: {severity: page}
annotations:
summary: "5xx 비율 {{ $value | humanizePercentage }}"
runbook: "https://…/runbooks/high-error-rate"
附上运行手册链接。 没有说明凌晨 3 点醒来后该查看什么的告警，只会制造焦虑。
按燃烧率告警。 如果 SLO 为 99.9%，一个月的错误预算是 43 分钟。用“按当前速度，何时会耗尽预算”作为条件，就能用同一套规则捕获短而严重与长而轻微的问题。
빠른 소진: 1시간 창에서 예산의 2% 이상 → 즉시 호출
느린 소진: 6시간 창에서 예산의 5% 이상 → 티켓
指标基数会杀死 Prometheus
每个标签值都会形成一条时间序列。把 user_id 作为标签，时间序列就会按用户数量增长，内存需求也随之增加。
# 지금 무엇이 시계열을 많이 쓰나
topk(10, count by (__name__)({__name__=~".+"}))
# 특정 지표의 라벨별 카디널리티
count(count by (route) (http_request_duration_seconds_count))
Prometheus 的 /status/tsdb 页面也会显示排名靠前的指标和标签。超过 100 万条时间序列后，内存会以数 GB 增长，重启时 WAL 回放变长，指标可能连续几分钟看起来为空。
值域无限增长的内容（请求 ID、电子邮件、完整 URL）应放进日志或追踪，而不是指标。这种区分占可观测性设计的一半。
实务中真正重要的事
不要依赖 up == 0，告警应使用 count(...) < N。 消失的目标不是 0，而是不存在，所以 up == 0 会在最大的事故中保持沉默。为每个已知预期数量的 job 设置一条数量告警，价值很高。
修改配置后，不要相信 reload 返回的 200，要重新读取已生效的值。 ConfigMap 传播最长需要 60 秒，subPath 挂载则完全不会更新。通过 /api/v1/status/config 查看当前运行配置，是唯一可靠的方法。
记录规则从注册时刻起计算。 仪表板迁移到规则后，历史区间会显示为空。迁移期间应将两个表达式并列保留一段时间，对照重叠区间。
下一个实验将在真正的 Prometheus 上亲自验证这些现象。