prometheus调研注意事项

云平台现有参数：每30秒抓取一次数据。数据留存10天。

1.几点原则

监控是基础设施，目的是为了解决问题，不要只朝着大而全去做，尤其是不必要的指标采集，浪费人力和存储资源。
需要处理的告警才发出来，发出来的告警必须得到处理。
简单的架构就是最好的架构，业务系统都挂了，监控也不能挂。

2.Prometheus 的局限

Prometheus 是基于 Metric 的监控，不适用于日志（Logs）、事件(Event)、调用链(Tracing)。
Prometheus 默认是 Pull 模型，合理规划你的网络。
监控系统一般情况下可用性大于一致性，容忍部分副本数据丢失，保证查询请求成功。

3.合理选择黄金指标
采集的指标有很多，我们应该关注哪些？Google 在“Sre Handbook”中提出了“四个黄金信号”：延迟、流量、错误数、饱和度。
在线服务：如 Web 服务、数据库等，一般关心请求速率，延迟和错误率
离线服务：如日志处理、消息队列等，一般关注队列数量、进行中的数量，处理速度以及发生的错误

4.Prometheus 大内存问题
Prometheus 的内存消耗主要是因为每隔2小时做一个 Block 数据落盘，落盘之前所有数据都在内存里面，因此和采集量有关。
加载历史数据时，是从磁盘到内存的，查询范围越大，内存越大。

5.Prometheus 容量规划
Prometheus中存储的每一个样本大概占用1-2字节大小（1.7Byte）
磁盘大小 = 保留时间 * 每次获取样本数 * 样本大小

6.慢查询问题
范围查询时，大的时间范围 step 值却很小，导致查询到的数量过大。

7.rate计算逻辑
建议将 Rate 计算的范围向量的时间至少设为抓取间隔的四倍。这将确保即使抓取速度缓慢，且发生了一次抓取故障，您也始终可以使用两个样本。
此类问题在实践中经常出现，因此保持这种弹性非常重要。例如，对于1分钟的抓取间隔，您可以使用4分钟的 Rate 计算，但是通常将其四舍五入为5分钟。

8.是否可以实现秒级数据抓取？
官网中得知可以实现毫秒级的抓取，但是github中有存在毫秒级抓取配置后的issue。所以需要在云平台实际环境中进行配置测试才能得出结论。
另外，抓取频率变高后需要考虑内存和磁盘的使用量增加。

9.是否可以直接直接TSDB时序数据库？
不可以，prometheus未开放相关接口，但是prometheus提供的查询接口可以满足查询指标的需求。

10.是否可以将数据存入到MySQL？
不建议。MySQL与时序数据库相比，可保存数据条数有限（数据多了影响使用性能）。一般prometheus的查询是把metric+label做关键字的，而且是很宽泛，
完全用户自定义的字符，因此没办法使用常规的sql数据库，prometheus的存储层使用了全文检索中的倒排索引概念，将每个时间序列视为一个小文档。
而metric和label对应的是文档中的单词。

11.prometheus是否可以存储一个季度的数据？
可以，prometheus默认留存15天数据，云平台配置为10天。若改为留存90天，需考虑存储容量。若本地存储容器有限，可使用远程存储，如influxdb。

12.是否可以获取cpu平均负载？
不能，平均负载计算的CPU运行和等待的任务数。prometheus没有采集该指标。只采集了CPU的使用时间的指标。