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

top10 高基数的
高基数的 label
找到最大的或 job
top10的数量：按名字分
top10的数量：按 job 名字分
重启慢与热加载
重启的时候需要把 Wal 中的内容 Load 到内存里，保留时间越久、Wal 文件越大，重启的实际越长，这个是的机制，没得办法，因此能的就不要重启，重启一定会导致短时间的不可用，而这个时候高可用就很重要了。

文章插图
也曾经对启动时间做过优化，在 2.6 版本中对于Wal的 Load 速度就做过速度的优化，希望重启的时间不超过 1 分钟。
1分钟：
提供了热加载能力，不过需要开启web.-配置，更改完配置后， curl 下接口即可。- 中更改了配置会默认触发，如果你没有使用，又希望可以监听配置变化来服务，可以试下这个简单的脚本。
使用时和挂载同一个，传入如下参数即可：
你的应用需要暴露多少指标
当你开发自己的服务的时候，你可能会把一些数据暴露出去，比如特定请求数、数等，指标数量多少合适呢？
虽然指标数量和你的应用规模相关，但也有一些建议(Brian ) ，比如简单的服务如缓存等，类似，大约 120 个指标，本身暴露了 700 左右的指标，如果你的应用很大，也尽量不要超过 10000 个指标，需要合理控制你的 Label 。
建议(Brian )：
node- 的问题
命名规范：
一些指标名字的变化：
如果你之前用的旧版本，在绘制的时候指标名称就会有差别，解决方法有两种：
指标转换器：
kube-state- 的问题
除了文章中提到的作用， kube-state-还有一个很重要的使用场景，就是和指标组合，原始的中只有 pod 信息，不知道属于哪个或者 sts ，但是和kube-state- 中的做 join 查询之后就可以显示出来， kube-state-的元数据指标，在扩展的 label 中起到了很多作用， - 的很多rule 就使用了 kube-state- 做组合查询。
容器监控实践—kube-state-：
kube-state- 中也可以展示 pod 的 label 信息，可以在拿到数据后更方便地做 group by ，如按照 pod 的运行环境分类。但是 kube-state- 不暴露 pod 的，原因是下面会提到的高基数问题，即的内容太多，不适合作为指标暴露。
与 gs
发生在采集之前， gs 发生在采集之后，合理搭配可以满足很多场景的配置。
如：
的预测能力
场景1：你的磁盘剩余空间一直在减少，并且降低的速度比较均匀，你希望知道大概多久之后达到阈值，并希望在某一个时刻报警出来。
场景2：你的 Pod 内存使用率一直升高，你希望知道大概多久之后会到达 Limit 值，并在一定时刻报警出来，在被杀掉之前上去排查。
的 Deriv 和方法可以满足这类需求，提供了基础的预测能力，基于当前的变化速度，推测一段时间后的值。
以为例，最近一小时的 free 值一直在下降。
deriv函数可以显示指标在一段时间的变化速度:
方法是预测基于这种速度，最后可以达到的值: