文章目录
- 特殊场景
- 解决方案
- 方案一「 API + Panel 」
- 方案二「 Metric + Table + Display」
- 方案施行流程
- 最终效果
- Q&A
- 附录
目前在企业级监控中,许多公司都用了 Prometheus + Grafana 组件。有些特殊场景需要以 String 类型为主要展示内容,那么你们的解决方案是什么呢?
了解更多,请关注 公众号 “
code 杂坛 “!
特殊场景
- 场景一
在一个业务任务中,通过抢锁的方式确保当前有且仅有一个节点在执行任务,且一但节点故障,其他节点替换执行。
「 锁:基于redisgo的分布式锁https://blog.csdn.net/qq_34417408/article/details/117224113 」
为了能够定位当前执行任务的节点,在锁的 value 中存储了节点 IP 。在进行展示的时候,遇到了问题,Prometheus + Grafana 貌似无法对 String 类型进行展示?
「 此处展示指,以String 类型展示为主,非 x 轴或注释形式。」
了解更多,请关注 公众号 “ code 杂坛 “!
- 场景二:
在对集群监控时,需要突出故障节点所在机房信息,遇到了同样的问题,貌似无法对 String 类型进行展示?
了解更多,请关注 公众号 “ code 杂坛 “!
作为一款云原生时代的实时监控,Prometheus 指标提供了四种基本类型,分别为 Counter、Guage、Histogram、Summary 。
深入了解,会发现这几种都是基于数值进行各种聚合,在 Grafana 联合中,展示面板的 Value 主体也是以数值为主。
那么 Prometheus + Grafana 如何进行 String 类型的展示呢?下面唠下相关解决方案…
解决方案
方案一「 API + Panel 」
通过 API 提供 String 类型数据源,自定义 Panel 的 Json 字段配合 API 结构进行调整,进行展示。
- 但是往往我们不采取这种方案,有一下痛点:
1、API格式有规范,且 Response 需要满足 Grafana Panel 基本准则,需满足 Panel 中基础元素的填充。
2、Panel Json 元素基本填充准则相关文档匮乏
3、调试复杂,改变 Json,观察视图
有另一种更简洁、灵活的方案,甚是便捷,方案如二!
方案二「 Metric + Table + Display」
利用常规的指标设计采集数据,在展示时,Format 选择 Table,数据则自动聚合为 “列 + 行” 的样式,之后可将非必要字段隐藏,主显示目标 String 类型的 Label 即可。
了解更多,请关注 公众号 “ code 杂坛 “!
方案施行流程
-
下面讲解方案二执行流程。分为一下几步:
-
1、设计指标:
fe_task_node{“node”="10.75.26.1|10.75.26.2|10.77.121.3|…”}
-
2、Prometheus Http Api
//HELP fe_task_node XXXXXdesc
//TYPE fe_task_node counter
fe_task_node{node=“10.77.121.108”} 13
-
3、Query配置如图
-
4、Visualization配置如图
-
5、TransForm配置如图
-
6、Field配置如图
最终效果
通过方案二实施之后,效果图如下。
Q&A
1、还有其他更敏捷的解决方案吗?
存在,Prometheus 、 Grafana 国内文档相对比较少,了解的同学可以补充在评论中。
附录
一天一个小技巧,偷偷超越隔壁老大哥!
了解更多,请关注 公众号 “ code 杂坛 “!