Prometheus分享--01介绍和特点

风干工程师肉要不要

已于 2023-01-06 10:06:30 修改

阅读量1.5k

点赞数 1

分类专栏： prometheus 文章标签：云原生 Powered by 金山文档

于 2023-01-06 09:50:16 首次发布

本文链接：https://blog.csdn.net/weixin_42714264/article/details/128573845

版权

prometheus 专栏收录该内容

4 篇文章 0 订阅

订阅专栏

1. 监控系统组成

一个完整的监控系统需要包括如下功能：数据产生、数据采集、数据存储、数据处理、数据展示分析、告警；

1.1 数据来源

我们如果要监控数据，首先得有数据，也就是说，这些数据应该可以被记录下来，或者被暴露出来，数据常见的产生、直接或间接暴露方式的方式如下：

硬件本身的记录信息 - 以文件或者以内存属性的方式存在

应用业务的接口 - 主动暴露软件本身的运行状态，比如 redis info、各种status等

相关的信息采集工具 - 方便收集数据或者采集数据的系统级别的命令等

注意：这些数据在长时间的运行过程中，都是以固定的"属性指标"来描述他们，我们把这些称为 metric。监控系统就需要对每个环境的每一个指标都要进行数据的获取，并且按照用户需要的方式提供给用户来使用。

1.2 数据采集和传输

对于上面所说的Metric指标数据，我们不是说只要获取一次就可以了，而是需要持续性、周期性的方式来采集。根据数据采集方式的不同划分为了两个分类：

软件层面:

agent: 专用的软件的一种应用机制。

ssh: 系统常见的一种应用通信机制，但是并非所有系统都支持。

SNMP: 简单网络管理协议(Simple Network Management Protocol),是工作在各种网络设备中的一种机制。

硬件层面:

IPMI: 智慧平台管理接口(Intelligent Platform Management Interface)是一种工业标准用于采集硬件设备的各种物理健康状态数据，如温度、电压、风扇工作状态、电源状态等。

注意:由于每个业务场景，我们需要采集的指标量不好评估，甚至一个业务场景，就需要采集数百个指标，如果按照上述所说的周期性采集的方式来说，数据的采集量是相当大的。

1.3 数据存储

由于我们采集到的"样本数据"，不是一次性使用的，尤其是单个数据是没有意义的，我们需要将这些数据存储下来，在后续的工作场景中进行聚合操作，从而来满足我们的需求。所以这些数据的存储也是一个非常重要的点。同时，我们在后续使用这些数据的时候，不仅仅要知道这些数据，还要知道这些数据的时间属性即什么时候的数据。所以这些数据在存储的时候，必须有一个重要的时间维度。所以我们一般将这种用于监控场景的数据，称为时间序列数据 - TS(Time series data)，专门用于存储这些数据的数据库，称其为时序数据库(TSDB Time series database) 。

时序列数据库是用来存储时序列(time-series)数据并以时间(点或区间)建立索引的软件一般时序列数据都具备以下特点：

数据结构简单：某一度量指标在某一时间点只会有一个值，没有复杂的结构(嵌套、层次等)和关系(关联、主外键等)

数据量大：由于时序列数据由所监控的大量数据源来产生、收集和发送，比如主机、IoT设备、终端或App等

1.4 数据处理

如果仅仅采集到的是单条数据，本身没有太大的意义，我们需要对数据进行各种聚合和处理操作才可以正常的用于工作分析场景。所以对于各种聚合操作之后的数据，我们也需要进行分析和展示。

1.5 数据分析展示

无论是采集到的时序数据，还是经过聚合分析之后的统计数据，由于数据量巨大,用肉眼观察很难能够看得情楚，尤其是通过表格来查看成千上万条数据，来分析其内在的逻辑趋势关系更是如此。所以，对于监控系统来说，其本身的数据可视化功能是非常重要的，以各种图形演示的方式展示我们数据的发展趋势，方便我们进行分析。

1.6 告警

作为人是有休息的时候，有打盹的时候，不可能时时刻刻处于精神紧张的状态，所以我们需要在某些特殊情况下，提醒我们去看相关的数据，所以我们就需要根据日常工作中采集到的数据，来分析出正常的状态值，然后将其作为一个阈值指标。接下来在后续数据采集的时候，让实时的数据，与阈值进行比较，一旦超出我们的阈值判断机制，就通过告警机制通知给我们。提高我们的工作效率。

采集到的数据达到一定的条件,比如磁盘空间满等,应该自动触发告警提示,比如:微信,邮件,短信等,方便及时发现问题并解决。

