大家好，我是狼王，一个爱打球的程序员
面试广度，深度都很重要，多扩展知识面总是好的！今天就让我们来瞅瞅这个被号称是下一代监控的prometheus！
前言
我们知道zabbix在监控界占有不可撼动的地位，功能强大。但是对容器监控显得力不从心。为解决监控容器的问题，引入了prometheus技术。
接下来的文章打算围绕prometheus做一个系列的介绍，顺便也帮自己理清一下知识点。
Zabbix
在Prometheus之前市面已经出现了很多的监控系统，如Zabbix、Open-Falcon等。那么Prometheus和这些监控系统有啥异同呢？我们在这就介绍下Zabbix这个监控系统。
Zabbix是由Alexei Vladishev开源的分布式监控系统，支持多种采集方式和采集客户端，同时支持SNMP、IPMI、JMX、Telnet、SSH等多种协议，它将采集到的数据存放到数据库中，然后对其进行分析整理，如果符合告警规则，则触发相应的告警。
Zabbix核心组件主要是Agent和Server，其中Agent主要负责采集数据并通过主动或者被动的方式采集数据发送到Server/Proxy，除此之外，为了扩展监控项，Agent还支持执行自定义脚本。Server主要负责接收Agent发送的监控信息，并进行汇总存储，触发告警等。
为了便于快速高效的配置Zabbix监控项，Zabbix提供了模板机制，从而实现批量配置的目的。
Zabbix Server将收集的监控数据存储到Zabbix Database中。Zabbix Database支持常用的关系型数据库，例如MySQL、PostgreSQL、Oracle等，默认MySQL。Zabbix Web页面（PHP编写）负责数据查询。Zabbix由于使用了关系型数据存储时序数据，所以在监控大规模集群时常常在数据存储方面捉襟见肘。为此Zabbix 4.2版本后也开始支持时序数据存储，不过目前还不成熟。
Open-Falcon是小米开源的企业级监控工具，用Go语言开发而成，包括小米、滴滴、美团等在内的互联网公司都在使用它，是一款灵活、可扩展并且高性能的监控方案，在这里就不多做介绍了。
下表通过多维度展现了各自监控系统的优缺点：
Prometheus简介
Prometheus是一套开源的系统监控报警框架。它受启发于Google的Brogmon监控系统，由工作在SoundCloud的前google员工在2012年创建，作为社区开源项目进行开发，并于 2015年正式发布。
2016年，Prometheus正式加入Cloud Native Computing Foundation（CNCF）基金会的项目，成为受欢迎度仅次于Kubernetes 的项目。2017年底发布了基于全新存储层的2.0版本，能更好地与容器平台、云平台配合。
Prometheus作为新一代的云原生监控系统，目前已经有超过650 位贡献者参与到Prometheus的研发工作上，并且超过120 项的第三方集成。
Prometheus优缺点
1.提供多维度数据模型和灵活的查询方式，通过将监控指标关联多个tag，来将监控数据进行任意维度的组合，并且提供简单的PromQL查询方式，还提供HTTP查询接口，可以很方便地结合Grafana等GUI组件展示数据
2.在不依赖外部存储的情况下，支持服务器节点的本地存储，通过Prometheus自带的时序数据库，可以完成每秒千万级的数据存储；不仅如此，在保存大量历史数据的场景中，Prometheus可以对接第三方时序数据库和OpenTSDB等。
3.定义了开放指标数据标准，以基于HTTP的Pull方式采集时序数据，只有实现了Prometheus监控数据才可以被Prometheus采集、汇总、并支持Push方式向中间网关推送时序列数据，能更加灵活地应对多种监控场景
4.支持通过静态文件配置和动态发现机制发现监控对象，自动完成数据采集。Prometheus目前已经支持Kubernetes、etcd、Consul等多种服务发现机制
5.易于维护，可以通过二进制文件直接启动，并且提供了容器化部署镜像。
6.支持数据的分区采样和联邦部署，支持大规模集群监控
Prometheus的组件与架构
Prometheus 生态圈组件
Prometheus 的生态系统包括多个组件，大部分的组件都是用Go语言编写的，因此部署非常方便，而这些组件大部分都是可选的，主要组件介绍如下：
Prometheus Server
Prometheus Server是Prometheus组件中的核心部分，负责实现对监控数据的获取，存储以及查询。
Prometheus Server可以通过静态配置管理监控目标，也可以配合使用Service Discovery的方式动态管理监控目标，并从这些监控目标中获取数据。
其次Prometheus Server需要对采集到的监控数据进行存储，Prometheus Server本身就是一个时序数据库，将采集到的监控数据按照时间序列的方式存储在本地磁盘当中。
最后Prometheus Server对外提供了自定义的PromQL语言，实现对数据的查询以及分析。
Prometheus Server内置的Express Browser UI，通过这个UI可以直接通过PromQL实现数据的查询以及可视化。
推送网关（push gateway）
主要是实现接收由Client push过来的指标数据，在指定的时间间隔，由主程序来抓取。
由于Prometheus数据采集基于Pull模型进行设计，因此在网络环境的配置上必须要让Prometheus Server能够直接与Exporter进行通信。
当这种网络需求无法直接满足时，就可以利用PushGateway来进行中转。
可以通过PushGateway将内部网络的监控数据主动Push到Gateway当中。
而Prometheus Server则可以采用同样Pull的方式从PushGateway中获取到监控数据。
Exporter
主要用来采集数据，并通过HTTP服务的形式暴露给Prometheus Server，Prometheus Server通过访问该Exporter提供的接口，即可获取到需要采集的监控数据。
常见的Exporter有很多，例如node_exporter、mysqld_exporter、statsd_exporter、blackbox_exporter、haproxy_exporter等，支持如 HAProxy，StatsD，Graphite，Redis 此类的服务监控；
告警管理器（Alertmanager）
管理告警，主要是负责实现报警功能。
在Prometheus Server中支持基于PromQL创建告警规则，如果满足PromQL定义的规则，则会产生一条告警，而告警的后续处理流程则由AlertManager进行管理。
在AlertManager中我们可以与邮件，Slack等等内置的通知方式进行集成，也可以通过Webhook自定义告警处理方式。AlertManager即Prometheus体系中的告警处理中心。
Prometheus架构
上图是Prometheus整体架构图，左侧是各种符合Prometheus数据格式的exporter，除此之外为了支持推动数据类型的Agent，可以通过Pushgateway组件，将Push转化为Pull。
Prometheus甚至可以从其它的Prometheus获取数据，组建联邦集群。Prometheus的基本原理是通过HTTP周期性抓取被监控组件的状态，任意组件只要提供对应的HTTP接口并且符合Prometheus定义的数据格式，就可以接入Prometheus监控。
上侧是服务发现，Prometheus支持监控对象的自动发现机制，从而可以动态获取监控对象。
图片中间是Prometheus Server，Retrieval模块定时拉取数据，并通过Storage模块保存数据。
PromQL为Prometheus提供的查询语法，PromQL模块通过解析语法树，调用Storage模块查询接口获取监控数据。
图片右侧是告警和页面展现，Prometheus将告警推送到alertmanger，然后通过alertmanger对告警进行处理并执行相应动作。
数据展现除了Prometheus自带的WebUI，还可以通过Grafana等组件查询Prometheus监控数据。
Prometheus Server负载定时在目标上抓取metrics(指标)数据，每个抓取目标都需要暴露一个HTTP服务接口用于Prometheus定时抓取。这种调用被监控对象获取监控数据的方式被称为Pull(拉)。Pull方式体现了Prometheus独特的设计哲学与大多数采用Push(推)方式的监控不同
Pull方式的优势是能够自动进行上游监控和水平监控，配置更少，更容易扩展，更灵活，更容易实现高可用。简单来说就是Pull方式可以降低耦合。由于在推送系统中很容易出现因为向监控系统推送数据失败而导致被监控系统瘫痪的问题。所以通过Pull方式，被采集端无需感知监控系统的存在，完全独立于监控系统之外，这样数据的采集完全由监控系统控制
总结
至此，我们了解了一些监控系统的区别和优缺点，也分析了prometheus的组件和它的整体架构，下篇将会更加深入的了解Prometheus，可不要错过哦！
