第一章 :Prometheus组件详解及其特点分析
笔记总结：
安装篇可去到这个链接：
(33条消息) Prometheus Server+Node Exporter+Grafana创建可视化Dashboard_赵唯一的博客-CSDN博客
https://blog.csdn.net/m0_72264240/article/details/130930831?csdn_share_tail=%7B%22type%22%3A%22blog%22%2C%22rType%22%3A%22article%22%2C%22rId%22%3A%22130930831%22%2C%22source%22%3A%22m0_72264240%22%7D
Prometheus 的特点
Prometheus 是一个开源的完整监控解决方案，其对传统监控系统的测试和告警模型进行了彻底的颠覆，形成了基于中央化的规则计算、统一分析和告警的新模型。 相比于传统监控系统，Prometheus 具有以下优点：
易于管理
Prometheus 核心部分只有一个单独的二进制文件，不存在任何的第三方依赖(数据库，缓存等等)。唯一需要的就是本地磁盘，因此不会有潜在级联故障的风险。
Prometheus 基于 Pull 模型的架构方式，可以在任何地方（本地电脑，开发环境，测试环境）搭建我们的监控系统。
PULL模型：
pull（拉）模式就是消费者主动去消息队列拉取消息；
push（推）模式消费者不需要主动，消息队列会自动将消息发送到消费者方。
Prometheus同其它TSDB相比有一个非常典型的特性:它主动从各Target上“拉取(pull)”数据，而非等待被监控端的“推送(push)
两个方式各有优劣，其中，Pul模型的优势在于:集中控制:有利于将配置集在Prometheus Server上完成，包括指标及采取速率等:
Prometheus的根本目标在于收集在Target上预先完成聚合的聚合型数据，而非一款由事件驱动的存储系统;
无论哪种方式，Server端都是pull的
对于一些复杂的情况，还可以使用 Prometheus 服务发现(Service Discovery)的能力动态管理监控目标。同时Pometheus 鼓励用户监控服务的内部状态，基于Prometheus 丰富的 Client 库，用户可以轻松的在应用程序中添加对Prometheus 的支持，从而让用户可以获取服务和应用内部真正的运行状态。
强大的数据模型
Prometheus仅用于以“键值”形式存储时序式的聚合数据，它并不支持存储文本信息;
其中的“键”称为指标(Metric)，通常代表着CPU速率、内存使用率或分区空闲比例等;
同一指标可能会适配到多个目标或设备，因而它使用“标签”作为元数据，从而为Metric添加更多的信息描述纬度;
这些标签还可以作为过滤器进行指标过滤及聚合运算。
所有采集的监控数据均以指标(metric)的形式保存在内置的时间序列数据库当中（TSDB，Time Series DB）。所有的样本除了基本的指标名称以外，还包含一组用于描述该样本特征的标签。如下所示：
http_request_status{
code='200',
content_path='/api/path',
environment='produment'
} =>
[value1@timestamp1,value2@timestamp2...]
http_request_status{ # 指标名称
code='200', # 维度的标签
content_path='/api/path2',
environment='produment'
} =>
[value1@timestamp1,value2@timestamp2...] # 存储的样本值
作业 (Job)和实例 (lnstance)
Instance:能够接收Prometheus Server数据Scrape操作的每个网络端点(endpoint)即为一个Instance(实例);
具有类似功能的Instance的集合称为一个Job，例如一个MySQL主从复制群中的所有MvSOL进程;
Job是Mysql主从复制进程，target是每个mysql
强大的查询语言 PromQL
比如通过Node Exporter暴露的HTTP服务，Prometheus可以采集到当前主机所有监控指标的样本数据。
# HELP node_cpu Seconds the cpus spent in each mode.
# TYPE node_cpu counter
node_cpu{cpu="cpu0",mode="idle"} 362812.7890625
# HELP node_load1 1m load average.
# TYPE node_load1 gauge
node_load1 3.0703125其中非#开头的每一行表示当前Node Exporter采集到的一个监控样本：node_cpu和node_load1表明了当前指标的名称、大括号中的标签则反映了当前样本的一些特征和维度、浮点数则是该监控样本的具体值。
样本
Prometheus会将所有采集到的样本数据以时间序列（time-series）的方式保存在内存数据库中，并且定时保存到硬盘上。time-series是按照时间戳和值的序列顺序存放的，我们称之为向量(vector).
每条time-series通过指标名称(metrics name)和一组标签集(labelset)命名。如下所示，可以将time-series理解为一个以时间为Y轴的数字矩阵：
^
│ . . . . . . . . . . . . . . . . . . . node_cpu{cpu="cpu0",mode="idle"}
│ . . . . . . . . . . . . . . . . . . . node_cpu{cpu="cpu0",mode="system"}
│ . . . . . . . . . . . . . . . . . . node_load1{}
│ . . . . . . . . . . . . . . . . . .
v
<------------------ 时间 ---------------->
在time-series中的每一个点称为一个样本（sample），样本由以下三部分组成：
- 指标(metric)：metric name和描述当前样本特征的labelsets;
- 时间戳(timestamp)：一个精确到毫秒的时间戳;
- 样本值(value)： 一个float64的浮点型数据表示当前样本的值。
<--------------- metric ---------------------><-timestamp -><-value->
http_request_total{status="200", method="GET"}@1434417560938 => 94355
http_request_total{status="200", method="GET"}@1434417561287 => 94334
http_request_total{status="404", method="GET"}@1434417560938 => 38473
http_request_total{status="404", method="GET"}@1434417561287 => 38544
http_request_total{status="200", method="POST"}@1434417560938 => 4748
http_request_total{status="200", method="POST"}@1434417561287 => 4785
指标(Metric)
在形式上，所有的指标(Metric)都通过如下格式标示：
{ 指标的名称(metric name)可以反映被监控样本的含义
（比如，http_request_total - 表示当前系统接收到的HTTP请求总量）。
指标名称只能由ASCII字符、数字、下划线以及冒号组成并必须符合正则表达式
[a-zA-Z_:][a-zA-Z0-9_:]*。
标签(label)反映了当前样本的特征维度，通过这些维度Prometheus可以对样本数据进行过滤，聚合等。
标签的名称只能由ASCII字符、数字以及下划线组成并满足正则表达式
[a-zA-Z_][a-zA-Z0-9_]*。
其中以__作为前缀的标签，是系统保留的关键字，只能在系统内部使用。标签的值则可以包含任何Unicode编码的字符。在Prometheus的底层实现中指标名称实际上是以__name__=的形式保存在数据库中的，因此以下两种方式均表示的同一条time-series：
api_http_requests_total{method="POST", handler="/messages"}
等同于：
{__name__="api_http_requests_total"，method="POST", handler="/messages"}
在Prometheus源码中也可以指标(Metric)对应的数据结构，如下所示：
type Metric LabelSet
type LabelSet map[LabelName]LabelValue
type LabelName string
type LabelValue stringMetric类型
在Prometheus的存储实现上所有的监控样本都是以time-series的形式保存在Prometheus内存的TSDB（时序数据库）中，而time-series所对应的监控指标(metric)也是通过labelset进行唯一命名的。
从存储上来讲所有的监控指标metric都是相同的，但是在不同的场景下这些metric又有一些细微的差异。
#例如，在Node Exporter返回的样本中指标node_load1反应的是当前系统的负载状态，随着时间的变化这个指标返回的样本数据是在不断变化的。
#而指标node_cpu所获取到的样本数据却不同，它是一个持续增大的值，因为其反应的是CPU的累积使用时间，从理论上讲只要系统不关机，这个值是会无限变大的。为了能够帮助用户理解和区分这些不同监控指标之间的差异，Prometheus定义了4中不同的指标类型(metric type)：Counter（计数器）、Gauge（仪表盘）、Histogram（直方图）、Summary（摘要）。
在Exporter返回的样本数据中，其注释中也包含了该样本的类型。例如：
# HELP node_cpu Seconds the cpus spent in each mode.
# TYPE node_cpu counter
node_cpu{cpu="cpu0",mode="idle"} 362812.7890625
Counter：只增不减的计数器
Counter类型的指标其工作方式和计数器一样，只增不减（除非系统发生重置）。
常见的监控指标，如http_requests_total，node_cpu都是Counter类型的监控指标。
一般在定义Counter类型指标的名称时推荐使用_total作为后缀。
#Counter是一个简单但有强大的工具，例如我们可以在应用程序中记录某些事件发生的次数，通过以时序的形式存储这些数据，我们可以轻松的了解该事件产生速率的变化。 PromQL内置的聚合操作和函数可以让用户对这些数据进行进一步的分析：例如，通过rate()函数获取HTTP请求量的增长率：
rate(http_requests_total[5m])
查询当前系统中，访问量前10的HTTP地址：
topk(10, http_requests_total)
Gauge：可增可减的仪表盘
与Counter不同，Gauge类型的指标侧重于反应系统的当前状态。
因此这类指标的样本数据可增可减。常见指标如：node_memory_MemFree（主机当前空闲的内容大小）、node_memory_MemAvailable（可用内存大小）都是Gauge类型的监控指标。
通过Gauge指标，用户可以直接查看系统的当前状态：
node_memory_MemFree
对于Gauge类型的监控指标，通过PromQL内置函数delta()可以获取样本在一段时间返回内的变化情况。例如，计算CPU温度在两个小时内的差异：
delta(cpu_temp_celsius{host="zeus"}[2h])
还可以使用deriv()计算样本的线性回归模型，甚至是直接使用predict_linear()对数据的变化趋势进行预测。例如，预测系统磁盘空间在4个小时之后的剩余情况：
predict_linear(node_filesystem_free{job="node"}[1h], 4 * 3600)
使用Histogram和Summary分析数据分布情况
除了Counter和Gauge类型的监控指标以外，Prometheus还定义了Histogram和Summary的指标类型。
Histogram和Summary主用用于统计和分析样本的分布情况。
在大多数情况下人们都倾向于使用某些量化指标的平均值，例如CPU的平均使用率、页面的平均响应时间。这种方式的问题很明显，以系统API调用的平均响应时间为例：如果大多数API请求都维持在100ms的响应时间范围内，而个别请求的响应时间需要5s，那么就会导致某些WEB页面的响应时间落到中位数的情况，而这种现象被称为长尾问题。
#为了区分是平均的慢还是长尾的慢，最简单的方式就是按照请求延迟的范围进行分组。例如，统计延迟在0~10ms之间的请求数有多少而10~20ms之间的请求数又有多少。通过这种方式可以快速分析系统慢的原因。Histogram和Summary都是为了能够解决这样问题的存在，通过Histogram和Summary类型的监控指标，我们可以快速了解监控样本的分布情况。例如，指标prometheus_tsdb_wal_fsync_duration_seconds的指标类型为Summary。 它记录了Prometheus Server中wal_fsync处理的处理时间，通过访问Prometheus Server的/metrics地址，可以获取到以下监控样本数据：
# HELP prometheus_tsdb_wal_fsync_duration_seconds Duration of WAL fsync.
# TYPE prometheus_tsdb_wal_fsync_duration_seconds summary
prometheus_tsdb_wal_fsync_duration_seconds{quantile="0.5"} 0.012352463
prometheus_tsdb_wal_fsync_duration_seconds{quantile="0.9"} 0.014458005
prometheus_tsdb_wal_fsync_duration_seconds{quantile="0.99"} 0.017316173
prometheus_tsdb_wal_fsync_duration_seconds_sum 2.888716127000002
prometheus_tsdb_wal_fsync_duration_seconds_count 216
从上面的样本中可以得知当前Prometheus Server进行wal_fsync操作的总次数为216次，耗时2.888716127000002s。其中中位数（quantile=0.5）的耗时为0.012352463，9分位数（quantile=0.9）的耗时为0.014458005s。
在Prometheus Server自身返回的样本数据中，我们还能找到类型为Histogram的监控指标prometheus_tsdb_compaction_chunk_range_bucket。
# HELP prometheus_tsdb_compaction_chunk_range Final time range of chunks on their first compaction
# TYPE prometheus_tsdb_compaction_chunk_range histogram
prometheus_tsdb_compaction_chunk_range_bucket{le="100"} 0
prometheus_tsdb_compaction_chunk_range_bucket{le="400"} 0
prometheus_tsdb_compaction_chunk_range_bucket{le="1600"} 0
prometheus_tsdb_compaction_chunk_range_bucket{le="6400"} 0
prometheus_tsdb_compaction_chunk_range_bucket{le="25600"} 0
prometheus_tsdb_compaction_chunk_range_bucket{le="102400"} 0
prometheus_tsdb_compaction_chunk_range_bucket{le="409600"} 0
prometheus_tsdb_compaction_chunk_range_bucket{le="1.6384e+06"} 260
prometheus_tsdb_compaction_chunk_range_bucket{le="6.5536e+06"} 780
prometheus_tsdb_compaction_chunk_range_bucket{le="2.62144e+07"} 780
prometheus_tsdb_compaction_chunk_range_bucket{le="+Inf"} 780
prometheus_tsdb_compaction_chunk_range_sum 1.1540798e+09
prometheus_tsdb_compaction_chunk_range_count 780
与Summary类型的指标相似之处在于Histogram类型的样本同样会反应当前指标的记录的总数(以_count作为后缀)以及其值的总量（以_sum作为后缀）。
不同在于Histogram指标直接反应了在不同区间内样本的个数，区间通过标签len进行定义。
同时对于Histogram的指标，我们还可以通过histogram_quantile()函数计算出其值的分位数。不同在于Histogram通过histogram_quantile函数是在服务器端计算的分位数。 而Sumamry的分位数则是直接在客户端计算完成。因此对于分位数的计算而言，Summary在通过PromQL进行查询时有更好的性能表现，而Histogram则会消耗更多的资源。反之对于客户端而言Histogram消耗的资源更少。
高效
对于监控系统而言，大量的监控任务必然导致有大量的数据产生。
而Prometheus 可以高效地处理这些数据，对于单一Prometheus Server 实例而言它可以处理：
数以百万的监控指标
每秒处理数十万的数据点
可扩展
可以在每个数据中心、每个团队运行独立的Prometheus Sevrer。Prometheus 对于联邦集群的支持，可以让多个 Prometheus 实例产生一个逻辑集群，当单实例 Prometheus Server 处理的任务量过大时，通过使用功能分区(sharding)+联邦集群(federation)可以对其进行扩展。
易于集成
使用Prometheus 可以快速搭建监控服务，并且可以非常方便地在应用程序中进行集成。
目前支持：Java，JMX，Python，Go，Ruby，.Net，Node.js 等等语言的客户端 SDK，基于这些 SDK 可以快速让应用程序纳入到 Prometheus 的监控当中，或者开发自己的监控数据收集程序。
同时这些客户端收集的监控数据，不仅仅支持 Prometheus，还能支持 Graphite 这些其他的监控工具。同时Prometheus 还支持与其他的监控系统进行集成：Graphite，Statsd，Collected， Scollector， muini， Nagios 等。 Prometheus 社区还提供了大量第三方实现的监控数据采集支持：JMX，CloudWatch，EC2，MySQL，PostgresSQL，Haskell，Bash，SNMP， Consul，Haproxy，Mesos，Bind，CouchDB，Django，Memcached，RabbitMQ，Redis，RethinkDB，Rsyslog 等等。
可视化
Prometheus Server 中自带的 Prometheus UI，可以方便地直接对数据进行查询，并且支持直接以图形化的形式展示数据。同时 Prometheus 还提供了一个独立的基于Ruby On Rails 的 Dashboard 解决方案 Promdash。
最新的 Grafana 可视化工具也已经提供了完整的Prometheus 支持，基于 Grafana 可以创建更加精美的监控图标。
基于Prometheus 提供的API 还可以实现自己的监控可视化UI。
开放性
通常来说当我们需要监控一个应用程序时，一般需要该应用程序提供对相应监控系统协议的支持，因此应用程序会与所选择的监控系统进行绑定。为了减少这种绑定所带来的限制，对于决策者而言要么你就直接在应用中集成该监控系统的支持，要么就在外部创建单独的服务来适配不同的监控系统。
而对于 Prometheus 来说，使用 Prometheus 的 client library 的输出格式不止支持Prometheus 的格式化数据，也可以输出支持其它监控系统的格式化数据，比如 Graphite。因此你甚至可以在不使用Prometheus 的情况下，采用 Prometheus 的 client library 来让你的应用程序支持监控数据采集。
Prometheus 组件介绍
Prometheus Server
Prometheus Server是Prometheus组件中的核心部分，负责实现对监控数据的获取，存储以及查询。 Prometheus Server可以通过静态配置管理监控目标，也可以配合使用Service Discovery的方式动态管理监控目标，并从这些监控目标中获取数据。其次Prometheus Server需要对采集到的监控数据进行存储，Prometheus Server本身就是一个时序数据库，将采集到的监控数据按照时间序列的方式存储在本地磁盘当中。最后Prometheus Server对外提供了自定义的PromQL语言，实现对数据的查询以及分析。
Prometheus Server内置的Express Browser UI，通过这个UI可以直接通过PromQL实现数据的查询以及可视化。
Prometheus Server的联邦集群能力可以使其从其他的Prometheus Server实例中获取数据，因此在大规模监控的情况下，可以通过联邦集群以及功能分区的方式对Prometheus Server进行扩展。
Exporters
exporter 简单说是采集端，通过 http 服务的形式保留一个 url 地址，prometheus server 通过访问该 exporter 提供的 endpoint 端点，即可获取到需要采集的监控数据。
一般来说可以将Exporter分为2类：
- 直接采集：这一类Exporter直接内置了对Prometheus监控的支持，比如cAdvisor，Kubernetes，Etcd，Gokit等，都直接内置了用于向Prometheus暴露监控数据的端点。
- 间接采集：间接采集，原有监控目标并不直接支持Prometheus，因此我们需要通过Prometheus提供的Client Library编写该监控目标的监控采集程序。例如： Mysql Exporter，JMX Exporter，Consul Exporter等。
AlertManager
在Prometheus Server中支持基于PromQL创建告警规则，如果满足PromQL定义的规则，则会产生一条告警，而告警的后续处理流程则由AlertManager进行管理。在AlertManager中我们可以与邮件，Slack等等内置的通知方式进行集成，也可以通过Webhook自定义告警处理方式。AlertManager即Prometheus体系中的告警处理中心。
PushGateway
由于Prometheus数据采集基于Pull模型进行设计，因此在网络环境的配置上必须要让Prometheus Server能够直接与Exporter进行通信。 当这种网络需求无法直接满足时，就可以利用PushGateway来进行中转。可以通过PushGateway将内部网络的监控数据主动Push到Gateway当中。而Prometheus Server则可以采用同样Pull的方式从PushGateway中获取到监控数据。
流程总结
prometheus 负责从 pushgateway 和 job 中采集数据， 存储到后端 Storatge 中，（可以通过PromQL 进行查询）， 推送 alerts 信息到 AlertManager， AlertManager 根据不同的路由规则进行报警通知。
架构理解
存储计算层
Prometheus Server，里面包含了存储引擎和计算引擎。
Retrieval 组件为取数组件，它会主动从 PushGateway 或者 Exporter 拉取指标数据。
Service discovery，可以动态发现要监控的目标。
TSDB，数据核心存储与查询。
HTTP server，对外提供 HTTP 服务。
采集层
采集层分为两类，一类是生命周期较短的作业，还有一类是生命周期较长的作业。
短作业：直接通过 API，在退出时间指标推送给PushGateway 。
长作业：Retrieval 组件直接从 Job 或者 Exporter 拉取数据。
应用层
应用层主要分为两种，一种是AlertManager，另一种是数据可视化。
AlertManager
对接Pagerduty，是一套付费的监控报警系统。可实现短信报警、5 分钟无人 ack 打电话通知、仍然无人 ack，通知值班人员 Manager…Emial，发送邮件… …
数据可视化
Prometheus build-in WebUI、Grafana、其他基于API 开发的客户端
抓取到异常值后，Prometheus支持通过“告警(Alert)”机制向用户发送反馈或警示，以触发用户能够及时采取应对措施;
Prometheus Server仅负责生成告警指示，具体的告警行为由另一个独立的应用程序AlertManager负责;
告警指示由Prometheus Server基于用户提供的“告警规则”周期性计算生成;Alertmanager接收到Prometheus Server发来的告警指示后，基于用户定义的告警路由(route)向告警接收人receivers)发送告警信息;