go实现重新给metric打标签上传到prometheus_案例分析｜云原生监控Prometheus对样本rate计算，出现标签重复？...

0 - 本案例所涉及的知识点

云原生、微服务&＃xff0c;带你了解大规模容器下的监控方式&＃xff0c;通过各个案例分析&＃xff0c;熟悉prometheus的内部原理。

涉及知识点&＃xff1a;go prometheus

1 - 案例概要

收到用户反馈&＃xff0c;使用grafana通过设置prometheus数据源&＃xff0c;绘制容器的网络指标时&＃xff0c;出现异常&＃xff0c;guan j z

2 - 故障重现

服务端prometheus版本为2.9.2&＃xff0c;通过访问内置UI地址 prometheus-server:9090&＃xff0c;查询数据重现故障&＃xff0c;错误截图如下&＃xff0c;

通过浏览器开发者模式&＃xff0c;获取当前具体的请求接口可表示为&＃xff1a;

响应的HTTP状态码422 Unprocessable Entity&＃xff0c;错误信息&＃xff1a;

3 - 初步假设

看字面意思是查询返回的样本结果集合中存在相同的标签&＃xff0c;至于是什么标签相同&＃xff0c;只能通过查询源码定位问题了。

4 - 理论知识

4.1 - Prometheus基础数据结构

首先熟悉Prometheus几个基础数据结构

Sample与Series的区别&＃xff1a;

• Sample是样本&＃xff1a;一个标签组合&＃xff0c;只包含一个时间点以及该点的时间数据
• Series是序列&＃xff1a;一个标签组合&＃xff0c;由多个时间点以及对应的数据组合而成

Vector与Matrix的区别&＃xff1a;

• Vector是一个向量数据结构&＃xff0c;由多个样本组成&＃xff0c;这些样本以时间为方向&＃xff0c;具有相同的方向
• Matrix是一个矩阵数据结构&＃xff0c;由多个序列数据组成

4.2 - 通过关键字匹配定位源码

• 异常关键字出现的代码位置

源码文件&＃xff1a;github.com/prometheus/prometheus/promql/engine.go

• 关键函数result.ContainsSameLabelset的实现源码

该函数主要用于检测在查询返回的数据中&＃xff0c;是否存在相同的标签集合&＃xff0c;由于向量与矩阵标签类型相同&＃xff0c;所以实际它们内部的实现也是一样的。

源码文件&＃xff1a;github.com/prometheus/prometheus/promql/value.go

• 判断样本标签组唯一性&＃xff0c;函数s.Metric.Hash()的实现

源码文件&＃xff1a;github.com/prometheus/prometheus/pkg/labels/labels.go

也就是在这计算中Vector(向量)或Matrix(矩阵)&＃xff0c;不能存在相同的Labels(标签组)。

5 - 疑点提出

1. Prometheus的持久存储方案是内部开发团队自实现的&＃xff0c;是这个引起的&＃xff1f;
2. Prometheus本地存储设置只保留最近24h的数据&＃xff0c;难道是这部分数据异常&＃xff1f;
3. 分别关闭本地与远程存储&＃xff0c;如果均正常&＃xff0c;难道是查询返回了相同的两条指标&＃xff1f;
4. 向量与矩阵里面的样本或序列数据是不能存在相同的标签组合&＃xff1f;

6 - 实践检验

6.1 - 实验前准备

下载源码&＃xff0c;通过以下命令可编译二进制可执行文件

cd github.com/prometheus/prometheusgo build cmd/prometheus/main.go

6.2 - 验证疑点1

由于prometheus本身不适合做长久数据存储&＃xff0c;所以我们内部设计了一套持久存储的方案&＃xff0c;结合配置remote_read、remote_write实现。

为了验证疑点1&＃xff0c;可以先把prometheus.yml中的remote_read设置关闭&＃xff0c;然后重载prometheus配置。

通过停止remote_read设置之后就可以正常使用了&＃xff0c;但这里也并不能确定就是设置remote_read的问题。

6.2 - 验证疑点2

通过关闭远程数据读取可以解决问题&＃xff0c;那通过删除本地数据呢&＃xff1f;通过以下步骤&＃xff1a;

1. 设置prometheus.yml取消原先对remote_read的注释。
2. 关闭prometehus进程&＃xff0c;清除本地存储目录下的所有数据&＃xff0c;实际由storage.tsdb.path设置&＃xff0c;如&＃xff1a;data/*
3. 重新启动prometheus进程。

在刚启动时候&＃xff0c;可以正常查询出数据&＃xff1a;

等待一会后&＃xff0c;出现同样问题&＃xff1a;

6.3 - 验证疑点3

在同时开启本地与远程数据存储的情况下&＃xff0c;通过promQL查询以下语句&＃xff1a;

container_network_receive_bytes_total{pod_name&＃61;"magick-img-converter-747d899b66-lsrn6"}[1m]

接口返回内容&＃xff1a;

确实是访问两个相同标签组的数据&＃xff0c;但是时间不同。

对这结果集使用rate函数计算&＃xff0c;也就出现了原先的问题。

rate(container_network_receive_bytes_total{pod_name&＃61;"magick-img-converter-747d899b66-lsrn6"}[1m])

6.4 - 验证疑点4

相同的标签组合是指&＃xff1a;一组同样的标签名与标签值。这里通过更改prometheus代码&＃xff0c;植入测试语句&＃xff0c;获取从远程或本地的数据&＃xff0c;对比差异&＃xff0c;查询到底哪里导致这个问题的产生。

由以上几个疑点验证可知&＃xff0c;问题出现在eval函数的case *Call语句中。

通过对以上函数添加调试代码&＃xff0c;然后编译promethues运行&＃xff0c;在执行相应的promQL查询。

这里可以看到&＃xff0c;存在两个数据&＃xff0c;在未移除标签__name__之前&＃xff0c;上图存在两个__name__&＃xff0c;下图只有一个__name__&＃xff0c;当移除之后&＃xff0c;他们就存在相同的标签组了。

7 - 问题定位

查询指标数据时&＃xff0c;prometheus分别从本地存储与远程存储获取数据&＃xff0c;然后进行合并&＃xff0c;远程存储获取的数据相比本地多了一个__name__标签。

8 - 解决方案

8.1 - 方案1

修复远程存储返回多余的__name__标签。

8.2 - 方案2

修改prometheus代码&＃xff0c;如果存在重复的__name__标签键值&＃xff0c;则想办法去重。

9 - 总结讨论

通过方案1&＃xff0c;我们就解决了这个问题&＃xff0c;同时也继续跟踪prometheus源码&＃xff0c;能否为它提交PR&＃xff0c;增强健壮性。

如存在疑问点&＃xff0c;欢迎留言讨论&＃xff0c;本人关注云原生生态&＃xff0c;如果您也喜欢&＃xff0c;欢迎关注我&＃xff0c;一起学习&＃xff0c;共同进步。