Prometheus “活学活用”，大牛总结了一套避坑指南( 四 ) _k8s

反直觉的 P95 统计
是常用的一个函数，比如经常把某个服务的 P95 响应时间来衡量服务质量。不过它到底是什么意思很难解释得清，特别是面向非技术的同学，会遇到很多“灵魂拷问” 。
我们常说 P95（P99,P90都可以）响应延迟是 100ms ，实际上是指对于收集到的所有响应延迟，有 5% 的请求大于 100ms ， 95% 的请求小于 100ms 。里面的函数接收的是 0-1 之间的小数，将这个小数乘以 100 就能很容易得到对应的百分位数，比如 0.95 就对应着 P95 ，而且还可以高于百分位数的精度，比如 0.9999 。
当你用画出响应时间的趋势图时，可能会被问：为什么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 查看