1. 网站首页
  2. 帮助与支持
  3. 行业资讯

不懂 Prometheus 做不好运维？这篇干货快收藏

2024-11-08 14:11:15 Jinyu

1、介绍&架构

Prometheus 是一个开源系统监控和警报工具包，将其监控的指标进行收集并存储为时间序列数据，即指标信息与记录时的时间戳以及称为标签的可选键值对一起存储。很多公司用来监控 K8s 集群。

图片

2. 合适&不合适场景

  • 合适场景：Prometheus 可以很好地记录任何数字时间序列，它既适合以机器为中心的监控，也适合监控高度动态的面向服务的架构。在微服务的世界中，他对多维数据收集的查询的支持是一个特殊的优势。专为可靠性而设计，是在中断期间可以使用的系统，可让你快速诊断问题。每个Prometheus服务器都是独立的，不依赖于网络存储或其他远程服务。当你的基础设施的其他部分损坏时，你可以依赖他，并且你无需设置大量基础设施即可使用

  • 不合适场景：你需要100%准确性，例如按请求计费。这时候Prometheus就不太适合，你最好使用其他系统来收集和分析数据以进行计费。

3. 数据模型

因为监控数量极大，所以使用了时间序列数据存储（就是带时间戳和值的）

  • Prometheus 本地存储：

Prometheus的本地存储被称为 Prometheus TSDB。TSDB的设计核心有两个：block和WAL，而block又包含 chunk、index、meta.json、tombstones。
TSDB 将存储的监控数据按照时间分隔成 block，block 大小并不固定，按照设定的步长倍数递增。随着数据量的不断增长，TSDB 会将小的 block 合并成大的 block，这样不仅可以减少数据存储，还可以减少内存中的 block 个数，便于对数据进行索引。
每个block都有全局唯一的名称，通过ULID（Universally Unique Lexicograpphically Sortable Indetifier，全局字典可排序ID）原理生成，可以通过block的文件名确定这个block的创建时间，从而很方便的按照时间对block排序。对时序数据库的查询通常会涉及到连续的很多块，这种通过命名便可以排序的设计非常简便。
WAL（Write-Ahead Logging，预写日志）是关系型数据库中利用日志来实现事务性和持久性的一种技术，即在进行某个操作之前先将这件事情记录下来，以便之后数据进行回滚、重试等操作并保证数据的可靠性。Prometheus 为了防止丢失暂存在内存中还未被写入磁盘的监控数据，引入了 WAL 机制。
按照每种对象设定的采集周期，Prometheus 会将周期性采集的监控数据通过 Add接口添加到 head block 中，但这些数据没有被持久化，TSDB 通过 WAL 将提交的数据先保存到磁盘中，在 TSDB 宕机重启后，会首先启动多协程读取 WAL，从而恢复之前的状态。

  • Prometheus 数据模型：

Prometheus 将数据存储为时间序列，其中包括称为标签的键值对、时间戳和最后的值：

表示法：

<metric_name>[{<label_1=“value_1”>,<label_N=“value_N”>}]<datapoint_numercial_value>

4. 指标

  • Counter：Prometheus实例接收的数据包总数（一直增）

  • Gauge：测量是一种度量，他在收集时对给定的测量进行快照，可以增加或减少（例如温度、磁盘空间、内存使用量）

  • Histogram：常常用于观察，一个Histogram包含下列值的合并：【某时间段内的百分比或者请求数量有多少】

5. 指标的摘要和聚合

指标摘要：通常来说。单个指标对我们来说价值很小，往往需要联合并可视化多个指标，这其中需要一些数学变换，例如我们可能会统计函数应用于指标或指标组，常见函数有：计数、求和、平均值、中间数、百分位数、标准差、变化率等等

  • 指标聚合：就是能看到来自多个源的指标的聚合视图

6、NodeExporter部署

Prometheus 使用 exporter 工具来暴露主机和应用程序上的指标。有很多种类型的exporter。

7. cAdvisor 监控 Docker 容器

cAdvisor（Constainer Advisor）是由谷歌开发的一个项目，让从正在运行的容器手机、聚合、分析和导出数据。可用的数据涵盖了几乎所有你可能需要的东西，从内存限制到GPU指标

  • cAdvisor 并不绑定到 Docker 容器，但它通常作为一个容器部署，从容器守护进程和 Linux cgroups 收集数据，是容器的发现透明且完全自动化。

  • 除了以 Prometheus 格式公开指标之外，cAdvisor 还提供了一个有用的 web界面，允许即使可视化主机及其容器的状态。

8. 捕获目标生命周期

服务发现->配置->重新标记（relable_configs）-> 抓取 -> metrics_relable_configs

9. PromQL查询语言

选择器及标签匹配器：

（1）选择器

Prometheus被设计用来处理成千上万的时间序列、根据标签的组合，咩哥指标名称可以有几个不同的时间序列；当来自不同的工作的类型名称的指标混合在一起时，查询正确的数据可能看起来比较困难。所以在Prometheus中，选择器指的是一组标签匹配器、度量名称也包含在这个定义中，因为从技术上讲，他的内容表示也是一个标签，尽管是一个特殊的标签：name。
选择器中的每个标签名称/值对称为标签匹配器，多个匹配器可用于进一步筛选选择器匹配的时间序列。标签匹配器用花括号括起来。如果不需要匹配器，可以省略花括号。选择器可以返回及时或范围向量

//例如：$ prometheus_build_info{version="2.17.0"}

（2）标签匹配器

