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

“`bash
rate([1h])
rate(_sum[1h]){="0.0.0.0:8890", job=""}
1.
“`
如果大致估算本地磁盘大小，可以通过以下公式：
保留时间(ds)和样本大小()不变的情况下，如果想减少本地磁盘的容量需求，只能通过减少每秒获取样本数()的方式。
查看当前每秒获取的样本数：
有两种手段，一是减少时间序列的数量，二是增加采集样本的时间间隔。考虑到会对时间序列进行压缩，因此减少时间序列的数量效果更明显。
举例说明：
【Prometheus “活学活用”，大牛总结了一套避坑指南】以上磁盘容量并没有把 wal 文件算进去， wal 文件(Raw Data)在官方文档中说明至少会保存3个 Write-Ahead Log Files ，每一个最大为128M(实际运行发现数量会更多) 。
因为我们使用了的方案，所以本地磁盘只保留2H 热数据。Wal 每2小时生成一份Block文件， Block文件每2小时上传对象存储，本地磁盘基本没有压力。
关于存储机制，可以看《容器监控实践—存储机制》。
容器监控实践—存储机制：
对的性能影响
如果你的使用了做服务发现，请求一般会经过集群的，随着规模的变大，需要评估下对性能的影响，尤其是Proxy失败的时候，会导致CPU 升高。当然了，如果单K8S集群规模太大，一般都是拆分集群，不过随时监测下的进程变化还是有必要的。
在监控、、Kube-Proxy 的时，我们一开始选择从Proxy 到节点的对应端口，统一设置比较方便，但后来还是改为了直接拉取节点，仅做服务发现。
Rate 的计算逻辑
中的类型主要是为了 Rate 而存在的，即计算速率，单纯的计数意义不大，因为一旦重置，总计数就没有意义了。
Rate 会自动处理重置的问题，一般都是一直变大的，例如一个启动，然后崩溃了。本来以每秒大约10的速率递增，但仅运行了半个小时，则速率（ [1h]）将返回大约每秒5的结果。另外，的任何减少也会被视为重置。例如，如果时间序列的值为[5,10,4,6] ，则将其视为[5,10,14,16] 。
Rate 值很少是精确的。由于针对不同目标的抓取发生在不同的时间，因此随着时间的流逝会发生抖动，计算时很少会与抓取时间完美匹配，并且抓取有可能失败。面对这样的挑战， Rate 的设计必须是健壮的。
Rate 并非想要捕获每个增量，因为有时候增量会丢失，例如实例在抓取间隔中挂掉。如果的变化速度很慢，例如每小时仅增加几次，则可能会导致【假象】。比如出现一个时间序列，值为100 ， Rate 就不知道这些增量是现在的值，还是目标已经运行了好几年并且才刚刚开始返回。
建议将 Rate 计算的范围向量的时间至少设为抓取间隔的四倍。这将确保即使抓取速度缓慢，且发生了一次抓取故障，您也始终可以使用两个样本。此类问题在实践中经常出现，因此保持这种弹性非常重要。例如，对于1分钟的抓取间隔，您可以使用4分钟的 Rate 计算，但是通常将其四舍五入为5分钟。
如果 Rate 的时间区间内有数据缺失，他会基于趋势进行推测，比如：