关于程序员:一文搞懂指标采集利器-Telegraf

52次阅读

共计 2600 个字符,预计需要花费 7 分钟才能阅读完成。


作者| 姜闻名
起源|尔达 Erda 公众号

导读:为了让大家更好的理解 MSP 中 APM 零碎的设计实现,咱们决定编写一个《详聊微服务观测》系列文章,深刻 APM 零碎的产品、架构设计和根底技术。本文为该系列文章的第三篇,将次要对 Telegraf 数据处理链路的实现原理以及插件实现形式进行介绍。

《详聊微服务观测》系列文章:

  • 《从监控到可观测性,咱们最终要走向哪里?》
  • 《上手后才晓得,这套仪表盘零碎用起来是真的爽!》
  • 《一文搞懂指标采集利器 Telegraf》(本文)

Telegraf 是 InfluxData 公司开源的一款非常风行的指标采集软件,在 GiHub 已有上万 Star。其借助社区的力量,领有了多达 200 余种采集插件以及 40 余种导出插件,简直笼罩了所有的监控项,例如机器监控、服务监控甚至是硬件监控。

架构设计

Pipeline 并发编程


在 Go 中,Pipeline 并发编程模式是一种罕用的并发编程模式。简略来说,其整体上是由一系列阶段(stage),每个 stage 由一组运行着雷同函数的 goroutine 组成,且各个 stage 之间由 channel 相互连接。

在每个阶段中,goroutine 负责以下事宜:

  1. 通过入口 channel,接管上游 stage 产生的数据。
  2. 解决数据,例如格局转换、数据过滤聚合等。
  3. 通过进口 channel,发送解决后的数据到上游 stage。

其中,每个 stage 都同时领有一个或多个进口、入口 channel,除了第一个和最初一个 stage,其别离只有进口 channel 和入口 channel。

Telegraf 中的实现


Telegraf 采纳了这种编程模式,其次要有 4 个 stage,别离为 Inputs、Processors、Aggregators 和 Outputs。

  • Inputs:负责采集原始监控指标,包含被动采集和被动采集。
  • Processors:负责解决 Inputs 收集的数据,包含去重、重命名、格局转换等。
  • Aggregators:负责聚合 Processors 解决后的数据,并对聚合后的数据计算。
  • Outputs:负责接管解决 Processors 或 Aggregators 输入的数据,并导出到其余媒介,例如文件、数据库等。

且它们彼此之间也是由 channel 互相链接的,其架构图如下所示:

能够看到,其整体上采纳的就是 pipeline 并发编程模式,咱们简略介绍下它的运作机制:

  • 第一个 stage 为 Inputs,每个 input 生成一个 goroutine,各自采集数据并扇入(fan-in)到 channel 中。
  • 第二个 stage 为 Processors,每个 processor 生成一个 goroutine,并按程序彼此用 channel 连贯。
  • 第三个 stage 为 Aggregators,每个 aggregator 生成一个 goroutine,并生产 Processors 产生的数据,并扇出(fan-out)到各个 aggregator。
  • 最初一个 stage 为 Outputs,每个 output 生成一个 goroutine,并生产由 Processors 或 Aggregators 产生的数据,并扇出到各个 output。

扇入(fan-in):多个函数输入数据到一个 channel,并由某个函数读取该 channel 直到其被敞开。

扇出(fan-out):多个函数读取同一个 channel 直到其被敞开。

插件设计


Telegraf 领有如此泛滥的 input、output 以及 processor 插件,那么它是如何高效地治理这些插件呢?并且又是如何设计插件体系以应答一直激增的扩大需要呢?别急,请容我细说。

其实,这里的插件并非通常意义上的插件(即在运行时动静加载与绑定动态链接库),而是一种基于工厂模式的变体,首先咱们来看下 Telegraf 的插件目录构造:

plugins
├── aggregators
│   ├── all
│   ├── basicstats
│   ├── registry.go
...
├── inputs
│   ├── all
│   ├── cpu
│   ├── registry.go
...
├── outputs
│   ├── all
│   ├── amqp
│   ├── registry.go
...
├── processors
│   ├── all
│   ├── clone
│   ├── registry.go
...


由上能够看到,目录构造是有法则的(以下咱们均以 Inputs 的插件为例,其余模块实现相似)。

  • plugins/inputs:为各个 input 插件的包目录。
  • plugins/inputs/all:通过 import 的形式引入插件模块包(次要是为了防止循环援用)。
  • plugins/inputs/registry.go:寄存注册表以及相干函数。

接口申明


Telegraf 通过 interface 来申明如下 Input 接口,示意 Input:

接口实现


在 plugins/inputs/ 目录中创立插件,例如 cpu,实现 Input 接口:

注册插件


最初,咱们只须要往全局注册表中注册插件的工厂函数即可:

如此,泛滥插件就被井井有条的治理起来了。同时,扩大插件也很不便,只需实现 Input 接口并注册工厂函数即可。

Erda 中的利用


在 Erda 中,咱们应用 Telegraf 作为 Erda 平台的指标采集服务,以守护过程的形式部署在每台物理机上。现如今,已广泛应用生产,在上千台机器上稳固运行,采集并上报大量指标,以供 SRE 及相干运维人员不便地剖析与排查。

因为一些非凡的需要,咱们不得不基于 Telegraf 进行了二次开发,以便更好的适配业务需要。尽管如此,得益于 Telegraf 弱小的插件零碎,咱们往往只须要针对需要新增插件即可。例如,减少 output 插件以上报到咱们本人的收集端,减少 intput 插件查看 Erda 本身组件衰弱度等。

后续,咱们将逐步摈弃二开局部,拥抱开源,最大化地与 Telegraf 官网开源版本保持一致,以回馈社区。

参考

  • 《Go Concurrency Patterns: Pipelines and cancellation》​
  • Telegraf 我的项目地址​
  • 《联合我的项目聊一聊 Go 的工厂模式》​

如果你有任何疑难,欢送增加小助手微信(Erda202106)退出交换群,参加交换和探讨!

  • Erda Github 地址:https://github.com/erda-project/erda
  • Erda Cloud 官网:https://www.erda.cloud/

正文完
 0