方案
方案分为两大模块：采集计算模块和存储查询模块。采集计算采用prometheus和thanos的架构，具有更好的时效性。不需要对外提供服务，查询压力小且稳定，具备较好的扩展性。存储查询采用VictoriaMetrics，保证高压缩率的存储和高效的查询性能，不需要依赖对象存储，易扩展。另外，为了进一步提高prometheus和thanos的扩展性，提高运维效率，还引入了配置管理方法，通过配置管理prometheus和thanos集群。
存储查询模块
采用集群版本的VictoriaMetrics持久化数据，提供数据查询服务。
- 无状态部署vminsert，为采集计算模块提供数据写入接口。
- 有状态部署vmstorage，独占服务器，发挥最大性能。
- 无状态部署vmselect，对外提供数据查询服务。
采集计算模块
prometheus
- 采集数据，执行部分预计算，即单序列预计算、采集维度范围内的聚合计算。
- 优化内存，取消过期数据保存到磁盘（即禁止生成block），内存只保留满足预计算时间范围。
- 使用配置管理prometheus的hashmod功能，按照指定维度分配采集任务，提高扩展性。
thanos
- sidecar用于监听prometheus，实现配置管理，自动为prometheus分配采集和预计算；提供grpc接口。需与prometheus一起部署。
- Rule用于实现采集维度以上的预计算并将结果保存在内存，提供grpc接口。实现配置管理，方便集群化，在集群内可按照group粒度分配任务。
- Querier通过Sidecar和Rule的grpc接口，汇聚数据并执行PromQL语法。无状态部署。
配置管理
通过SDK的方式集成在Sidecar和Rule组件上，通过template语法自动生成prometheus和Rule的采集配置和预计算配置，一份统一的配置可以为prometheus和Rule集群分配任务，简化运维，提高扩展性。
- 为Sidecar和Rule组件定义标签，结合机器的环境变量和template语法生成。
- prometheus采集和预计算配置管理，Sidecar利用生成的标签信息和template语法生成最终的配置，并通知prometheus重载。
- Rule预计算配置管理，原理同上。