2. 监控内容

2.1 资源数据

硬件设备：服务器、路由器、交换机、IO系统等

系统资源：OS、网络、容器、VM实例

应用软件：Nginx、MySQL、Java应用等

2.2 业务服务

业务状态：服务通信、服务运行、服务下线、性能指标、QPS、DAU(Daily Active User )日活、转化率、业务接口(登陆，注册，聊天，留言)、产品转化率、充值额度、用户投诉等。

一般故障：访问缓慢、存储空间不足，数据同步延迟，主机宕机、主机不可达。

严重故障：服务不可用、集群故障。

2.3 趋势分析

数据统计：时间序列数据展示历史数据等

数据预测：事件什么时候发生、持续时间、发生概率是多大等,比如:电商大促时间

3. 监控设施实现方式

对于Linux系统来说，它的系统监控的实现方式很多，主要有系统命令、开源软件、监控平台等。

3.1 系统命令

3.2 开源软件

对于传统的业务数据监控来说，Zabbix是优秀的，由于Zabbix诞生的时代业务数据量相对不是太多，所以它默认采取的是关系型数据库作为后端存储。

所以随着业务场景的发展，尤其是微服务、云原生场景的发展，大量数据的存储就成为了Zabbix本身的限制。所以就出现了另外一种监控软件 Prometheus。

3.3 监控平台

一些云服务商提供了监控平台可以实现监控功能

4. 时序数据库

4.1 什么是序列数据

参考资料: https://db-engines.com/en/ranking/time+series+dbms

时间序列数据(TimeSeries Data) : 按照时间顺序记录系统、设备状态变化的数据被称为时序数据。

时序数据库记录的数据以时间为横座标,纵坐标为其它数据。

时间序列数据库 (Time Series Database , 简称 TSDB) 是一种高性能、低成本、稳定可靠的在线时间序列数据库服务，提供高效读写、高压缩比存储、时序数据插值及聚合计算等服务，广泛应用于物联网 (IoT)设备监控系统、企业能源管理系统(EMS)、生产安全监控系统和电力检测系统等行业场景;除此以外，还提供时空场景的查询和分析的能力。

TSDB 具备秒级写入百万级时序数据的性能，提供高压缩比低成本存储、预降采样、插值、多维聚合计算、可视化查询结果等功能，解决由设备采集点数量巨大、数据采集频率高造成的存储成本高、写入和查询分析效率低的问题。

TSDB是一个分布式时间序列数据库，具备多副本高可用能力。同时在高负载大规模数据量的情况下可以方便地进行弹性扩容，方便用户结合业务流量特点进行动态规划与调整。

应用的场景很多:

物联网设备无时无刻不在产生海量的设备状态数据和业务消息数据，这些数据有助于进行设备监控、业务分析预测和故障诊断。

传统电力化工以及工业制造行业需要通过实时的监控系统进行设备状态检测，故障发现以及业务趋势分析。

系统运维和业务实时监控,通过对大规模应用集群和机房设备的监控，实时关注设备运行状态、资源利用率和业务趋势，实现数据化运营和自动化开发运维。

4.2 时间序列数据特点

大部分时间都是顺序写入操作，很少涉及修改数据

删除操作都是删除一段时间的数据，而不涉及到删除无规律数据

读操作一般都是升序或者降序

高效的压缩算法，节省存储空间，有效降低 IO,存储成本低

TSDB 使用高效的数据压缩技术，将单个数据点的平均使用存储空间降为1~2个字节，可以降低 90%存储使用空间，同时加快数据写入的速度

高性能读写, 每秒百万级数据点写入，亿级数据点聚合结果秒级返回

5. prometheus简介

5.1 prometheus简介

Prometheus 是一个开源的系统监控和报警系统，它启发于 Google 的 borgmon 监控系统，在一定程度上可以理解为，Google BorgMon监控系统的开源版本。

该软件由工作在 SoundCloud 的 google 前员工在 2012 年创建，作为社区开源项目进行开发，并于 2015 年正式发布。2016 年，Prometheus 正式加入 CNCF(Cloud Native Computing Foundation)，成为继 Kubernetes之后第二个在CNCF托管的项目, 现已广泛用于在容器和微服务领域中得到了广泛的应用，当然不仅限于此。

云原生: https://landscape.cncf.io/

Prometheus 本身基于Go语言开发的一套开源的系统监控报警框架和时序列数据库(TSDB)。

Prometheus 的监控功能很完善和全面，性能也足够支撑上万台规模的集群。

网站:https://prometheus.io/

