作者介绍：
王坤，年加入去哪儿网，高级系统运维工程师、去哪儿云原生SIG、基础设施SIG成员，目前主要负责Kubernetes、容器指标监控等系统的运维和云原生相关工作。
一、概述
在云原生的体系下，面对高弹性、拆分微服务以及应用动态生命周期等特点，传统监控体系如cacti、nagios、Zabbix等已经逐渐丧失了优势，难以适用和支撑，对应的新一代云原生监控体系应运而生，Prometheus为核心的监控系统已成为云原生监控领域的事实标准。之前公司有文章介绍过，Qunar内部的一站式监控平台，后端存储是基于Graphite+Whisper做的二次开发，前端控制面是基于Grafana做的二次开发。而Grafana是支持多数据源的，其中就包含Prometheus数据源。所以在容器化落地期间最初计划采用的监控方案也是Prometheus，其本身是个AllinOne的系统，拥有强大的PromQL，集采集、处理、存储、查询、rule检测于一身，非常易于部署和运维。但每个系统都不是完全能够契合使用需求的，Prometheus也一样不是完美的。该文章将以Qunar容器监控实践过程和经验为基础，讲述我们监控体系构建、遇到的挑战和相应对策，以及对VictoriaMetrics的简单介绍与Qunar在过渡至VictoriaMetrics后的效果。二、使用Prometheus的相关问题Prometheus是个AllinOne的系统，集采集、处理、存储、查询、rule检测于一身，这样做易于部署和运维，但也意味着丧失了拆分组件所具备的独立性和可扩展性。实践测试摘录的几个问题如下：
数据采集量大存在瓶颈，目前Qunar单集群容器指标量级每分钟将近1亿；
不支持水平扩容；
只支持AllinOne单机部署，不支持集群拆分部署；
其本身不适用于作为长期数据存储；
占用资源高；
查询效率低，Prometheus加载数据是从磁盘到内存的，不合理查询或大范围查询都会加剧内存占用问题，范围较大的数据查询尤其明显，甚至触发OOM。
如上例举的几项问题点，其实对于大多数公司来讲都不是问题，因为没有那么大的数据量和需求。但是对于我们或一些数据规模较大的公司来讲，每一项都在对我们的使用环境说No...我们也对这些问题尝试了以下解决方案：使用分片，对Prometheus进行按服务维度分片进行分别采集存储。默认告警策略条件是针对所有Targets的，分片后因每实例处理的Targets不同，数据不统一，告警规则也需要随着拆分修改。使用HA，也就是跑两个Prometheus采集同样的数据，外层通过负载均衡器进行代理对其实行高可用使用Promscale作为其远程存储，保留长期数据注：Promscale是TimescaleDB近两年发布的一个基于TimescaleDB之上的Prometheus长期存储。但做了这些处理后，其实还是留存问题，也有局限性和较大隐患：例如2个实例，1、2同时运行采集相同数据，他们之间是各自采集各自的没有数据同步机制，如果某台宕机一段时间恢复后，数据就是缺失的，那么负载均衡器轮训到宕机的这台数据就会有问题，这意味着使用类似Nginx负载均衡是不能够满足使用的。各集群2w+Targets，拆分Prometheus后可以提升性能，但依然有限，对资源占用问题并未改善。远程存储Promscale资源占用极大，40ksamples/s，一天0亿，就用掉了将近16cores/40G内存/GB磁盘。而我们单集群1.50Milsamples/s，一天就产生亿左右，而且需求数据双副本，这样的资源需求下如果上了线，仅磁盘单集群1天就要耗费12TB左右，这样的代价我们是表示有些抗拒的。。三、接触VictoriaMetrics在为调整后面临到的这些难点，进行进一步调研，结合Qunar自身经验和需求参考各类相关文档以及各大厂商的架构分享时，我们注意到了VictoriaMetrics，并在其