Prometheus概述

1.什么是prometheus

Prometheus 是一个开源的服务监控系统和时序数据库，其提供了通用的数据模型和快捷数据采集、存储和查询接口。它的核心组件Prometheus server会定期从静态配置的监控目标或者基于服务发现自动配置的自标中进行拉取数据，当新拉取到的数据大于配置的内存缓存区时，数据就会持久化到存储设备当中。它可以监控主机，服务，容器，支持多种exporter采集数据，还支持pushgateway进行数据上报，Prometheus性能足够支撑上万台规模的集群。

2.Zabbix和Prometheus区别

简短来说就是区别在使用场景：

Zabbix：适合于需要集中管理、传统监控需求和广泛集成的场景。

Prometheus：适合于现代化的微服务架构、需要灵活的数据模型和强大查询能力的场景。

• 1.和Zabbix类似，Prometheus也是一个近年比较火的开源监控框架，和Zabbix不同之处在于Prometheus相对更灵活点，模块间比较解耦，比如告警模块、代理模块等等都可以选择性配置。服务端和客户端都是开箱即用，不需要进行安装。zabbix则是一套安装把所有东西都弄好，很庞大也很繁杂。
• 2.zabbix的客户端 agent 可以比较方便的通过脚本来读取机器内数据库、日志等文件来做上报。而 Prometheus 的上报客户端则分为不同语言的SDK和不同用途的 exporter 两种，比如如果你要监控机器状态、mysql性能等，有大量已经成熟的 exporter 来直接开箱使用，通过http 通信来对服务端提供信息上报（server去pull信息）；而如果你想要监控自己的业务状态，那么针对各种语言都有官方或其他人写好的 sdk供你使用，都比较方便，不需要先把数据存入数据库或日志再供zabbix-agent采集。
• 3.zabbix的客户端更多是只做上报的事情，push模式。而Prometheus则是客户端本地也会存储监控数据，服务端定时来拉取想要的数据。
• 4.界面来说zabbix比较陈旧，而prometheus比较新且非常简洁，简洁到只能算一个测试和配置平台。要想获得良好的监控体验，搭配Grafana还是二者的必走之路。

3.prometheus的特点

Prometheus官网上的自述是：“From metrics to insight.Power your metrics and alerting with a leading open-source monitoring solution.”

翻译过来就是：从指标到洞察力，Prometheus通过领先的开源监控解决方案为用户的指标和告警提供强大的支持。

主要有以下几个特点：

• 多维度数据模型，可以通过多个维度对数据建模，也可以通过多个维度对数据进行查询
• 灵活的查询语言，提供灵活的PromQL查询方式，还提供了HTTP查询接口，可以很方便地结合Grafana等组件展示数据
• 不依赖分布式存储，支持单节点的本地存储。通过Prometheus自带的时序数据库，可以完成每秒百万及的数据存储，如果需要存储大量历史数据，还可以对接第三方的时序数据库
• 以HTTP方式，通过pull模型拉取时间序列数据，并提供了开放的指标数据标准
• 也可以通过中间网关支持push模型 ；这种推，拉监控其实就是主动和被动监控，默认情况下是以pull(拉)的方式，也就是监控主机去找被监控主机将数据要过来，如果要实现push(推)的方式需要中间网关的支持，这只是与zabbix的叫法不同而已
• 通过服务发现或者静态配置来发现目标服务对象
• 支持多种多样的图表和界面展示，可以使用第三方的工具来展示内容，如Grafana

4.配置文件六个大配置段含义

• prometheus配置文件各个大配置段
  • scrape_configs 采集配置段 做采集器
  • alerting: Alertmanager信息段
  • remote_write 远程写入段
  • remote_read 远程查询段
  • rule_files 告警、预聚合配置文件段

5.功能组件

1、Prometheus Server

收集和储存时间序列数据

Prometheus server：服务核心组件，采用pull方式收集监控数据，通过http协议传输。并存储时间序列数据。Prometheus server 由三个部分组成：Retrival，Storage，PromQL。

Retrieval：负责在活跃的target 主机上抓取监控指标数据。
Storage：存储，主要是把采集到的数据存储到磁盘中。默认为15天（可修改）。
PromQL：是Prometheus提供的查询语言模块。

2、Job和Instance

当需要采集不同的监控指标(例如：主机、MySQL、Nginx)时，需要运行相应的监控采集程序（exporter），并且让Prometheus-Server知道Exporter实例的访问地址。

在Prometheus中，每一个暴露监控样本数据的HTTP服务称为一个实例（instance），它是被监控的具体目标。监控这些instances的任务叫做job。每个job负责一类任务，可以为一个job配置多个instance，job对自己的instance执行相同的动作。隶属于job的instance可以直接在配置文件中指定。也可以让job自动从consul、kuberntes中动态获取，这个过程就是服务发现。

3、Push Gateway

Pushgateway：类似一个中转站，Prometheus的server端只会使用pull方式拉取数据，但是某些节点因为某些原因只能使用push方式推送数据，那么它就是用来接收push而来的数据并暴露给Prometheus的server拉取的中转站。可以理解成目标主机可以上报短期任务的数据到Pushgateway，然后Prometheus server 统一从Pushgateway拉取数据。

4、Exporters

Exporter将监控数据采集的端点通过HTTP服务的形式暴露给Prometheus Server,Prometheus Server通过访问该Exporter提供的Endpoint端点,即可获取到需要采集的监控数据。

5、Alertmanager

Prometheus自身不具备告警能力,需要结合AlertManager实现监控指标告警。Alertmanager是一个独立的告警模块，从Prometheus server端接收到“告警通知”后，会进行去重、分组，并路由到相应的接收方，发出报警，常见的接收方式有：电子邮件、钉钉、企业微信等。

• 1.Prometheus Server 仅负责生成告警指示，具体的告警行为由另一个独立的应用程序AlertManager负责；
• 2.告警指示由 Prometheus Server基于用户提供的告警规则周期性计算生成。
• 3.Alertmanager 接收到Prometheus Server发来的告警指示后，基于用户定义的告警路由向告警接收人发送告警信息。

6、Service Discovery

Service Discovery：服务发现，用于动态发现待监控的Target，Prometheus支持多种服务发现机制：文件、DNS、Consul、Kubernetes等等。服务发现可通过第三方提供的接口，Prometheus查询到需要监控的Target列表，然后轮询这些Target 获取监控数据。该组件目前由Prometheus Server内建支持。