目录
一、 prometheus介绍
二、Prom组件
三、Prom的架构
3.1 框架图简单说明
3.2 prometheus服务器
3.2.1 时序数据库节点安装
3.2.2 服务发现
3.3 prom数据采集、报警、展示功能
3.3.1 数据采集
3.3.2 报警功能
3.3.3 数据展示
四、Prometheus_工作流程
附录一、Prometheus核心组件
1.Prometheus服务器
2.Client Library
3.Exporter
4.Pushgateway
5.Alertmanager
前面花了十多篇介绍了k8s，那么大名鼎鼎的配合k8s的监控工具prometheus（简称prom）肯定是要用的。所以让我们开始prometheus之旅吧
推荐书籍《Prometheus监控技术与实践》我已经上专到csdn中可以点击下载，感觉比较适合入门，挻不错的
一、 prometheus介绍
Prometheus（普罗米修斯，有时简称Prom）是一个开源的容器和微服务监测和预警工具集。Prometheus是为提供丰富度量指标、又不影响目标系统性能而设计的、高度可定制的云原生监控系统。Prometheus已经成为主流开源的监测工具，受到了广大用户的欢迎，对于那些严重依赖容器和微服务的人来说，Prometheus是他们最佳的选择。Prometheus适用于各种规模、各个行业。Prometheus已经具备完整的生态，包括与监控密切关联的报警系统，也非常方便与第三方的监控系统集成，成为监控报警平台。Prometheus为现代DevOps工作流提供了关键组件，监视云原生应用程序和基础设施，并与CNCF另一个流行的项目Kubernetes完美协同。
Prometheus是由SoundCloud开发的开源监控报警系统和时序数据库（Time Series Database，TSDB）。Prometheus受Google的Brogmon监控系统的启发（Kubernetes是从Google的Brog系统演变而来的），从2012年开始由前Google工程师在SoundCloud以开源软件的形式进行研发，并且于2015年初对外发布早期版本。2016年5月继Kubernetes之后成为第二个正式加入CNCF基金会的项目，同年6月正式发布1.0版本。2017年底发布了基于全新存储层的2.0版本，能更好地与容器平台、云平台配合。2018年8月，Prometheus已成为CNCF历史上第二个“毕业”的项目。
二、Prom组件
Prometheus生态系统包含多个组件，其中许多是可选的：
- Prometheus server ：Prometheus主服务器，它会抓取并存储时间序列数据
- client libraries：客户端库，用于检测应用程序代码
- push gateway：一个支持短期工作short-lived 的推送网关
- exporters导出器：诸如HAProxy，StatsD，Graphite等服务的专用导出器
- alertmanager：警报经理以处理警报
- 各种支持工具
更详细说明 见附录一
三、Prom的架构
学习一个软件，看一下框架是很重要的，这样你就能知道它的组成，工作流程等
根据 Prometheus 官网Architecture ，目前最新版本为2.20，构架如下：
3.1 框架图简单说明
上图中，中间部分是最重要的，也是核心部分，即prometheus server
既然是监控软件，肯定涉及到数据采集、展示、报警三大功能，你图左边为数据采集、图右上为警告处理、图右下为数据展示
3.2 prometheus服务器
prometheus 服务器，如中图中：
这个是最核心部分，prometheus是使用Go语言编写的，使用是非源码安装，所以已经把相关依赖都弄进去了，基本上不需要安装任何依赖。
用于收集和存储时间序列数据。Prometheus Server是Prometheus组件中的核心部分，负责实现对监控数据的获取,存储以及查询。提供一套灵活高效的查询( PromQL )
prometheus server分为三部分：
- Retrieval（238, 238, 238); opacity: 0.6;">
优点：这样做是是的架构简单命令,在做prometheus的多台server HA的时候非常方便。
缺点：无法对海量的数据进行存储(数据最多保留几周或者几个月) , 还有个缺点就是当我们的prometheus压力有点大的时候,横向扩容也是不方便的。
所以Prometheus提供了remote_ write和remote_ read的特性 ,支持将数据存储到远端和从远端读取数据。通过将监控与数据分离, Prometheus能够更好地进行弹性扩展。
时序数据库排行榜中的时序数据库如下：
PS：
时序数据库（Time Series Database，TSDB）用于保存时间序列（按时间顺序变化）的海量数据，是一种高性能、低成本、稳定可靠的专业化数据库。它可以提供高效读写、高压缩比低成本存储、降精度、插值、多维聚合计算和查询功能，解决由于设备采集点数据量巨大、数据采集频率高而造成的存储成本高、写入和查询分析效率低的问题。时序数据库广泛应用于物联网监控系统、企业能源管理系统、生产安全监控、电力检测系统等行业场景。
3.2.2 服务发现
服务发现，如中图上：
服务发现, Prometheus支持多种服务发现机制:文件, DNS , Consul,Kubernetes,OpenStack,EC2等等。基于服务发现的过程并不复杂,通过第三方提供的接口, Prometheus查询到需要监控的Target列表,然后轮训这些Target获取监控数据。
3.3 prom数据采集、报警、展示功能
3.3.1 数据采集
靠pull metrics（指标）去拉数据，看图左边。
左上图：
short-lived jobs :
存在时间不足以被删除的短暂和批量作业,无法通过pull方式拉取,需要使用push方式，与PushGateway搭配使用Pushgateway
在其他情况下Prometheus都是通过Pull的方式从Exporters拉取,但是有一些情况是我们网络不允许Prometheus和Exporters直接通信的情况下，可以使用Pushgateway由客户端主:动push数据到Pushgateway ,再由Prometheus拉取,很多时候我们需要自定义-些组件来采集。主要是拉取从Pushgateway推送过来的metric。主要是因为
1.Prometheus 采用 pull 模式，可能由于不在一个子网或者防火墙原因，导致 Prometheus 无法直接拉取各个 target 数据。
2.在监控业务数据的时候，需要将不同数据汇总, 由 Prometheus 统一收集。
由于以上原因,不得不使用pushgateway ,但在使用之前,有必要了解一下它的一些弊端:
1、将多个节点数据汇总到pushgateway, 如果pushgateway挂了, 受影响比多个target大。
2、Prometheus 拉取状态up只针对pushgateway,无法做到对每个节点有效。
3、Pushgateway 可以持久化推送给它的所有监控数据。因此，可以做多个pushgateway;即使你的监控已经下线, prometheus还会拉取到旧的监控数据,需要手动清理pushgateway不要的数据。
左下图：
Exporters/Jobs :
负责收集目标对象( host, container... )的性能数据,并通过HTTP接口供Prometheus Server获取。支持数据库、硬件、消息中间件、存储系统、http服务器、 jmx等。只要符合接口格式,就可以被采集。从已经配置好的job或者exporter中拉取metric。
ps：从其他的Prometheus服务器中拉取metric
Prometheus服务器获取到数据后存储在本地（也可以选择远端存储），通过一定规则对数据进行清理和整理，并且把结果存储到新的时间序列中。
PS：
- 所谓的metrics（指标），可以理解成符合它标准的资源，比较要cpu0、内存（总、剩余、使用）等
- 在Prometheus中，任何被采集的目标，即每一个暴露监控样本数据的HTTP服务都称为一个实例（Instance），通常对应于单个进程。而具有相同采集目的的实例集合（比如为可伸缩性或可靠性而复制的流程）称为作业（Job）
3.3.2 报警功能
报警功能主要是靠prom服务器 push 警告到 alertmanager 组件上，图右边上
Prometheus服务器定时查询已经定义好的规则，若发现满足定义的触发条件，便将alert信息推送至已配置好的Alertmanager。
Alertmanager收到alert信息后，根据配置文件对接收到的alert信息进行处理（聚合、去重、降噪），然后将它们转换为网页、电子邮件和其他通知方式发出告警
3.3.3 数据展示
图右下是数据展示：
靠PromQL 表达式语言，对prom的数据进行筛选，最后把结果显示出来，可以是自带的，也可以使用第三方的Grafana软件
Prometheus在记录纯数字时间序列方面表现得非常优秀。它既适用于对服务器硬件各项指标的监控，也适用于对高度动态的面向服务架构的监控。在当下比较火的微服务生态圈中，它对多维数据收集和查询的支持具有特殊的优势。
四、Prometheus_工作流程
综合上面，知道Prometheus_工作流程大概如下：
1.Prometheus server定期从配置好的jobs或者exporters 中拉metrics ,或者接收来自Pushgateway发过来的metrics ,或者从其他的Prometheus server中拉metrics。
2 Prometheus server在本地存储收集到的metrics ,并运行E定义好的alert.rules ,记录新的时间序列或者向Alertmanager推送警报。
3 Alertmanager根据配置文件,对接收到的警报进行处理,发出告警。
4.在图形界面中,可视化采集数据,可以使用别人写好的Grafana模板,或者可以自己灵活定制相关方法。
附录一、Prometheus核心组件
Prometheus生态圈系统由多个组件组成，其中许多组件是可选的。大多数Prometheus组件使用Go语言编
写而成，这样可以非常容易地构建和部署为静态的二进制文件。我们介绍几个核心组件：1.Prometheus服务器
Prometheus服务器（server）是Prometheus架构中的核心组件，基于Go语言编写而成，无第三方依赖关
系，可以独立部署在物理服务器、云主机、Docker容器内。主要用于收集每个目标数据，并存储为时间序
列数据，对外可提供数据查询支持和告警规则配置管理。Prometheus服务器可以对监控目标进行静态配置管理或动态配置管理，它将监控采集到的数据按照时间
序列存储在本地磁盘的时序数据库中（当然也支持远程存储），自身对外提供了自定义的PromQL语言，可
以对数据进行查询和分析。2.Client Library
Client Library是用于检测应用程序代码的客户端库。在监控服务之前，需要向客户端库代码添加检测，
从而实现了Prometheus中metric的类型。所有主要语言和运行时都可以用于客户端库。Prometheus项目提供了官方的客户端库，包括Go、
Python、Java/JVM和Ruby。还有第三方客户端库，例如Bash、C++、.Net/C#、Node.js、PHP、Haskell、
Erlang和Rust。客户端库负责所有细节，如线程安全和生成Prometheus文本表示格式以响应HTTP请求。由于基于指标
的监视不跟踪单个事件，客户端库内存使用不会随着事件的增加而增加。相反，内存与你拥有的监控指标
的数量相关。
根据库和运行时环境的不同，一些指标通常是由客户端库提供的，比如CPU使用率和垃圾收集统计数
据。客户端库不限于以Prometheus文本格式输出指标。Prometheus是一个开放的生态系统，用于生成文本格
式的API可以生成其他格式的指标。3.Exporter
用于输出被监控组件信息的HTTP接口统称为Exporter（导出器）。目前互联网公司常用的组件大部分
都有Exporter供直接使用，比如Nginx、MySQL、Linux系统信息（包括磁盘、内存、CPU、网络等）。Exporter是Prometheus系统中重要的组成部分。在实际中收集监控样本数据都是由Exporter完成的。
Exporter可以是一个独立运行的进程，对外提供一个用于获取监控数据的HTTP服务。Prometheus server只需
要定时通过这些Exporter提供的HTTP服务获取监控数据即可。可以类似理解为我们传统意义上的被监控目
标的agent，只是区别在于Exporter不会主动推送监控数据到Prometheus server。官方的Exporter列表中包含了常见的绝大多数系统监控指标，比如用于机器性能监控的node_exporter，
MySQL数据库监控的mysqld_exporter，以及网络设备监控的snmp_exporter等。这些已有的Exporter对于监控
来说，只需进行很少的配置，就能提供完善的数据指标采集工作。4.Pushgateway
Pushgateway是指用于支持短期临时或批量计划任务工作的数据汇聚节点。主要用于短期的Job，此类
Job存在的时间较短，可能在Prometheus来pull之前就自行消失了。所以针对这类Job，设计成可以直接向
Pushgateway推送metric，这样Prometheus服务器端便可以定时去Pushgateway拉取metric。
另外当某应用系统的网络环境中，Prometheus server和Exporter不能进行直接互通，我们可以使用
Pushgateway来进行中转。5.Alertmanager
Alertmanager主要用于处理Prometheus服务器端发送的alerts信息，对其去除重数据、分组并路由到正确
的接收方式，发出告警。它支持的告警通知方式非常丰富，常见的通知方式有电子邮件、pagerduty、
OpsGenie，webhook等，还可以控制告警的静音和抑制。