若谷学院
互联网公司技术架构分享

prometheus 落地实践 — 内部监控系统wonder改造(一)

初衷

前面曾经简单介绍过prometheus在web平台初期的落地实践.经过一段时间的使用,随着期望接入的业务越来越多,业务的应用场景也随之变得复杂.大多轻量级的业务可以配合进行代码内部打点改造,但是大部分业务代码内部复杂度较高,侵入式的打点改造成本也十分高.因此在现有监控系统上进行改造,让业务也最小的成本享受到prometheus的特性也变的更急迫.

当前web平台部正在使用的是基于open-falcon进行二次开发的wonder监控系统,目前已接入web平台部4w台服务器,日后会逐步接入全公司服务器达10w台以上.在日常系统级的基础监控方面扮演着十分重要的角色,hulk平台的大部分用户也对wonder监控平台使用也十分熟悉.
因此我们决定由wonder入手,进行改造,方便用户无痛接入prometheus.

初期改造

改造前 wonder 架构如图:

alt

在wonder的架构中,agent 上报的所有数据都会流经transfer组件再分发到其他组件.所以我们可以从transfer入手,尝试将发送到wonder中的所有数据实时的拉取到prometheus.

从上一篇落地实践的文章中不难发现prometheus在pull模型之外同时也是支持push模型的,但是push操作并不是直接push到prometheus,而是通过push到gateway这个组件,再由prometheus通过pull模型从gateway拉取到本地.在我们进行改造的过程中便是在wonder transfer中引入prometheus gateway的功能.

改造方法

改造方法简单说就是在transfer内部实现一个metric exporter.

  1. 将wonder metric转译为prometheus metric,tags转译为metric label.
  2. 对相同metric进行分组,并对每组相同metric内不同label value的metric生成唯一标识,每次相同metric{label/value}的数据都写入对应唯一标识的metric.
  3. 并使用prometheus.NewConstMetric方法生成metric,减少相同metric不同label数量导致的metric注册失败问题.
  4. 同时针对每个metric添加一个过期时间,每次采集操作遍历所有内存数据前,将过期数据丢弃,减少对超时时间内未上报数据的metric产生的干扰.
  5. 另外需要注意prometheus对metirc及label的命名有一定要求,需要主动消除特殊字符.
  6. 将上述内容在collect接口中实现并注册到内部prometheus客户端中,并在在wonder原生http服务上注册prometheus的http.handler并路由到/metrics即可.

改造后的局部结构如图:

alt

这样用户实时上报的数据也会同时采集到prometheus中.

报警

数据有了,那么如何报警呢?
我们针对报警需求添加了三个组件

  • global server
  • remote adaper
  • rule adapter

分别用于数据汇聚,数据向后端发送及各类规则生成.

他们各自在接入wonder后针对报警的作用及实现方式将在下一篇文章中进行介绍.

原文出自:https://www.opsdev.cn/archives/

好烂呀没啥价值凑合看看还不错很精彩 (还没有人评分)
Loading...
本站文章来自互联网一线技术博客,若有侵权,请联系我们:若谷技术学院 » prometheus 落地实践 — 内部监控系统wonder改造(一)
关注若谷技术,获得个性化即时架构文章推送

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址

全球互联网技术架构,前沿架构参考

联系我们博客/网站内容提交