打造出色的 Prometheus 监控系统,看完后薪资翻倍?-轻识

一、监控概念&误区

监控是管理基础设施和业务的核心工具，监控应该和应用程序一起构建和部署，没有监控，将无法了解你的系统运行环境，进行故障诊断，也无法阻止提供系统性的性能、成本和状态等信息。

误区：

要尽量避免进行机械式的监控、不够准确的监控、静态和监控、不频繁的监控、缺少自动化或自服务。

二、黑盒监控&白盒监控

1、黑盒监控

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

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

2、白盒监控

系统在被测对象表面显示其内部状态和临界段的性能数据。这种类型的自省可能非常强大，因为它暴露了内部操作，显示不同内部组件的健康状况，否则很难甚至不可能确定。这种数据处理通常以胰腺癌方式进行处理：

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

三、度量指标

度量指标有监控系统执行的过程通常可以分为两种方式：push（监控系统去服务进行拉取）、pull（被监控的服务自动往监控系统进行推送）【站在客户的角度】

Push VS Pull
测量什么：

谷歌提出应该监控的四个指标：

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

Brendan 的方法更关注于及其他声明对于每个资源（CPU、磁盘、网络接口等等），应该监视以下指标：

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

汤姆威尔基的红色方法：更侧重于服务级别方法，而不是底层系统本身。显然，这种才领略对于见识服务很有用，对于预测外部客户的体验也很有价值。如果服务的错误率增加，那么就可以合理地假设这些错误将直接或间接地影响客户的体验。

速率：转换成每秒请求数
错误：每秒失败请求的数量
持久性：这些请求所花费的时间

四、Prometheus

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

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