标签匹配器用于将查询搜索限制为特定的一组标签值。下面将使用node_cpu_secends_total metric来阐述标签匹配的操作，匹配的操作符有=、!=、=和! 如果没有任何匹配的规范。仅此度量就会返回一个包含度量名称的所有可用时间序列的及时向量。以及所有的CPU核心数（cpu=“0”，cpu=“1”）和CPU的型号（mode=“idle”，mode=“iowait”，mode=“irq”，mode=“nice”，mode=“softirq”，mode=“steal”，mode=“user”，mode=“system”）

（3）范围、偏移、子查询

范围向量：如果要定义一个范围向量选择查询，你必须设置一个及时向量选择器和使用[]追加一个范围。

偏移量的修饰符：offset的修饰符查询过去的数据，也就是说可双选择相对于当前时间的多长时间以前

子查询【道理类似于 MySQL中】

（4）PromQL操作符
向量匹配：有one-to-one、many-to-one、one-to-many【其实就类似于mysql的左右外连接】
（5）PromQL函数
lable_join()和label_replace()这些函数用于操作标签——他们允许您将标签连接到其他标签，提取标签值的一部分，甚至删除标签（尽管使用标准的聚合操作更容易、更符合人体工程学）。在这两个函数中，如果定义的目标标签是一个新的，它将被添加到标签集；如果他是一个现有的标签，它将被取代。【也就是说，如果该语句满足什么条件的话，机会产生相对应的结果】
predict_linear（）函数可以预测时间序列v在t秒后的值，它基于简单线性回归的方式，对时间窗口内的样本数据进行统计，从而可以对时间序列的变化趋势作出预测。该函数的返回结果不带有度量指标，只有标签列表。
rate()和irate()函数：sort()和sort_desc()

10. 计算CPU的使用率

//例子：avg(irate(node_cpu_seconds_total{job="node"}[5m] by (instance) * 100))

11. 计算CPU负载（饱和度）

在主机上获得CPU饱和的一种方法是跟踪平均负载，实际上它是将主机上的CPU数量考虑在内的一段时间内的平均运行队列长度。平均负载少于CPU的数量通常是正常的，长时间内超过该数字的平均值则表示CPU已经饱和。
要查看主机的平均负载，可以使用 node_load * 指标，他们显示1分钟、5分钟和15分钟的平均负载。比如使用1分钟的平均负载：node_load1

//计算主机上的CPU数量，可以使用count聚合实现count by (instance)(node_cpu_seconds_total{mode="idle"})//接下来将此计算与node_load指标结合起来node_load1 > on (instance) 2 * count by (instance)(node_cpu_seconds_total{mode="idle"})//这里我们查询的是1分钟的负载超过主机CPU数量的两倍的结果

12. 计算内存使用率

Node Exporter的内存指标按内存的类型和使用率进行细分。可以在node_memory为前缀的指标列表找到他们。

//查看主机上的总内存node_memory_MemTotal_bytes//主机上的可用内存node_memory_MemFree_bytes//缓冲缓存中的内存node_memory_Buffers_bytes//页面缓存中的内存node_memory_Cached_bytes//通过以上的就可以计算出内存使用率（总内存-可用内存-缓冲缓存中的内存-页面缓冲中的内存）/总内存 * 100

13. 计算内存饱和度

还可以通过检查内存和磁盘的读写来监控内存饱和度，可以使用从 /proc/vmstat 收集的两个 Node Exporter 指标

  • node_vmstat_pswpin：系统每秒从磁盘读到内存的字节数

  • node_vmstat_pswpout：系统每秒从内存写到磁盘的字节数

  • 两者都是自上次启动以来的字节数，以KB为单位

  • 为了获得饱和度指标，对每个指标计算每一分钟的速率，将两个速率相加，然后乘以1024获得字节数
1024 * sum by (instance) ((rate(node_vmstat_pgpgin[1m]) + rate(node_vmstat_pgpgout[1m])))

然后，可以对此设置图形化展示或者警报，以识别行为不当的应用程序主机。

14. 磁盘使用率

对于磁盘，只测量磁盘使用情况而不是使用率、饱和或错误。这是因为在大多数情况下，它是对可视化和警报最有用的数据。

//node_filesystem_size_bytes指标显示了被监控的每个文件系统挂载的大小。node_filesystem_size_bytes

可以使用与内存指标类似的查询来生成在主机上使用的磁盘空间百分比。

(node_filesystem_size_bytes{mountpoint="/"} - node_filesystem_free_bytes{mountpoint="/"}) / node_filesystem_size_bytes{mountpoint="/"} * 100

与内存指标不同，在每个主机上的每个挂载点都有文件系统指标。所以添加了mountpoint标签，特别是跟文件系统”/“挂载。这将在每台主机上返回该文件系统磁盘使用指标。
如果想要或需要监控特定挂载点，那么我们可以为其添加查询。比如要监控/data挂载点，可以使用。

(node_filesystem_size_bytes{mountpoint="/data"} - node_filesystem_free_bytes{mountpoint="/data"}) / node_filesystem_size_bytes{mountpoint="/data"} * 100

或者可以使用正则表达式匹配多个挂载点

(node_filesystem_size_bytes{mountpoint="/|/run"} - node_filesystem_free_bytes{mountpoint="/|/run"}) / node_filesystem_size_bytes{mountpoint="/|/run"} * 100

可以使用 predict_linear 函数来构建在未来什么时候会耗尽磁盘空间

//预测四小时之后磁盘空间会不会爆满predict_linear(node_filesystem_free_bytes{mountpoint="/"}[1h], 4* 3600) < 0

上面是指定跟文件系统，还可以通过制定作业名称或使用正则表达式来选择所有文件系统

predict_linear(node_filesystem_free_bytes{job="node"}[1h], 4* 3600) < 0


我要咨询

关于我们

产品&服务

帮助与支持

招贤纳士

服务热线

130-4243-1809（微信同步）
周一至周五:9:00~17:00