github:https://github.com/prometheus

其特点主要如下:

支持多维数据模型:由度量名和键值对组成的时间序列数据

内置时间序列数据库TSDB(Time Series Database )

支持PromQL(Prometheus Query Language)查询语言，可以完成非常复杂的查询和分析，对图表展示和告警非常有意义

支持 HTTP的Pull方式采集时间序列数据

支持 PushGateway 采集瞬时任务的数据

支持静态配置和服务发现两种方式发现目标

多种可视化和仪表盘,支持第三方Dashboard,比如：Grafana

数据特点

监控指标，采用独创的指标格式，我们称之为Prometheus格式，这个格式在监控场景中很常见。

数据标签，支持多维度标签，每个独立的标签组合都代表一个独立的时间序列。

数据处理，Prometheus内部支持多种数据的聚合、切割、切片等功能。

数据存储，Prometheus支持双精度浮点型数据存储和字符串

适用场景

Prometheus 非常适合记录任何纯数字时间序列。它既适合以机器为中心的监控场景，也适合于高度动态的面向服务的体系结构的监控场景。尤其是在微服务世界中，它对多维数据收集和查询的支持是一种特别的优势。

Prometheus的设计旨在提高可靠性，使其成为中断期间要使用的系统，以使您能够快速诊断问题。每个Prometheus服务器都是独立的，而不依赖于网络存储或其他远程服务。当基础结构的其他部分故障时，您可以依靠它，并且无需设置广泛的基础结构即可使用它。

由于Prometheus重视可靠性。在故障情况下，我们可以查看有关系统的可用统计信息。但是如果您需要100%的准确性，则Prometheus并不是一个不错的选择，因为所收集的数据可能不会足够详细和完整。在这种情况下，最好使用其他系统来收集和分析数据以进行计费，并使用Prometheus进行其余的监视。

Prometheus 不足

不支持集群化

被监控集群规模过大后本身性能有一定瓶颈

中文支持不好中文资料也很少

5.2 prometheus架构

官方文档：

https://prometheus.io/docs/

https://prometheus.io/docs/introduction/overview/

5.2.1 数据获取逻辑

Prometheus同其它TSDB相比有一个非常典型的特性:它主动从各Target上“拉取(pull)”数据，相当于Zabbix里的被动模式,而非等待被监控端的“推送(push)”;

两个方式各有优劣，其中，Pull模型的优势在于：集中控制：有利于将配置集在 Prometheus Server上完成，包括指标及采取速率等,Prometheus的根本目标在于收集在Target上预先完成聚合的聚合型数据，而非一款由事件驱动的存储系统。

5.2.2 prometheus架构

Prometheus 的主要模块包括：

prometheus

时序数据存储、监控指标管理

可视化

Prometheus web UI : 集群状态管理、promQL

Grafana:非常全面的可视化套件

数据采集

Exporter: 为当前的客户端暴露出符合 Prometheus 规格的数据指标,Exporter 以守护进程的模式运行井开始采集数据,Exporter 本身也是一个http_server 可以对http请求作出响应返回数据 (K/V形式的metrics)

Pushgateway : 拉模式下数据的采集工具

监控目标

服务发现 :文件方式、dns方式、console方式、k8s方式

告警

alertmanager

Prometheus 由几个主要的软件组件组成，其职责概述如下。

组件	解析
Prometheus Server	彼此独立运行，仅依靠其本地存储来实现其核心功能:抓取时序数据，规则处理和警报等。
Client Library	客户端库，为需要监控的服务生成相应的 metrics 并暴露给 Prometheus server。当 Prometheus server 来 pull 时，直接返回实时状态的 metrics。
Push Gateway	exporter采集类型已经很丰富，但是依然需要很多自定义的监控数据,用 pushgateway可以实现自定义的监控数据,任意灵活想做什么都可以做到 exporter的开发需要使用真正的编程语言，不支持shell这种快速脚本,而 pushgateway开发去容易的多pushgateway主要用于短期的 jobs。由于这类 jobs 存在时间较短，可能在 Prometheus 来 pull 之前就消失了。为此，这次 jobs 可以直接向 Prometheus server 端推送它们的 metrics。这种方式主要用于服务层面的 metrics，对于机器层面的 metrices，需要使用 node exporter
Exporters	部署到第三方软件主机上，用于暴露已有的第三方服务的 metrics 给 Prometheus。
Alertmanager	从 Prometheus server 端接收到 alerts 后，会进行去除重复数据，分组，并路由到对应的接受方式，以高效向用户完成告警信息发送。常见的接收方式有:电子邮件，pagerduty，OpsGenie, webhook 等,一些其他的工具。
Data Visualization	Prometheus Web UI (Prometheus Server内建)，及Grafana等
Service Discovery	动态发现待监控的Target，从而完成监控配置的重要组件，在容器化环境中尤为有用;该组件目前由Prometheus Server内建支持;

