核心内容摘要
汤叔十八岁，人生新篇章的十八般“武艺”_1
PrometheusGrafana构建云原生分布式监控系统十四_Prometheus中PromQL使用(
https://blog.csdn.net/xiaochenXIHUA/article/details/157615417
集合操作与排序
1.
集合运算prometheus支持的集合运算有时候需要过滤或将一组时间序列与另一组时间序列进行合并Prometheus 提供了 3 个在瞬时向量之间操作的集合运算符。
序号集合运算符说明1交集and如对较高错误率触发报警但是只有当对应的总错误率超过某个阈值的时候才会触发报警2并集or对序列进行并集计算3除非unless如要对磁盘空间不足进行告警除非它是只读文件系统与算术和过滤二元运算符类似这些集合运算符会尝试根据相同的标签集在左侧和右侧之间查找来匹配序列除非你提供on()或ignoring()修饰符来指定应该如何找到匹配。
#集合运算示例 #示例1-【or】列出所有低于 10 或者高于 50 的请求率 rate(prometheus_http_request_duration_seconds_count[5m])10 or rate(prometheus_http_request_duration_seconds_count[5m])50 #示例2-【and】关于磁盘的使用率有的磁盘分区很大比如 10T有的分区很小比如 100G像这种情况如果只是用磁盘的使用率做告警就不太合理比如 disk_used_percent{jobdockerserver} 70 表示磁盘使用率大于 70% 就告警。
对于小盘这个策略是合理的但对于大盘70% 的使用率表示还有非常多的空间就不太合理。
这时我们希望给这个策略加一个限制只有小于 200G 的硬盘在使用率超过 70% 的时候才需要告警这时我们就可以使用 and 运算符 ((node_filesystem_size_bytes{fstype~xfs|ext4}-node_filesystem_avail_bytes{fstype~xfs|ext4})/node_filesystem_size_bytes{fstype~xfs|ext4})
7 and on(addr,app,device,fstype,instance,job,mountpoint) node_filesystem_size_bytes{fstype~xfs|ext4}/1024^3100 (node_filesystem_avail_bytes{fstype~xfs|ext4}/node_filesystem_size_bytes{fstype~xfs|ext4})
3 and on(addr,app,device,fstype,instance,job,mountpoint) node_filesystem_size_bytes{fstype~xfs|ext4}/1024/1024/
10241001.
对查询结果进行排序可以使用【sort()升序】或者【sort_desc()降序】函数来实现对输出结果进行排序。
有时候只对最大或最小的几个序列感兴趣可以使用【topk()】和【bottomk()】这两个运算符来操作可以返回K个最大或最小的序列。
#对查询结果进行排序示例 #1-示例1-按值对系统可用空间按照从大到小排序 sort_desc(node_filesystem_avail_bytes) sort_desc(node_filesystem_avail_bytes{fstype~xfs|ext4}) #2-示例2-按值显示最大的前三个内容 topk(3,node_filesystem_avail_bytes) topk(3,node_filesystem_avail_bytes{fstype~xfs|ext4})
直方图prometheus 中的直方图指标用来记录某个服务一系列数值的分布。
直方图通常用于跟踪请求的延迟或响应大小等指标值。
直方图是如何记录数值分布的?比如有个web api接口服务监控到的样本的响应时间范围为 200ms~3s大致的分布区间是大部分接口延迟最小在一两百毫秒最大的通常在 1 秒如果超过 3 秒就意味着系统不正常了。
直方图的做法是根据数据的范围规划多个桶bucket把样本数据点放入不同的桶来统计。
根据web api接口服务的情况可以规划 4 个桶假设有 1000 个请求来看下各个桶和对应的样本统计值情况如下《1》延迟小于 200 毫秒的有 600 个请求落到了这个区间。
《2》延迟小于 1 秒的有 850 个请求落到了这个区间其中大于 200 毫秒的有 250 个请求。
《3》延迟小于 3 秒的有 1000 个请求落到了这个区间其中大于 1 秒的有 150 个请求。
《4》延迟小于正无穷的也就是总量有 1000 个请求落到了这个区间说明没有大于 3 秒的请求。
现在来计算 90 分位值也就是第 900 个请求说明这个值落到了第 3 个桶延迟小于 3 秒的桶于是我们可以得出结论90 分位的延迟大小是 1~3 秒之间。
虽然知道了区间范围但是还无法得出具体的值。
为了计算出具体的值prometheus 有个假设它认为各个桶里的样本数据是均匀分布的即第三个桶的这 150 个请求延迟最小的请求恰好延迟了 1 秒延迟最大的恰好延迟了 3 秒总量的第 900 个请求是这个桶里的第 50 个请求最终 90 分位的延迟数据计算方法是3−1×50÷
1
67秒。
这就是 histogram_quantile函数的计算方法。
【histogram_quantile】是 Prometheus 的一个函数。
用来计算分位数而且是一个预估值并不完全准确因为这个函数是假定每个区间内的样本分布是线性分布来计算结果值的。
预估的准确度取决于 bucket 区间划分的粒度粒度越大准确度越低。
在 prometheus 内部直方图被实现为一组时间序列每个序列代表指定桶的计数例如10ms以下的请求数、25ms以下的请求数、50ms以下的请求数等。
在 prometheus 中每个 bucket 桶的计数器是累加的这意味着较大值的桶也包括所有低数值的桶的计数。
在作为直方图一部分的每个时间序列上相应的桶由特殊的le标签表示。
le代表的是小于或等于。
prometheus_http_request_duration_seconds_bucket{handler/metrics}直方图可以帮助我们了解这样的问题如我有多少个请求超过了100ms的时间(当然需要直方图中配置了一个以 100ms 为边界的桶)又比如我99%的请求是在多少延迟下完成的这类数值被称为百分位数或分位数。
在 prometheus 中这两个术语几乎是可以通用只是百分位数指定在
范围内而分位数表示在 0 和 1 之间所以第 99 个百分位数相当于分位数
99。
#直方图示例 #示例计算过去5分钟内第90个百分位数的API延迟 histogram_quantile(
9,rate(prometheus_http_request_duration_seconds_bucket{handler/metrics}[5m]))
实例状态监测
3.
检查实例抓取状态每当 prometheus 抓取一个目标时它都会存储一个合成的样本其中包含指标名称up和被抓取实例的job和instance标签如果抓取成功则样本的值被设置为 1如果抓取失败则设置为 0因此可以通过下面的查询来获取当前哪些实例处于正常或挂掉的状态#检查实例抓取状态示例 #1-示例1获取所有掉线的实例 up0 #2-示例2获取挂掉实例的总数 sum by(instance)(up
0)
3.
检查序列数据在某些情况下只查看实例的状态是不够的有时还需要检测是否存在某些序列上面我们用【up 0】语句来查询所有无法抓取的实例服务但是只有已经被抓取过的目标才会被加上up指标如果 Prometheus 都没有抓取到任何的实例服务目标应该怎么办呢【此时absent()函数就非常有用了absent()将一个瞬时向量作为其输入当输入一个已存在的序列时将返回一个空结果不存在时将返回单个输出序列而且样本值为1】。
此外还有一个 函数【absent_over_time()】它接受一个区间向量告诉我们在该输入向量的指定时间范围内是否有样本当输入一个已存在的序列时将返回一个空结果不存在时将返回单个输出序列而且样本值为1。
#检查序列数据示例 #示例1-检查指定指标存在且掉线 up{jobnode_service_discovery}0 absent(up{jobnode_service_discovery}