Prometheus的优缺点
-
(注:发表于https://zhuanlan.zhihu.com/p/544050725)在自己构建监控系统时,很多公司会选用Prometheus作为存储方案,那么作为数据存储和提供基本处理(OLAP)能力的Prometheus有什么优缺点呢?它是否适合你所需要的场景呢?希望这篇文章能简单的回答上述问题。
源自Google Borgmon的Prometheus在开源解决方案中已经是事实上的监控数据存储方案标准了;能成为标准,自然有它的很多有点,比如:
- 简单易用,可以快速构建一个简单的数据存储方案
- 灵活的数据模型,通过标签可以帮助用户实现业务上的多维数据组织能力,且该数据存储模型也成为了事实上的存储标准
- 灵活的数据注入方式,自带支持push和pull的数据注入模型
- 灵活的数据处理,自带的PromQL也基本成为监控数据OLAP的标准
- 自带集成的告警处理能力,虽然简单,但能满足大多数用户一站式的告警处理能力
- 超多的集成方案;由于成为了事实上的标准,基于Prometheus的各种数据注入插件层出不穷
这些优点都决定了Prometheus成为了大多数用户构建自己监控方案时的首选存储方案。但是Prometheus也存在一些明显的不足之处,限制了它的使用场景:
- 仅存指标数据(数值型数据):监控往往要采集多种多样的结构化的、半结构化甚至无结构化的数据,这意味着在构建监控方案时,Prometheus只能提供部分存储能力
- 扩展性较差:在满足小场景或简单场景时,Prometheus是个相当不错的选择,但在复杂场景和较大场景时则会面临较大的扩展性问题;从某个角度来说Prometheus适合构建toy性质的监控系统用来满足临时监控需求或作为原型系统的验证系统
- 数据存储的管理:监控系统往往需要考虑对数据存留时间的考虑,且在不同场景下存留时间会出现不同的需求(比如一些测试数据可能存留24小时即可,而一些产品数据则需要存留一个月甚至更久),Prometheus在设计上并没有针对这些需求做特殊的考虑和设计
- 数据模型过于简单:虽然基于标签的数据管理模型在绝大多数情况下为业务带来了多维组织和查询的便利,但Prometheus的设计过于简单,往往无法满足一些最基本的需求,比如对一个docker 或进程重启后,如何进行时序数据的关联
- 告警处理能力较弱:虽然集成了AlertManager能满足绝大多数的告警需求,但它的告警处理能力只能算一个相当初级的解决方案,对一些复杂场景的联合告警等特殊需求则无能为力。而且它缺少一些关键的状态维护能力,导致它无法支持一些状态事件(比如机器负载过高是一个持续性的状态事件而非一个一次性的告警事件)
由于Prometheus的这些弱点或缺陷,市面上出现了很多基于它(如Thanos)或用于替代它(如Victoria Metrics)的解决方案。但这些解决方案只是部分解决了上述问题,而且它们自身也引入了系统的复杂度和维护成本,反而增加了普通客户的使用难度。
对大多数普通客户而言,如果使用场景简单,需求简单则不如坚持使用基本的Prometheus及相关组件;或者在复杂场景下选择一些集成度更高,更满足场景需求的现成解决方案(如择维士的面向场景的监控解决微方案,后面会陆续写一些择维士方案特点的文章方便用户了解和选择)。
-
@hades mark