打造出色的 Prometheus 监控系统，看完后薪资翻倍？

一、监控概念&误区

• 误区：

二、黑盒监控&白盒监控

1、黑盒监控

• 应用程序或主机是从外部观察的，因此，这种方法可能相当有限。检查是为了评估被观察的系统是否以已知的方式响应探测。

• 例子：

1）主机是否相应PING的请求
2）特定的TCP端口是否打开
3）应用程序在接受到特定的HTTP请求时，是否使用正确的数据和状态代码进行响应
4）特定应用程序的进程是否在其主机中运行

2、白盒监控

1）通过日志导出：到目前为止。这是也是在广泛引入库之前，应用程序是如何暴露其内部工作的最常见的情况，例如：可以处理 HTTP 服务器的访问日志来监视请求率、延迟和错误百分比；
2）以结构化的事件输出：这种方法类似于日志记录，但不是将数据写入磁盘，而是直接将数据发送到处理系统进行分析和聚合。
3）以聚合的方式保存在内存中：这种格式的数据可以驻留在端点中，也可以直接从命令行工具中读取。这种方法的例子有/metrics with Prometheus metrics、HAProxy 的 stats 页面或 varnishstats 命令行工具

三、度量指标

• Push VS Pull
• 测量什么：

• 延迟：服务请求所需的时间
• 流量：正在发出的请求的数量
• 错误：求失败的比率
• 饱和：未处理的工作量，通常在队列中

• 利用率：以资源繁忙的百分比来衡量
• 饱和：资源无法处理的工作量，通常会排队
• 错误：发生的错误数量

• 速率：转换成每秒请求数

• 错误：每秒失败请求的数量

• 持久性：这些请求所花费的时间

四、Prometheus

1、介绍&架构

2. 合适&不合适场景

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

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

3. 数据模型

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

• 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

原文链接：https://blog.csdn.net/weixin_44827241/article/details/123902001

还不过瘾？还想了解更多企业级运维落地指南？GOPS 全球运维大会 2024 · 深圳站了解一下，点击下方小程序，更多精彩 ⏬



近期好文：
运维必会！10个超级实用 Shell 脚本，看完不踩坑？
“高效运维”公众号诚邀广大技术人员投稿
投稿邮箱：jiachen@greatops.net，或添加联系人微信：greatops1118。


















点个“在看”，一年不宕机