关于prometheus设计的一些思考

其实设计一套完整的监控系统是挺复杂的，既要考虑的通用性，也要考虑的对各种指标和监控对象的特殊性，业内也并没有规范可言，还有考虑的数据的存储和持久化。prometheus的设计初衷就就是一个通用监控系统，它并没有设计集群，类似HDFS一套东西去存储数据，它的设计初衷就没有想过存储大量的持久的监控数据，如果你想做报表的话，它可能不适合，它更适合作为一个通用的实时的监控系统。下面针对它的设计理念的一些思考：

它是什么

它首先是一个监控系统，采集和存储监控指标，支持指标的查询和指标告警，当然还有自己的一个dashboard。

它的侧重点

它的重点是操作系统和云环境的监控
它不不适合日志和时间采集存储，请求的跟踪，持久的存储，没有用户和鉴权，不能够自动水平伸缩。

为什么不做多租户

这个问题，想必大家都很关心，这个通用的监控系统，为啥没有多租户的设计呢！因为做多租户就要TSL、鉴权之类的东西，这样会导致监控的exporter将会很复杂，并且多租户的隔离完全可以在系统之外用户自己去维护。

Label 对比 hierarchy

这是设计理念的对比，label的优势不言而喻，在kubernetes的资源对象的关联都是通过label去完成，它相比简单层级结构要更加的灵活、高效、多维度。

promsql 对比 sql

prometheus为啥不设计一套兼容标准sql的CURD呢？应为要考虑到标准sql的解析等，这样会降低性能，并且标准sql写起来很麻烦，如果你用过promsql就会看出它的优势，能够更好的做指标计算，prometheus认为监控数据只读就可以了，所以promsql只支持读。

pull 对比 push

这个是从架构上面思考，pull是自己去拉，push是推送。这个设计对比和之前rabbitmq和kafka的设计形成对照。到底应该推还是拉。prometheus选择拉，拉的优势是能够自动的上游监控、水平监控、更加灵活、更容易实现高可用、更少的配置、更容易扩展。展开来说就是拉的方式，降低耦合，在推送的系统中很容易出现因为向监控系统推送数据失败而导致系统瘫痪的问题，通过pull，独立于被监控系统之外，这样数据的采集存储能够更加可控，被采集端无须感知监控系统的存在。

无集群

我并不否认集群的好处，能够更大规模的采集和存储数据。但这这样设计会将整个系统复杂化，尤其告警变的复杂，可能导致数据的一致性性问题，prometheus专注实时监控。

relabel

relabel是为了系统兼容而设计的，在环境中监控的对象不同，针对不同的监控对象target，要能够改变监控查询的方式。数据存储使用float64，这样在保证精度的情况下，或得较好压缩。

exporter

这个一个设计模式的问题，一个exporter是功能大而全，还是简单独立好呢？prometheus坚持的是，第一单一职责划分架构简单；第二是避免SPOF（Single Point Of Failure）；第三是操作瓶颈，一个大而全的采集器可能要处理更大的数据；第四，单一功能的exporter可以支持不同的语言编写，这样系统变的更加通用，只要支持prometheus风格的metric都可以被监控。