
前提已经搭建好promehtes和granfana,实践过程:grafana接入prometheus数据源和一些简单的prometheus语法
本文档为个人学习笔记,所有配置、命令、指标名称均为测试用途
从主页将鼠标放到小 ⚙️ 上,点击「数据源」

点击 Add data source 进入数据源配置页面

在数据源列表中选择:Prometheus

http://192.168.1.139:8001


功能 | 说明 |
|---|---|
Dashboard | 直接创建一个新的空白仪表盘 |
Folder | 类似创建目录,可以区分项目和业务类型创建 |
Imports | 支持从模板或 JSON 文件导入已有仪表盘 |




这个是后端自定义的埋点, 指标名称是自定义的:counter_Htest_exception_total,代表请求异常总数(Counter 类型)counter_Htest_total:代表请求总数(Counter 类型)rate()rate(counter_Htest_exception_total[1m]) / rate(counter_Htest_total[1m])offset 手动差值(counter_Htest_exception_total - counter_Htest_exception_total offset 1m) / (counter_Htest_total - counter_Htest_total offset 1m)只有当服务有真实流量且错误率显著偏高时,才发出告警, 里面用到了rate和运算符还有and
rate(counter_Htest_total[5m]) * 60 > 5
and
rate(counter_Htest_exception_total[5m])/rate(counter_Htest_total[5m]) > 0.2验证告警规则格式是否正确可以用promtool 如:
将告警规则添加到zidingyi.rules
[root@test rules]# ../promtool check rules zidingyi.rules
Checking zidingyi.rules
SUCCESS: 12 rules found
语法解析:
过去 5 分钟平均每分钟请求数 > 5一开始只用了错误率作为告警条件,结果发现测试环境下经常误报——有时候就一两个请求失败,错误率就飙到100%,但上去看日志、手动测接口都是正常的。后来加上了“请求总量达到一定阈值”的前置条件,避免了低流量下的无效告警。这个做法仅供参考,具体阈值和逻辑还需要根据实际业务特征来调整
数据聚合sum 是 PromQL 的聚合操作符sum(rate(counter_Htest_total[1m])) by (job)按
job分组,统计每个服务的总 QPS job是收集指标的一个标签
round(counter_Htest_exception_total/counter_Htest_total*100)

5)获取某段时间范围内的数据
指标名称{job="test“}[5m]指标名称{job=~"test$"}📌 说明:
=~ 表示正则匹配job 标签以 test结尾的实例
注:正则匹配需确保标签存在(否则返回空)7)总结
metric_name(指标名称)8)、 语法调试建议
添加自定义模版时,先在prometheus上调试语法,调试好了复制到granfana,这样调试更加方便一些
1、查询规则比较复杂时(如聚合、标签过滤,计算等),可分步调试如:
metric_name-->metric_name{label="value"}-->sum(metric_name{label="value"})
2、使用promtool检查告警规则语法(promtool check rules zidingyi.rules),确保规则格式正确
欢迎留言分享你的运维小技巧!
⚠️ 注:内容为个人经验总结与技术分享,仅供参考!