在上诉的组件中，大多数都是用Go编写的，因此易于构建和部署为静态二进制文件。

5.2.3 prometheus工作流程

Prometheus server 定期从配置好的 jobs 或者 exporters 中拉 metrics，或者接收来自Pushgateway 发过来的 metrics，或者从其他的 Prometheus server 中拉 metrics。

Prometheus server 在本地存储收集到的 metrics，并运行已定义好的 alert.rules，记录新的时间序列或者向 Alertmanager 推送警报，实现一定程度上的完全冗余功能。

Alertmanager 根据配置文件，对接收到的警报进行去重分组，根据路由配置，向对应主机发出告警

集成Grafana或其他API作为图形界面，用于可视化收集的数据。

5.2.4 生态组件

Prometheus 只负责时序型指标数据的采集及存储

其它的功能,如: 数据的分析、聚合及直观展示以及告警等功能并非由Prometheus Server所负责,需要配合其它组件实现

5.2.4.1 支持丰富的 Exporter实现各种应用的监控

https://prometheus.io/docs/instrumenting/exporters/

5.3 prometheus数据模型

Prometheus中存储的数据为时间序列，即基于同一度量标准或者同一时间维度的数据流。除了时间序列数据的正常存储之外，Prometheus还会基于原始数据临时生成新的时间序列数据，用于后续查询的依据或结果。

每个时间序列都由metric名称(表示某项指标)和标签(键值对形式,表示属性,其为可选项)组合成唯一标识。

5.3.1 metric名字

该名字必须有意义，用于表示metric的一般性功能，例如:http_requests_total表示http 请求的总数。

metric 名字由 ASCII 字符，数字，下划线，以及冒号组成，且必须满足正则表达式[a-zA-Z_:][a-zA-Z0-9_:]* 的查询需求。

注意:冒号是为用户定义的记录规则保留的。

5.3.2 标签

标签是以键值对的样式而存在，不同的标签用于表示时间序列的不同维度标识

基本格式:

<metric name>{<label name>=<label value>, ...}

#示例样式:

http_requests_total{method="POST",endpoint="/api/tracks"}

解析: http_requests_total{method="POST"} 表示所有 http 请求中的 POST 请求， endpoint="/api/tracks"表示请求的url地址是/api/tracks。当 method="GET" 时，则为新的一个metric

标签中的键名由ASCII字符，数字，以及下划线组成，且必须满足正则表达式 [a-zA-Z_:][a-zA-Z0- 9_:]*。以__开头的标签名称保留供内部使用

标签值可以包含任何Unicode字符，标签值为空的标签被认为等同于不存在的标签

查询语言允许基于这些维度进行过滤和聚合。更改任何标签值，包括添加或删除标签，都会创建一个新的时间序列。

5.3.3 指标类型

Prometheus客户端库提供了四种核心度量标准类型。

官方说明

https://prometheus.io/docs/concepts/metric_types/

说明：

