问题：
今天在统计机房请求量的时候，发现时间选择12 hours时还是正常的，但是选择24 hours时就有一些线条出不来，数据也有缺失，如下：
12 hours
24 hours
问了同事，说是数据量太多，导致线条失真，可以改大步长(step)，然后去百度了下step，没看懂...
先记录下现象，后面再研究吧
原因：
百度到的：
当查询到的样本数据量非常大时可以导致Grafana渲染图标时出现一些性能问题，通过Min Step可以控制Prometheus查询数据时的最小步长（Step），从而减少从Prometheus返回的数据量。
Resolution选项，则可以控制Grafana自身渲染的数据量。例如，如果Resolution的值为1/10，Grafana会将Prometeus返回的10个样本数据合并成一个点。因此Resolution越小可视化的精确性越高，反之，可视化的精度越低。
解析：
简单来说，这个step就是采样原始数据的间隔，也是展示图形两点之间的间隔时长，比如我的原始数据是15秒一个点，所以默认的min step=15，此时图形展示里的每一点就是我的原始数据值
当选择的时间跨度大时，数据点就会非常多，容易出现查询超时或者图形失真现象
此时就得加大步长，这样采集的数据就会减少，如下图，同样是展示60s内的数据，step=30时，只需要取两次原始数据，虽然会失去精度，但获得了性能的提升
此时点与点之间的间隔为30s
Resolution：
Resolution选项，则可以控制Grafana自身渲染的数据量。例如，如果Resolution的值为1/10，Grafana会将Prometeus返回的10个样本数据合并成一个点。因此Resolution越小可视化的精确性越高，反之，可视化的精度越低。
同时使用Min step 与 Resolution
当 Min step 时间 < Resolution 时间时，Resolution生效，step也会随着改变
当Min step 时间 > Resolution 时间时，step生效
综述
查询时间跨度大，数据量多，图形就较容易出现问题，如果优化集群性能很难的话，可以加大步长时间，丢失一些查询精度，来保证查询性能
- Resolution Grafana step Minresolution grafana step min resolution super-resolution high_resolution_clock cvpr_high-resolution high-resolution resolution temporary failure ubuntu super-resolution convolutional resolution real-time super-resolution scale-arbitrary resolution cvpr_spatial-frequency super-resolution resolution