![](https://img-blog.csdnimg.cn/b0ee14ee634947f0a0f72016ce68bc5b.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzU5MzU4NjQ4,size_16,color_FFFFFF,t_70#pic_center)
作者｜ 姜聞名
來源｜[爾達 Erda 公眾號](https://mp.weixin.qq.com/s/gBYFVczynmiMoih-fUpEug)

> **導讀**：為了讓大家更好的瞭解 MSP 中 APM 系統的設計實現，我們決定編寫一個《詳聊微服務觀測》系列文章，深入 APM 系統的產品、架構設計和基礎技術。本文為該系列文章的第三篇，將主要對 Telegraf 資料處理鏈路的實現原理以及外掛實現方式進行介紹。

《詳聊微服務觀測》系列文章：

- [《從監控到可觀測性，我們最終要走向哪裡？》](http://mp.weixin.qq.com/s?__biz=Mzg2MDYzNTAxMw==&mid=2247484773&idx=1&sn=1a75c690916d63010a9f559456324b26&chksm=ce222f8ff955a699abc8ebd61ce6faba93401f6a5f9d39cc5eae664b2e57aa2983ccdd63e57a&scene=21#wechat_redirect)
- [《上手後才知道，這套儀表盤系統用起來是真的爽！》](http://mp.weixin.qq.com/s?__biz=Mzg2MDYzNTAxMw==&mid=2247485052&idx=1&sn=af12b930227bb8b0871816d4151c0bd2&chksm=ce222c96f955a5804ce3a9b032e030d4335ecb7ba7b21aa5fdb193e16344e72bd0c7b8725577&scene=21#wechat_redirect)
- 《一文搞懂指標採集利器 Telegraf》（本文）

Telegraf 是 InfluxData 公司開源的一款十分流行的指標採集軟體，在 GiHub 已有上萬 Star。其藉助社群的力量，擁有了多達 200 餘種採集外掛以及 40 餘種匯出外掛，幾乎覆蓋了所有的監控項，例如機器監控、服務監控甚至是硬體監控。

# 架構設計

## Pipeline 併發程式設計

在 Go 中，Pipeline 併發程式設計模式是一種常用的併發程式設計模式。簡單來說，其整體上是由一系列階段（stage），每個 stage 由一組執行著相同函式的 goroutine 組成，且各個 stage 之間由 channel 相互連線。

在每個階段中，goroutine 負責以下事宜：

1. 透過入口 channel，接收上游 stage 產生的資料。
1. 處理資料，例如格式轉換、資料過濾聚合等。
1. 透過出口 channel，傳送處理後的資料到下游 stage。

其中，每個 stage 都同時擁有一個或多個出口、入口 channel，除了第一個和最後一個 stage，其分別只有出口 channel 和入口 channel。

## Telegraf 中的實現

Telegraf 採用了這種程式設計模式，其主要有 4 個 stage，分別為 Inputs、Processors、Aggregators 和 Outputs。

- Inputs：負責採集原始監控指標，包括主動採集和被動採集。
- Processors：負責處理 Inputs 收集的資料，包括去重、重新命名、格式轉換等。
- Aggregators：負責聚合 Processors 處理後的資料，並對聚合後的資料計算。
- Outputs：負責接收處理 Processors 或 Aggregators 輸出的資料，並匯出到其他媒介，例如檔案、資料庫等。

且它們彼此之間也是由 channel 相互連結的，其架構圖如下所示：

![](https://img-blog.csdnimg.cn/d14415e7e9f6464f94eabd1c1967d52d.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzU5MzU4NjQ4,size_16,color_FFFFFF,t_70#pic_center)

可以看到，其整體上採用的就是 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：

![](https://img-blog.csdnimg.cn/b97ad4e8662b4504bb993624b3dc626e.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzU5MzU4NjQ4,size_16,color_FFFFFF,t_70#pic_center)

## 介面實現

在 plugins/inputs/ 目錄中建立外掛，例如 cpu，實現 Input 介面：

![](https://img-blog.csdnimg.cn/40299e2f64314064bc659ccfc54d57fd.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzU5MzU4NjQ4,size_16,color_FFFFFF,t_70#pic_center)

## 註冊外掛

最後，我們只需要往全域性登錄檔中註冊外掛的工廠函式即可：

![](https://img-blog.csdnimg.cn/bf9793dc0d524a1d9864857e09fa1268.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzU5MzU4NjQ4,size_16,color_FFFFFF,t_70#pic_center)

如此，眾多外掛就被有條不紊的管理起來了。同時，擴充套件外掛也很方便，只需實現 Input 介面並註冊工廠函式即可。

# Erda 中的應用

在 Erda 中，我們使用 Telegraf 作為 Erda 平臺的指標採集服務，以守護程式的方式部署在每臺物理機上。現如今，已廣泛應用生產，在上千臺機器上穩定執行，採集並上報大量指標，以供 SRE 及相關運維人員方便地分析與排查。

由於一些特殊的需求，我們不得不基於 Telegraf 進行了二次開發，以便更好的適配業務需求。雖然如此，得益於 Telegraf 強大的外掛系統，我們往往只需要針對需求新增外掛即可。例如，增加 output 外掛以上報到我們自己的收集端，增加 intput 外掛檢查 Erda 自身元件健康度等。

後續，我們將逐漸拋棄二開部分，擁抱開源，最大化地與 Telegraf 官方開源版本保持一致，以回饋社群。

## 參考

- [《Go Concurrency Patterns: Pipelines and cancellation》](https://blog.golang.org/pipelines)
- [Telegraf 專案地址](https://github.com/influxdata/telegraf)
- [《結合專案聊一聊 Go 的工廠模式》](https://zhuanlan.zhihu.com/p/81715661)

**如果你有任何疑問，歡迎新增小助手微信（Erda202106）加入交流群，參與交流和討論！**

- Erda Github 地址：[https://github.com/erda-project/erda](https://github.com/erda-project/erda)
- Erda Cloud 官網：[https://www.erda.cloud/](https://www.erda.cloud/)

一文搞懂指標採集利器 Telegraf

相關文章