类型	解析
Counter-累计图	counter是一个累加的计数器，代表一个从0开始累积单调递增的计数器，其值只能在重新启动时增加或重置为零。典型的应用如:用户的访问量,请求的总个数，任务的完成数量或错误的数量等。不能使用Counter来表示递减值。
Gauge-量规图	Gauge是一种度量标准，只有一个简单的返回值，或者叫瞬时状态，可以代表可以任意metric的上下波动的数值。通常用于测量值，例如，硬盘剩余空间,当前的内存使用量,一个待处理队列中任务的个数等，还用于可能上升和下降的“计数”，例如并发请求数。
Histogram-直方图	Histogram统计数据的分布情况。比如最小值，最大值，中间值，还有中位数，75百分位,90百分位, 95百分位.98百分位,99百分位,和9.9百分位的值(percenties ,代表着近似的百分比估算数值比如: 每天1000万请中,统计http_response_time不同响应时间的分布情况,响应时间在0-0.05s有多少,0.05s到2s有多少,10s以上有多少每个存储桶都以"_BucketFuncName{...}" 样式来命名.例如 hist_sum、hist_count 等可以基于histogram_quantile()函数对直方图甚至是直方图的聚合来进行各种分析计算。
Summary-摘要	用于表示一段时间内的数据采样结果,典型的应用如:请求持续时间，响应大小。但它直接存储了分位数(将一个随机变量的概率分布范围分为几个等份的数值点，常用的有中位数即二分位数、四分位数、百分位数等)，而不是通过区间来计算。类似于直方图，摘要会基于阶段性的采样观察结果进行信息描述。它还提供了观测值的累计计算、百分位计算等功能，每个摘要的命名与Histogram 类似，例如: summary_sum、summary_count等

5.3.4 数据格式

Prometheus 数据格式，本质上就是将收集的数据转化为对应的文本格式，并提供 http 请求。

Exporter 收集的数据转化的文本内容以行 (\n) 为单位，空行将被忽略, 文本内容最后一行为空行

文本内容，如果以 # 开头通常表示注释。

以 # HELP 开头表示 metric 帮助说明。

以 # TYPE 开头表示定义 metric 类型，包含 counter, gauge, histogram, summary, 和 untyped 类型。其他表示一般注释，供阅读使用，将被 Prometheus 忽略。

5.3.5 任务和实例

用Prometheus术语来说，一个单独 scrape(<host>:<port>)的目标称为instance，通常对应于单个进

程。一组同种类型的 instances集合称为jobs，主要用于保证可扩展性和可靠性。

例如,一个 API 服务 job 包含四个instances:

job: api-server

instance 1: 1.2.3.4:5670

instance 2: 1.2.3.4:5671

instance 3: 5.6.7.8:5670

instance 4: 5.6.7.8:5671

对于任务实例来说，他们还可以借助于特殊的字符串来表示通用的功能，常见的使用样式如下:

#判断任务是否健康，1代表正常，0代表不正常

up{job="<job-name>", instance="<instance-id>"}

#获取任务的持续时间

scrape_duration_seconds{job="<job-name>", instance="<instance-id>"}

#任务执行后剩余的样本数

scrape_samples_post_metric_relabeling{job="<job-name>", instance="<instance- id>"}

#暴露的样本数量

scrape_samples_scraped{job="<job-name>", instance="<instance-id>"}

#样本的大概数量

scrape_series_added{job="<job-name>", instance="<instance-id>"}

总结

数据模型：metric名称+标签，每个指标都有2个默认的标签，instance和job

数据类型：Counter+Gauge+Histogram+Summary

任务：多个instances组成一个jobs

5.4 prometheus数据处理

5.4.1 数据获取

这些metric数据，是基于HTTP call方式来进行获取的，从对方的配置文件中指定的网络端点(endpoint, 即IP:Port,表示一个应用)上周期性获取指标数据。每一个端点上几乎不可能只有一个数据指标。

根据上面的了解，这些指标都必须以http的方式暴露出来，而这也是，prometheus无法直接获取内核等相关数据的原因，只能借助于其他的机制才可以。prometheus默认支持通过三种类型的途径从目标上“抓取(Scrape)”指标数据;

方式	解析
Exporters	部署到对应节点上，负责从目标应用程序上采集和聚合原始格式的数据，并转换或聚合为Prometheus格式的指标，以http方式向外暴露本地节点数据后
Instrumentation	指附加到应用程序中形成内建的检测系统，采集数据并暴露出来的客户端库，当然了，暴露的方式也是http方式
Pushgateway	接收节点上的任务机制获取数据并转换成 Prometheus 格式数据，然后推送给prometheus

5.4.2 数据存储

Prometheus 采用的是time-series(时间序列)的方式以一种自定义的格式存储在本地硬盘上

Prometheus的本地T-S(time-series)数据库以每两小时为间隔分成block为单位存储，每一个Block中又分为多个Chunk文件

Chunk是作为存储的基本单位,用来存放采集过来的数据的T-S数据,包括metadata和索引文件(index)。 Index文件是对metrics(对应一次KV采集数据)和 labels(标签)进行索引之后存储在chunk文件中 Prometheus平时是将采集过来的数据先都存放在内存之中, 以类似缓存的方式用于加快搜索和访问。

Prometheus提供一种保护机制叫做WAL( Write-Ahead Logging )可以将数据存入硬盘中的chunk文件，当出现宕机时，重新启动时利用此日志系统来恢复加载至内存

[root@prometheus ~]#tree /usr/local/prometheus/data

/usr/local/prometheus/data

├── 01G9RSD61ZEF16T5YGE91K49MZ

│ ├── chunks

│ │ └── 000001

│ ├── index

│ ├── meta.json

│ └── tombstones

├── 01G9RZ8VXF2FHHB18CW0594P8T

│ ├── chunks

│ │ └── 000001