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

“`bash
rate([1h])
rate(_sum[1h]){="0.0.0.0:8890", job=""}
1.
“`
如果大致估算本地磁盘大小，可以通过以下公式：
保留时间(ds)和样本大小()不变的情况下，如果想减少本地磁盘的容量需求，只能通过减少每秒获取样本数()的方式。
查看当前每秒获取的样本数：
有两种手段，一是减少时间序列的数量，二是增加采集样本的时间间隔。考虑到会对时间序列进行压缩，因此减少时间序列的数量效果更明显。
举例说明：
以上磁盘容量并没有把 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 的时间区间内有数据缺失，他会基于趋势进行推测，比如：

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