histogram_quantile 不能直接算 p99，因其依赖预设桶边界，线性插值导致偏差超30%；桶过宽会低估p99，过密则引发样本爆炸；默认桶无法覆盖80–120ms关键区间，需按slo上限（如p99=100ms）精细配置le标签。
latency bucket 为什么不能直接用 histogram_quantile 算 P99？
因为 histogram_quantile 依赖 Prometheus 的直方图指标（_bucket 时间序列），而 SLO 中的 latency 目标必须基于服务端真实观测到的请求分布，不是查询时“拟合”出来的近似值。桶边界（le 标签）设得太宽，P99 就会严重低估；设得太密，又导致样本爆炸和存储压力。
-
le="0.1"和le="0.2"之间没数据，但实际 95% 请求落在 0.15s，这时histogram_quantile(0.99, ...)只能线性插值，结果偏差可能超 30% - Python 应用打点时若用默认
prometheus_client.Histogram桶（[.005, .01, .025, .05, .1, .25, .5, 1, 2.5, 5, 10]），对 API 延迟在 80–120ms 的服务，le="0.1"和le="0.25"之间跨度太大，关键分位无法锚定 - 桶边界必须覆盖你 SLO 承诺的 latency 上限（比如 SLO 是 “99% 请求 le="0.2"，否则
histogram_quantile(0.99, ...)计算结果不可信
Python 里怎么定义一组合理的 latency bucket？
不是靠经验猜，而是根据你服务的历史延迟分布 + SLO 目标反推。重点是让关键分位（如 P90、P95、P99）落在两个相邻桶之间，且上界桶必须 ≥ SLO 阈值。
- 先用
prometheus_client.Histogram临时开启详细打点（比如 20 个桶），跑 1–2 天，查rate(http_request_duration_seconds_bucket[1h])各le的累积占比 - 观察 P90/P95/P99 落在哪两个
le值之间 —— 比如 P99 在le="0.15"（87%）和le="0.2"（99.2%）之间，那就保留这两个桶，并在中间补一个le="0.18" - 最终桶列表要满足：最小桶 ≤ 典型延迟下限（如 10ms），最大桶 ≥ SLO 阈值（如 0.2），中间按对数或等差加密（推荐
[0.01, 0.02, 0.05, 0.1, 0.15, 0.2]） - 代码里显式传入
buckets参数：hist = Histogram('http_request_duration_seconds', 'HTTP request duration', buckets=[0.01, 0.02, 0.05, 0.1, 0.15, 0.2])
为什么 le="0.2" 桶的计数突然归零？
这不是数据丢了，是 Prometheus 的 _bucket 时间序列只保留最近采样点的值，如果某段时间内所有请求都 le="0.2" 的计数不会“自动继承”前一个桶的值，它就真的停在那儿不动了 —— 导致 histogram_quantile 计算时误判为“这部分请求不存在”。
- 根本原因是：Prometheus 不做桶间聚合，每个
le是独立时间序列，没有隐含的“上界包含关系” - 解决办法只有两个：确保你的应用一定有少量请求落到最上界桶（比如加一个兜底
le="+Inf"，它永远递增），或者在查询时用sum by (le) (rate(...))强制重聚合 - Python 打点时别删掉
le="+Inf"——prometheus_client默认自带，删了会导致histogram_quantile完全失效
Python 进程重启后 latency bucket 统计会断吗？
会断，但不是你想的“从零开始”，而是 _count 和 _sum 重置，但各 _bucket 的值是累计计数器（counter），重启后若没正确恢复初始值，Prometheus 会把突降识别为 counter 重置，触发错误的 rate 计算。
立即学习“Python免费学习笔记（深入）”；
- 默认
prometheus_client.Histogram使用进程内计数器，重启即丢 —— 所以必须配合持久化方案，比如用MultiProcessCollector+prometheus_multiproc_dir环境变量 - 如果你用 Gunicorn 或多进程部署，不配
MultiProcessCollector，各 worker 的_bucket计数互不感知，汇总后histogram_quantile结果完全失真 - 验证方法：查
http_request_duration_seconds_bucket{le="0.2"}在重启前后是否出现跳变（非单调递增），有就是没配对
