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

在公众号后端架构师后台回复“offer”，获取算法面试题和答案。
也曾经对启动时间做过优化，在 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函数可以显示指标在一段时间的变化速度:

文章插图
方法是预测基于这种速度，最后可以达到的值:

文章插图
你可以基于设置合理的报警规则，如小于 10 时报警:
与 deriv 的关系: 含义上约等于如下表达式，不过稍微准确一些。
如果你要基于做模型预测，可以参考下- 。
-：
的上层封装
部署之后很少会改动，尤其是做了服务发现，就不需要频繁新增。但报警的配置是很频繁的，如修改阈值、修改报警人等。拥有丰富的报警能力如分组、抑制等，但如果你要想把他给业务部门使用，就要做一层封装了，也就是报警配置台。用户喜欢表单操作，而非晦涩的 yaml，同时他们也并不愿意去理解。而且大多数公司内已经有现成的监控平台，也只有一份短信或邮件网关，所以最好能使用直接集成。