万字长文，Prometheus 如何做到“活学活用”，大牛总结的避坑指南( 四 ) _集群

当你用画出响应时间的趋势图时，可能会被问：为什么P95大于或小于我的平均值？
正如中位数可能比平均数大也可能比平均数小，P99 比平均值小也是完全有可能的。通常情况下 P99 几乎总是比平均值要大的，但是如果数据分布比较极端，最大的 1% 可能大得离谱从而拉高了平均值。一种可能的例子：
服务 X 由顺序的 A，B 两个步骤完成，其中 X 的 P99 耗时 100Ms，A 过程 P99 耗时 50Ms，那么推测 B 过程的 P99 耗时情况是？
直觉上来看，因为有 X=A+B，所以答案可能是 50Ms，或者至少应该要小于 50Ms 。实际上 B 是可以大于 50Ms 的，只要 A 和 B 最大的 1% 不恰好遇到，B 完全可以有很大的 P99：

文章插图

文章插图
所以我们从题目唯一能确定的只有 B 的 P99 应该不能超过 100ms，A 的 P99 耗时 50Ms 这个条件其实没啥用。
类似的疑问很多，因此对于函数，可能会产生反直觉的一些结果，最好的处理办法是不断试验调整你的的值，保证更多的请求时间落在更细致的区间内，这样的请求时间才有统计意义。
慢查询问题
提供了自定义的作为查询语句，在 Graph 上调试的时候，会告诉你这条 Sql 的返回时间，如果太慢你就要注意了，可能是你的用法出现了问题。
慢查询：
评估的整体响应时间，可以用这个默认指标:
一般情况下响应过慢都是使用不当导致，或者指标规划有问题，如：
step:
部分数据：
高基数问题
高基数是数据库避不开的一个话题，对于 Mysql 这种 DB 来讲，基数是指特定列或字段中包含的唯一值的数量。基数越低，列中重复的元素越多。对于时序数据库而言，就是 tags、label 这种标签值的数量多少。
比如中如果有一个指标 {="get",path="/abc",="1.1.1.1"}表示访问量，表示请求方法，是客户端 IP，的枚举值是有限的，但却是无限的，加上其他 label 的排列组合就无穷大了，也没有任何关联特征，因此这种高基数不适合作为的 label，真要的提取，应该用日志的方式，而不是监控。
时序数据库会为这些 Label 建立索引，以提高查询性能，以便您可以快速找到与所有指定标签匹配的值。如果值的数量过多，索引是没有意义的，尤其是做 P95 等计算的时候，要扫描大量数据。
官方文档中对于Label 的建议
如何查看当前的Label 分布情况呢，可以使用提供的Tsdb工具。可以使用命令行查看，也可以在 2.16 版本以上的Graph 查看

文章插图

文章插图
top10 高基数的

文章插图
高基数的 label

文章插图
找到最大的或 job
top10的数量：按名字分

文章插图
top10的数量：按 job 名字分

文章插图
重启慢与热加载
重启的时候需要把 Wal 中的内容 Load 到内存里，保留时间越久、Wal 文件越大，重启的实际越长，这个是的机制，没得办法，因此能的就不要重启，重启一定会导致短时间的不可用，而这个时候高可用就很重要了。