前言
zabbix是传统的监控系统，出现比云原生早，使用的是SQL关系型数据库；而Prometheus基于谷歌的borgemon使用go语言开发，使用TSDB数据库，所以支持云原生。zabbix最新发布的6.0版本，知道自己处于生死存亡时刻，也支持了Prometheus使用的TSDB数据库。
一、Prometheus 概述
1.1 什么是Prometheus
Prometheus 是一个开源的服务监控系统和时序数据库，其提供了通用的数据模型和快捷数据采集、存储和查询接口。它的核心组件Prometheus server会定期从静态配置的监控目标或者基于服务发现自动配置的自标中进行拉取数据，当新拉取到的数据大于配置的内存缓存区时，数据就会持久化到存储设备当中。
每个被监控的主机都可以通过专用的exporter 程序提供输出监控数据的接口，它会在目标处收集监控数据，并暴露出一个HTTP接口供Prometheus server查询，Prometheus通过基于HTTP的pull的方式来周期性的采集数据。
任何被监控的目标都需要事先纳入到监控系统中才能进行时序数据采集、存储、告警和展示，监控目标可以通过配置信息以静态形式指定，也可以让Prometheus通过服务发现的机制进行动态管理。
Prometheus 能够直接把API Server作为服务发现系统使用，进而动态发现和监控集群中的所有可被监控的对象。
Prometheus 官网地址：https://prometheus.io
Prometheus github 地址：https://github.com/prometheus
1.2 prometheus 的特点：
多维数据模型：由度量名称和键值对标识的时间序列数据
时序数据，是在一段时间内通过重复测量（measurement）而获得的观测值的集合；将这些观测值绘制于图形之上，它会有一个数据轴和一个时间轴；
服务器指标数据、应用程序性能监控数据、网络数据等也都是时序数据；
内置时间序列（pime series）数据库：Prometheus；外置的远端存储通常会用：InfluxDB、openTsDB等
promQL一种灵活的查询语言，可以利用多维数据完成复杂查询
基于HTTP的pull（拉取）方式采集时间序列数据
同时支持PushGateway组件收集数据
通过静态配置或服务发现发现目标
支持作为数据源接入Grafana
1.3 Prometheus的生态组件
Prometheus 负责时序型指标数据的采集及存储，但数据的分析、聚合及直观展示以及告警等功能并非由Prometheus Server所负责。
（1）Prometheus server：服务核心组件，采用pull方式收集监控数据，通过http协议传输。并存储时间序列数据。Prometheus server 由三个部分组成：Retrival，Storage，PromQL
Retrieval：负责在活跃的target 主机上抓取监控指标数据。
Storage：存储，主要是把采集到的数据存储到磁盘中。默认为15天（可修改）。
PromQL：是Prometheus提供的查询语言模块。
（2）client Library：客户端库，目的在于为那些期望原生提供Instrumentation功能的应用程序提供便捷的开发途径，用于基于应用程序内建的测量系统。
（3）Exporters：指标暴露器，负责收集不支持内建Instrumentation的应用程序或服务的性能指标数据，并通过HTTP接口供Prometheus Server获取。换句话说，Exporter 负责从目标应用程序上采集和聚合原始格式的数据，并转换或聚合为Prometheus格式的指标向外暴露。
常用的Exporters：
Node-Exporter：用于收集服务器节点（例如k8s）的物理指标状态数据，如平均负载、CPU、内存、磁盘、网络等资源信息的指标数据，需要部署到所有运算节点。指标详细介绍：https://github.com/prometheus/node_exporter
mysqld-exporter/nginx-exporter
Kube-state-Metrics：为prometheus 采集k8s资源数据的exporter，通过监听APIServer 收集kubernetes集群内资源对象的状态指标数据，例如pod、deployment、service 等等。同时它也提供自己的数据，主要是资源采集个数和采集发生的异常次数统计。
需要注意的是kube-state-metrics 只是简单的提供一个metrics 数据，并不会存储这些指标数据，所以可以使用prometheus来抓取这些数据然后存储，主要关注的是业务相关的一些元数据，比如Deployment、Pod、副本状态等；调度了多少个replicas？现在可用的有几个？多少个Pod是running/stopped/terminated 状态？Pod 重启了多少次？有多少job在运行中。
cAdvisor：用来监控容器内部使用资源的信息，比如CPU、内存、网络I/0、磁盘I/0。
blackbox-exporter：监控业务容器存活性。
（4）Service Discovery：服务发现，用于动态发现待监控的Target，Prometheus支持多种服务发现机制：文件、DNS、Consul、Kubernetes等等。
服务发现可通过第三方提供的接口，Prometheus查询到需要监控的Target列表，然后轮询这些Target 获取监控数据。该组件目前由Prometheus Server内建支持
（5）Alertmanager：是一个独立的告警模块，从Prometheus server端接收到“告警通知”后，会进行去重、分组，并路由到相应的接收方，发出报警，常见的接收方式有：电子邮件、钉钉、企业微信等。
Prometheus Server 仅负责生成告警指示，具体的告警行为由另一个独立的应用程序AlertManager负责；告警指示由 Prometheus Server基于用户提供的告警规则周期性计算生成，Alertmanager 接收到Prometheus Server发来的告警指示后，基于用户定义的告警路由向告警接收人发送告警信息。
（6）Pushgateway：类似一个中转站，Prometheus的server端只会使用pull方式拉取数据，但是某些节点因为某些原因只能使用push方式推送数据，那么它就是用来接收push而来的数据并暴露给Prometheus的server拉取的中转站。可以理解成目标主机可以上报短期任务的数据到Pushgateway，然后Prometheus server 统一从Pushgateway拉取数据。
（7）Grafana：是一个跨平台的开源的度量分析和可视化工具，可以将采集的数据可视化的展示，并及时通知给告警接收方。其官方库中具有丰富的仪表盘插件。
1.4 Prometheus的工作模式：
Prometheus Server 基于服务发现（Service Discovery）机制或静态配置获取要监视的目标（Target），并通过每个目标上的指标exporter来采集（Scrape）指标数据；
Prometheus Server 内置了一个基于文件的时间序列存储来持久存储指标数据，用户可使用PromQL接口来检索数据，也能够按需将告警需求发往A1ertmanager完成告警内容发送；
一些短期运行的作业的生命周期过短，难以有效地将必要的指标数据供给到Server端，它们一般会采用推送（Push）方式输出指标数据，Prometheus借助于Pushgateway 接收这些推送的数据，进而由server端进行抓取
1.5 Prometheus的工作流程
（1）Prometheus以prometheus Server 为核心，用于收集和存储时间序列数据。Prometheus Server从监控目标中通过pull方式拉取指标数据，或通过pushgateway 把采集的数据拉取到Prometheus server中。
（2）Prometheus server 把采集到的监控指标数据通过TSDB存储到本地HDD/ssD中。
（3）Prometheus 采集的监控指标数据按时间序列存储，通过配置报警规则，把触发的报警发送到Alertmanager。
（4）Alertmanager 通过配置报警接收方，发送报警到邮件、钉钉或者企业微信等。
（5）Prometheus 自带的Web UI 界面提供PromQL 查询语言，可查询监控数据。
（6）Grafana 可接入Prometheus 数据源，把监控数据以图形化形式展示出。
1.6 Prometheus的局限性
Prometheus是一款指际监控系统，不适合存储事件及日志等；它更多地展示的是趋势性的监控，而非精准数据；
Prometheus认为只有最近的监控数据才有查询的需要，其本地存储的设计初衷只是保存短期（例如一个月）数据，因而不支持针对大量的历史数据进行存储；若需要存储长期的历史数据，建议基于远端存储机制将数据保存于InfluxDB或openTsDB等系统中；
Prometheus的集群机制成熟度不高，可基于Thanos（和灭霸是一个单词）实现Prometheus集群的高可用及联邦集群。
mysql、nginx、k8s等使用多个不同的Prometheus收集，形成联邦集群
