Telegraf の導入と使用 (インストール、使用、内部データ構造 - InfluxDB 行プロトコル、構成、アーキテクチャ、Glob の使用、プラグインの統合と実装、Prometheus の収集)

導入

Telegraf は、プラグインベースのオープンソース指標収集ツールです。InfluxDB (時系列データベース) に合わせて作られたデータコレクターですが、非常に優れており、特に時系列データベースの分野で、キャプチャしたデータをさまざまな場所に書き込むことができ、多くの時系列データベースを使用できます。 。通常、時折インジケーター データのバッチ (マシンの CPU 使用率、ディスク IO、ネットワーク状態、MySQL サーバー上のセッション数など) を取得し、時系列データベース、メッセージに送信します。キュー、または自動的に定義がどこかにエクスポートされます。ダウンストリームのアプリケーション処理 (アラームなど)。Telegraf は外部にサービスを提供し、クライアントがデータをプッシュするのを待つこともできます。

logstash はログを収集することを除いて、logstash に似ています。telegraf はメトリクスを収集します。

公式では 300 以上のオプション プラグインが提供されており、さらに Telegraf は拡張が容易で、公式プラグインではニーズを満たせない場合には、いつでも Telegraf をベースにして独自のプラグインを作成できます。

Telegraf のインストールと展開

ダウンロード ページにアクセスしてください: https://portal.influxdata.com/downloads/

右側のプラットフォームが対応するシステムです。お使いのプラットフォームに対応するものを選択すると、ダウンロード URL が自動的に変わります。

ここでは yum ファイルを作成する必要があります。ページに示されているコマンドに問題があります。次のように変更する必要があります。赤い部分が修正です。

cat <<EOF | sudo tee /etc/yum.repos.d/influxdata.repo
[influxdata]
name = InfluxData Repository - Stable
baseurl = https://repos.influxdata.com/stable/\$basearch/main
enabled = 1
gpgcheck = 1
gpgkey = https://repos.influxdata.com/influxdb.key
EOF

このコードを実行すると、influxdata.repo ファイルが /etc/yum.repose.d/ ディレクトリに表示されます。内部のコンテンツはコードの中間部分です。

次に、yum を使用してオンラインでインストールします。

sudo yum install telegraf

systemctl を使用して、telegraf が正常にインストールされているかどうかを確認します。

systemctl status telegraf

使用

例 1: 単一入力単一出力ワークフロー

(1) Telegraf設定ファイルの書き込み

telegraf の設定ファイル専用のディレクトリを作成します。

mkdir /opt/module/telegraf_conf

設定ファイルexample01.confを作成します。

vim example01.conf

そして次のように入力します。

[agent]
  interval = "3s"

[[inputs.cpu]]
  percpu = true
  totalcpu = true
  collect_cpu_time = false
  report_active = false
  core_tags = false

[[outputs.file]]
  files = ["stdout"]

example01.conf 構成ファイルには 3 つの構成ブロックが含まれています。

• [エージェント] 以下にグローバル構成をいくつか示します。ここでは、interval="3s" を設定します。これは、構成ファイル内のすべての入力プラグインが 3 秒ごとにインジケーターを収集することを意味します。間隔のデフォルト値は 10 秒です。
• [[ inputs.cpu ]] これは入力コンポーネントです。ここでの構成は、エクスポートするインジケーターに各 CPU コアの使用量と、すべての CPU の合計使用量も含まれることを意味します。
• [[ Outputs.file ]] これは出力コンポーネントです。ここでは file という名前の出力コンポーネントを使用しますが、files パラメーターは stdout (標準出力)、つまりコンソールに設定されているため、プログラムが実行されており、データがコンソールに表示されます。

(2) Telegraf プログラムを実行する

次のコマンドを使用して telegraf を起動し、コンソールで状況を観察します。s

telegraf --config ./example01.conf

図に示すように、次の出力がコンソールに表示されます。

コンソール出力内容:

(1)プロセス設定とプラグインロード情報

まず、コンソールは、Telegraf プロセスの 1 つの説明情報を含むログ コンテンツを出力します。

1. Telegraf の現在のバージョン番号は 1.23.2 です。

2. ロードされている入力プラグインのリスト (現在 1 つ): cpu

3. ロードされたアグリゲーター プラグインのリスト (現在は何もありません)

4. ロードされているプロセッサ プラグインのリスト (現在は何もありません)

5. ロードされた出力プラグインのリスト (現在 1 つ): ファイル

6. タグが有効になり、グローバル タグ セットが有効になり、グローバル インジケーター データがタグ host=hadoop102 で追加されます。

7. エージェント構成、グローバル構成

   1. 間隔: 3 秒、すべての入力コンポーネントは 3 秒ごとにインジケーター データを収集します。

   2. Quiet: false、Quiet モードで実行しません。

   3. ホスト名: 「hadoop102」、マシン名 hadoop102

   4. フラッシュ間隔: 10 秒 すべての出力コンポーネントは 10 秒ごとにインジケーター データを出力します。したがって、telegraf の実行後は、10 秒ごとにコンソールに出力のバッチが表示されるはずです。

(2)データ出力

Telegraf 構成コンテンツが出力されると、大量の高密度データが表示されます。これは json のようにも csv のようにも見えないことがわかります。これは実際には、InfluxDB 行プロトコルと呼ばれる Telegraf の組み込みデータ構造です。このデータ構造については、後で具体的に説明する。

例 2: 処理プラグインを有効にする

ここでは、より複雑な例を使用して、Telegraf でプロセッサ プラグインを使用する方法を学習します。

(1) Telegraf設定ファイルの書き込み

次に、example01.conf をベースに若干の改良を加え、新しい設定ファイル example02.conf を作成します。

cp example01.conf example02.conf
vim example02.conf

次のコンテンツを入力します (赤い部分は example01.conf に関連する新しいコンテンツです)

[agent]
  interval = "3s"
  flush_interval = "5s"

[global_tags]
  user="atguigu"

[[inputs.cpu]]
  percpu = true
  totalcpu = true
  collect_cpu_time = false
  report_active = false
  core_tags = false

[[processors.converter]]
  [processors.converter.tags]
    measurement = ["cpu"]

[[outputs.file]]
  files = ["stdout"]

(2) Telegraf プログラムを実行する

次のコマンドを実行して、構成ファイル example02.conf を使用して telegraf プロセスを開始します。

telegraf --conf ./example02.conf

コンソールは正常に出力され、すべてが正常であることを示します。

(3) 例1の出力との違い

1)ロードされているプラ​​グインが異なります

コンソール上で telegraf を 2 回実行して出力されたヘッダー情報を比較します。example02.conf ファイルにより、telegraf プログラムが追加のコンバータ プラグインをロードできることがわかります。

2) データの出力が変更されました

現時点では、Telegraf の内部データ形式については説明していません。ただし、今のところは 2 つの例の出力データのヘッダーにだけ注目してください。

以下に示すように:

データのヘッダーは 2 つの部分で構成されます。

• 測定（測定名）。ここでは、CPU 入力プラグインを使用して CPU 使用率を測定するため、測定の名前は cpu と呼ぶのが適切です。
• タグ（タグセット）。telegraf は InfluxData によって InfluxDB 用に開発されたインジケーター収集コンポーネントであるため、ここでのタグは実際には InfluxDB によるインデックス付けの便宜のためのものです。インデックスの詳細については後述します。

上の図のデータを比較すると、プロセッサ プラグインを追加した後にデータの形式が変更されたことがわかります。元のラベル セットの内容は、測定値 (メトリック名) を置き換えるために使用されました。これは、データを操作、変換、処理するプロセッサ プラグインの機能も反映しています。

例 3: Remote Config (http.server) の使用

Telegraf の -cofnig パラメータで URL を指定すると、telegraf がネットワーク経由で構成ファイルをリモートで取得できるようになります。

(1) Python 独自の http.server を使用して静的ファイル サービスを迅速に構築する

cd で構成ファイル /opt/module/telegraf_conf を配置したディレクトリに移動し、次のコマンドを使用して静的ファイル サービスをすぐに開始します。

python3 -m http.server

デフォルトでは、ポート 8000 でリッスンし、外部アクセスを許可します。

(2) Telegraf を実行する

次に、このサービスを使用して構成ファイルを取得してみます。

以下のコマンドを使用して Telegraf を実行します

telegraf --config http://hadoop102:8080/example01.conf

ご覧のとおり、設定ファイルの取得に成功し、データが正常に出力できました。

ただし、この方法では構成の変更を監視できません。

例 4: 包括的な例

この例では、上記のすべての概念をつなぎ合わせてケースを作成してみます。入力が 2 つ、処理プラグインが 2 つ、集計プラグインが 2 つあります。最後に Telegraf を –test モードで実行します。

(1) 設定ファイルの書き込み

example04.conf ファイルを作成する

vim example04.conf

次のように入力します。

[agent]
  interval = "3s"
  flush_interval = "5s"

[global_tags]
  who = "atguigu"

[[inputs.cpu]]
  percpu = true
  totalcpu = true
  collect_cpu_time = false
  report_active = false
  core_tags = false

[[inputs.mem]]
  # no config

[[processors.converter]]
  order = 0
  [processors.converter.tags]
    measurement = ["cpu"]

[[processors.date]]
  order = 1
  tag_key = "month"
  date_format = "1"

[[aggregators.valuecounter]]
  period = "30s"
  namepass = ["cpu0","cpu1"]
  fields = ["usage_idle"]

[[aggregators.minmax]]
  period = "30s"
  namepass = ["mem"]

[[outputs.file]]
  files = ["stdout"]

• global_tags: コンテキスト設定に属するグローバル タグ タグは Telegraf ワークフロー全体に追加されます。

• processors.date: データのタイムスタンプを抽出し、それをタグに変換します。ここでの dateformat は、GoLang の参照時刻形式を渡す必要があります。

  Year: "2006" "06"
  Month: "Jan" "January" "01" "1"
  Day of the week: "Mon" "Monday"
  Day of the month: "2" "_2" "02"
  Day of the year: "__2" "002"
  Hour: "15" "3" "03" (PM or AM)
  Minute: "4" "04"
  Second: "5" "05"
  AM/PM mark: "PM"
  

• aggregators.valuecounter、集計プラグイン、値カウンターは、過去 30 秒間の値の数をカウントします。測定名が cpu0 および cpu1 のデータのみがこのプラグインに入力されます。

• aggregators.minmax、集計プラグイン、最大値と最小値、過去 30 秒間のフィールド値の最大値と最小値の統計、測定名が mem のデータのみが入力されます。

(2) Telegraf プログラムを実行する

以下のコマンドを使用して Telegraf を実行します。

telegraf --config ./example03.conf --test

実行情報を観察します。

ロード済み

• 2つの出力プラグイン

• 2つの処理プラグイン

• 2 つの集計プラグイン

• 0 出力プラグイン (テスト モードは出力プラグインをロードしません)

データの変更を観察します。

図に示すように、未集計の元のデータが緑色のボックス内にあることがわかります。

中の赤いボックスが集計されたデータです。

• 集約された mem 測定では、各フィールドに対応する _min フィールドと _max フィールドがあり、最後の 30 秒の最大値と最小値を示します。

• cpu1 と cpu0 の測定値を集計した後、元の use_idle フィールドは us​​e_idle_98.xxxx=1i になります。これは、過去 30 秒間に、usage_idle 値が 98.xxx のデータが 1 つだけ存在することを意味します。したがって、この例は適切ではありません。valuecount は、リクエストのステータス コードなど、値の範囲が制限された文字列型データに使用する必要があります。

例 5: 構成ファイルと環境変数

Telegraf の構成ファイルは値の構文をサポートしています。

(1) 設定ファイルの書き込み

example01.conf を example05.conf にコピーします

cp example01.conf example05.conf

次のように入力します。

[agent]
  interval = "3s"

[global_tags]
  user = "${
    
    USER}"

[[inputs.cpu]]
  percpu = true
  totalcpu = true
  collect_cpu_time = false
  report_active = false
  core_tags = false

[[outputs.file]]
  files = ["stdout"]

(2) Telegraf のデフォルト変数宣言ファイル

/etc/default/telegraf は Telegraf のデフォルトの変数宣言ファイルであり、このファイルで変数を直接宣言することもできます。ただし、優先度は環境変数ほど高くありません。

vim /etc/default/telegraf

以下を追加します

USER=atguigu

保存して終了。

(3) Telegraf プログラムを実行する

次のコマンドを使用して telegraf プログラムを実行します。

telegraf --config ./example05.conf

(4) データ出力を観察する

その他の user=atguigu タグ

(5) コマンドラインで変数を宣言する

これは、値が dengziqi である USER 変数を環境変数に持つことと同じです。

USER=dengziqi

(6) Telegraf プログラムを実行する

次のプログラムを使用して Telegraf プログラムを再度実行します。

telegraf --config example05.conf --test

(7) 観測データ出力

ユーザーの価値はdengziqiになります

プラグインのドキュメントの使い方を学ぶ

上記 2 つの例から、3 つのプラグイン (入力 1 つ、プロセッサー 1 つ、出力 1 つ) の構成ファイルがそれぞれ独自の記述メソッドを持っていることがわかります。では、ユーザーとして、各アクセサリの構成を記述する方法はどうすればわかるでしょうか?

これには文書が必要です。

次に、公式ドキュメントを通じて、先ほどの Processor プラグインの使用法を理解しようとします。s

プラグインのドキュメントの使用方法

(1) Telegraf のバージョンが異なれば、サポートされるプラグインも異なります。

まず、Telegraf のバージョン 1.23 を使用している場合は、プラグインのドキュメントを読むときに、バージョン 1.23 のドキュメントも読む必要があることに注意してください。これは、Go 言語で開発されたプロジェクトは、プロジェクト全体に含まれるすべてのものを別のバイナリ実行可能ファイルにコンパイルするためです。

また、この実行ファイルに記述されている内容はすべてネイティブコードであり、特別なGo言語の実行環境を必要とせず、OS環境から直接実行することができます。

この時点で、Telegraf のプラグインとフレームワークのコア コードは一緒にコンパイルされ、すべて 1 つの実行可能ファイルにまとめられます。

したがって、古いバージョンの Telegraf ソース コードをダウンロードし、そこに必要なプラグイン ソース コードを書き込んで再コンパイルしない限り、v1.23 の固有のプラグインは以前のバージョンでは使用できません。

知らせ！上記は Telegraf の組み込みプラグインです。Telegraf は実行入力プラグインも残しています。このプラグインを通じて、インジケーター データをキャプチャする外部プラグインと統合できます。次のコースには詳細なケースが含まれています。

(2) Telegrafプラグインディレクトリ

まず、Telegraf の公式ドキュメントには、Plugin directory という列があり、ここには、対応する Telegraf バージョンで利用可能なすべてのプラグインが表示されます。

以下のリンクは Telegraf v1.23 のプラグイン ディレクトリです。

https://docs.influxdata.com/telegraf/v1.23/plugins/

(3) プラグインフィルタリング

ページの上部には一連のフィルターがあり、表示したいプラグイン カテゴリにチェックを入れると、ページ下部のプラグイン リストが大幅に短くなり、見つけやすくなります。あなたのターゲットを素早く。

ここでは、「プロセッサ」オプションをクリックして、ページの下部に参照できるコンポーネントが 27 個だけ残るようにします。

(4) 該当するプラグインのヘルプドキュメントを検索する

ページを下にスクロールすると、プラグインのリストが表示されます。これらはフィルターで除外したプラグインです。

2 番目のカードは、例 2 で使用した Converter プラグインです。下の図に示すように、カードにはいくつかのヘルプ情報が表示されます。右上隅にある表示ボタンをクリックすると、詳細な手順が表示されます。

まず、完全なプラグイン構成にどのようなオプションを含めることができるかを確認できます。

何よりも、プラグインの作成者は通常、プラグインがどのように機能するかを理解するのに役立ついくつかの例を提供します。

役立つ情報はサンプル構成にも含まれています

以上が公式サイトからのプラグインの使い方です。さらに、telegraf コマンドを使用して、プラグインのサンプル設定を表示できます。

次のコマンドは、Telegraf のすべての組み込みプラグインのサンプル構成を出力します。

telegraf config

ただし、コンソールへの出力はほとんど役に立ちません。正しい方法は、ファイルにエクスポートし、エディターで検索して表示することです。

telegraf config \> tmp.conf

図に示すように、vim エディターで開いた後、正規表現を直接使用して目的のプラグインを見つけます。このプラグインで使用可能なすべての構成項目と、各構成項目の説明が含まれています。しかし、データを結合するユースケースはありません。

Telegraf 内部データ構造 (InfluxDB 行プロトコル)

Telegraf の内部データ構造は、InfluxDB 行プロトコルと呼ばれます。以下に示すように:

Telegraf 自体は、InfluxData によって InfluxDB 用に特別に開発されたデータ コレクターです。上記のデータ形式は InfluxDB データベースで使用されており、上記形式に準拠していれば、InfluxDB API を介してデータベースにデータをインポートできます。したがって、当然のことながら、独自のプラグインは独自のエコシステムである InfluxDB をサポートします。

次に、そのいくつかのコンポーネントを紹介します。

測定（測定名）

後で勉強するにつれて、この概念を徐々に深く理解できるようになります。現時点では、リレーショナル データベースのテーブルとして理解できます。

• 必須
• 測定の名前。各データポイントは、それがどの測定値に属するかを宣言する必要があり、省略することはできません。
• 大文字と小文字を区別
• アンダースコア_で始めることはできません

タグセット

ラベルは、値の範囲が限られており、変更される可能性が低い属性に使用する必要があります。センサーの種類やIDなど。タグはInfluxDB のインデックスに相当します。データ ポイントにタグを追加すると、将来のデータの取得が容易になります。ただし、インデックスが多すぎると、データの挿入速度が遅くなります。

• オプション
• キーと値の関係は = で表されます。
• 複数のキーと値のペアを区切るにはコンマを使用します。
• タグのキーと値は大文字と小文字が区別されます
• タグキーをアンダースコア_で始めることはできません
• キーのデータ型: 文字列
• 値のデータ型: 文字列

フィールドセット

• 必須
• データ ポイント上のすべてのフィールドのキーと値のペア。キーはフィールド名で、値はデータ ポイントの値です。
• データ ポイントには少なくとも 1 つのフィールドが必要です。
• フィールドセット キーでは大文字と小文字が区別されます。
• 分野
• キーのデータ型: 文字列
• 値のデータ型: float | integer | unsigned integer | string | boolean

タイムスタンプ

• オプション
• データ ポイントの Unix タイムスタンプ。各データ ポイントは独自のタイムスタンプを指定できます。
• タイムスタンプが指定されていない場合。次に、InfluxDB は現在のシステム タイムスタンプを使用します。
• データ型: Unix タイムスタンプ
• データ内のタイムスタンプがナノ秒単位ではない場合は、データを書き込むときにタイムスタンプの精度を指定する必要があります。

空間

行プロトコルの空白によって、InfluxDB がデータ ポイントを解釈する方法が決まります。最初のエスケープされていないスペースは、測定とタグのセットをフィールド セットから分離します。2 番目のエスケープされていないスペースは、フィールド セット (フィールド レベル) とタイムスタンプを区切ります。

プロトコル内のデータ型とその形式

(1) Float（浮動小数点数）

IEEE-754 標準の 64 ビット浮動小数点数。これはデフォルトのデータ型です。

例: フィールドレベルの値型が float の行プロトコル

myMeasurement fieldKey=1.0
myMeasurement fieldKey=1
myMeasurement fieldKey=-1.234456e+78

(2) 整数(整数)

符号付き 64 ビット整数。数字の最後に小文字の数字 i を追加する必要があります。

整数の最小値	整数の最大値
-9223372036854775808i	9223372036854775807i

例: フィールド値のタイプは整数です

(3) UInteger（符号なし整数）

符号なし 64 ビット整数。数字の最後に小文字の数字 u を追加する必要があります。

符号なし整数の最小値	符号なし整数の最大値
0u	18446744073709551615u

例: フィールド値の型が符号なし整数であるナビゲーション プロトコル

myMeasurement fieldKey=1u
myMeasurement fieldKey=12485903u

(4) 紐(ひも)

通常のテキスト文字列、長さは 64KB を超えることはできません

例：

\# String measurement name, field key, and field value
myMeasurement fieldKey="this is a string"

(5) Boolean (ブール値)

正しいか間違っているか。

例：

ブール値	サポートされている構文
真実	t、t、true、true、true
間違い	f、F、偽、偽、偽

例：

myMeasurement fieldKey=true
myMeasurement fieldKey=false
myMeasurement fieldKey=t
myMeasurement fieldKey=f
myMeasurement fieldKey=TRUE
myMeasurement fieldKey=FALSE

ブール値を引用符で囲まないでください。引用符を使用しないと、文字列として解釈されます。

(6)Unixタイムスタンプ(Unixタイムスタンプ)

タイムスタンプを書き込むと、

myMeasurementName fieldKey="fieldValue" 1556813561098000000

コメント

# 記号で始まる行はコメントとして扱われます。

例：

# 这是一行数据
myMeasurement fieldKey="string value" 1556813561098000000

Telegraf コマンドラインの使用

導入

Telegraf をインストールしたら、telegraf コマンドを使用できるようになります。

使用法：

telegraf [ 命令 ]
telegraf [ 选项 ]

注文：

注文	説明する
構成	完全な設定例を標準出力 (stdout コンソール) に出力します。
バージョン	バージョン番号を標準出力 (stdout コンソール) に出力します。

オプション:

パラメータ	説明する
–aggregator-filter <フィルター>	フィルタ アグリゲータを有効にするには、区切り文字は次のとおりです。
–config <ファイル>	ロードする設定ファイル
–config-directory<ディレクトリ>	他の構成ファイルが含まれるディレクトリ。構成ファイル名は .conf で終わる必要があります
–非推奨リスト	非推奨のプラグインまたはプラグイン オプションをすべて出力します。
–watch-config	ローカル構成ファイルが変更されると、Telegraf プロセスが再起動され、リスニング方法ではファイル システム通知またはポーリング ファイルが使用されます。--watch-config 機能はデフォルトでは無効になっています。
–plugin-directory <ディレクトリ>	プラグイン ディレクトリ。このディレクトリは再帰的に検索されて利用可能なプラグインが検索され、見つかったプラグインがロードされます。プラグイン ファイルの拡張子は .so です。
-デバッグ	デバッグレベルのログファイルを開始します
–input-filter <フィルター>	有効にする入力プラグインを次のように区切ってフィルタリングします。
–入力リスト	利用可能な入力プラグインを印刷する
–出力フィルター	有効にする出力プラグインを次の区切りでフィルタリングします。
–出力リスト	利用可能な出力プラグインを印刷する
–pidfile <ファイル>	pid が書き込まれるファイル。
–pprof-addr <アドレス>	pprof アドレス。デフォルトでは無効になっています。pprof は Go のプログラム実行時間を解析するためのツールで、さまざまなパフォーマンス データを提供できます。たとえば、メモリ割り当てに関するサンプリング情報、メモリ使用量に関するサンプリング情報などです。
–processor-filter <フィルター>	有効にするフィルター プラグインをフィルターします。プラグインを区切るには: を使用します。
-静かな	静音モードで実行する
–section-filter <フィルター>	このパラメータは、config コマンドと一緒に使用した場合にのみ意味を持ちます。印刷する構成セクション (エージェント、グローバルタグ、出力、プロセッサー、アグリゲーター、入力) をフィルターします。設定セクションは次のように区切られています。
–サンプル構成	完全なサンプル構成を出力します (config コマンドと同じ機能)
-一度	メトリクスを一度収集して書き出し、プロセスを終了します。
-テスト	メトリクスを 1 回収集して 1 回印刷し、プロセスを終了します。
–テスト待機	telegraf进程在test或once模式下，进行一次input所需要的秒数。
–usage <plugin>	打印插件的用法。（比如：telegraf --usage mysql）
–version	打印Telegraf的版本号

生成Telegraf的配置文件

使用config命令，打印输出配置配置文件（也可以使用–sample-config参数），将输出重定向到一个文件中。

telegraf config > telegraf.conf

生成仅定义了CPU输入和InfluxDB输出的配置文件

telegraf --input-filter cpu --output-filter influxdb config

运行单个的Telegraf配置文件并打印到控制台

使用test模式，output插件不会被启用。

telegraf --config example01.conf --test

运行一个配置文件中的所有插件

telegraf --config telegraf.conf

运行一个包含CPU和内存输入插件以及InfluxDB输出插件的Telegraf实例

telegraf --input-filter cpu:mem --output-filter influxdb

运行Telegraf时开启pprof

telegraf --config telegraf.conf --pprof-addr localhost:6060

运行上述代码后，可在浏览器访问hadoop102:6060来观察进程运行的性能信息。

配置文件参数

Agent配置

配置名	直译	解释
interval	间隔	所有的input组件采集数据的间隔时间
round_interval	间隔取整	将采集的间隔时间取整。比如，如果interval设置为10s，但我们在1分02秒启动了telegraf服务，那么采集的时间会取整到1分10秒，1分20秒，1分30秒
metric_batch_size	指标 批大小	telegraf一批次从output组件向外发送数据的大小，网络不稳定时可以减小此参数。
metric_buffer_limit	指标 缓冲区	telegraf会为每个output插件创建一个缓冲区，来缓存指标数据，并在output成功将数据发送后，将成功发送的数据从缓冲区删除。所以，metriac_buffer_limit参数应该至少是metric_batch_size参数的两倍
collection_jetter	采集抖动	这个参数会在采集的时间点上加一个随机的抖动，这样可以避免很多插件同时查询一些消耗资源的指标，从而对被观测的系统产生不可忽视的影响。
flush_interval	刷新间隔	所有output的输出间隔，这个参数不应该设的比interval（所有input组件的采集间隔）小。最大的实际发送间隔将会是
flush_jitter	刷新抖动	对output的输出时间加上一个随机的抖动，这主要是为了避免大量的Telegraf实例在同样的时间同时执行写入操作，出现较大的写入峰值。比如，flush_jitter设为5s，flush_interval设为10s意味着会在10~15秒的时候进行一次输出。
precision	精度	精度配置确定从输入插件接收的点中保留多少时间戳精度。所有传入的时间戳都被阶段为给定的精度。然后Telegraf用零填充截断的时间戳以创建纳秒时间戳，输出插件将以纳秒为单位发出时间戳。有效的精度为ns，us，ms和s。例如：如果精度设置为ms，则纳秒时间戳1480000000123456789将被截断为1480000000123毫秒精度，然后用0填充以生成新的，不太精确的纳秒时间戳1480000000123000000。输出插件不会进一步更改时间戳。如果是服务型的输出插件会忽略这个设置。
logfile	日志文件	自定义的日志名称，
debug	调试	使用debug模式运行Telegraf
quiet	安静	安静地运行Telegraf，只会提示错误信息
logtarget	日志目标	该配置用来空值日志的目标。它可以是"file"，“stderr"之一，如果是在Windows系统上，它还可以设为"eventlog”。设置为"file"时，输入文件由 logfile 配置项决定。
logfile	日志文件	指定logtarget指定为"file"时的日志文件名。如果设置为空，那么日志会输出到stderr上。
logfile_rotation_interval	日志轮转间隔	日志轮转间隔，多长时间开启一个新的日志文件，如果设置为0，那么就不按时间进行轮转。
logfile_rotation_max_size	日志轮转大小	当正在使用的日志文件的大小超过该值时，开启一个新的日志文件。当设置为0，表示不按照日志文件的大小进行日志轮转。
logfile_rotation_max_archives	最大轮转存档数	最大的日志归档数量，每一次日志轮转发生时，都会产生一个新的正在使用的日志文件，和一个归档（旧的不再使用的日志文件）
log_with_timezone	日志时区	设置日志记录要使用的时区，或者设为"local"即为本地时间。
hostname	主机名	覆盖默认的主机名，如果不设该值，那么os.Hostname( )的返回值。（os.Hostname）是Go语言标准库中的方法，可以获取当前机器的名称。
omit_hostname	忽略主机名	telegraf输出的指标数据中，有一个默认的

Input 输入插件通用配置

配置名	直译	解释
alias	别名	给一个input插件实例进行命名。
interval	间隔	单个Input组件收集指标的间隔时间，插件中的interval配置比全局的interval配置的优先级要高。
precision	精度	单个Input组件的时间精度，覆盖[agent]中的配置。精度配置确定从输出插件接收的点中保留多少时间戳精度。所有传入的时间戳都被阶段为给定的精度。然后Telegraf用零填充截断的时间戳以创建纳秒时间戳，输出插件将以纳秒为单位发出时间戳。有效的精度为ns，us，ms和s。例如：如果精度设置为ms，则纳秒时间戳1480000000123456789将被截断为1480000000123毫秒精度，然后用0填充以生成新的，不太精确的纳秒时间戳1480000000123000000。输出插件不会进一步更改时间戳。如果是服务型的输出插件会忽略这个设置。
collection_jitter	采集抖动	单个Input组件的采集抖动
name_override	重命名	覆盖原来的指标名称，默认值为input组件的名称
name_prefix	名称前缀	指定要附加到度量值名称的前缀
name_suffix	名称后缀	指定要附加到度量值名称的后缀
tags	标签集	给当前input数据添加新的标签集。

Output 输出插件通用配置

配置名	直译	解释
alias	别名	给一个output插件起一个别名
flush_interval	刷新间隔	单个output插件的输出间隔（覆盖全局配置）
flush_jitter	刷新抖动	单个output插件的输出时间抖动（覆盖全局配置）
metric_batch_size	指标批次大小	一次最多发送多少条数据（会覆盖全局配置）
metric_buffer_limit	指标缓冲区上限	未发送数据的缓冲区（会覆盖全局配置）
name_override	重命名	覆盖原来的指标名称，默认值为output的名称（我怀疑官网说错了）
name_prefix	名称前缀	指标名称的前缀
name_suffix	名称后缀	指标名称的后缀

Aggregator 聚合插件通用配置

配置名	直译	解释
alias	别名	给一个Aggregator插件的实例命名
period	期间	聚合器对从now-period 到now 之间的数据进行聚合。
delay	延迟	聚合时进行一个小的延迟，防止在对时间戳为1000的数据进行聚合时，上游还在正在发送时间戳为1000的数据
grace	宽限	迟到多久的数据可以进入下一个聚合周期。
drop_original	删除源	默认为false，如果设置为true，袁术的指标数据就会从流水线上删除，不会发给下游的output插件
name_override	名称覆盖	给数据的指标名称重新命名
name_prefix	名称前缀	给指标名称加一个前缀
name_suffix	名称后缀	给指标名称加一个后缀
tags	标记	添加额外的标签集

Processor 处理插件通用配置

配置名	直译	解释
alias	别名	给Processor插件的示例起一个名字
order	顺序	这是处理器的执行顺序，如果没有制定，那么执行器的顺序就是随机的。注意！不是按照配置文件的先后顺序来的，而是随机。

Metric filtering 指标过滤器通用配置

指标过滤器的配置可以卸载input，output

配置名	直译	解释
namepass	名称通过	一个glob模式的字符串数组，仅有measurement名称与这个配置的参数能匹配的指标数据可以进入此插件。
namedrop	名称删除	一个glob模式的字符串数组，能匹配上measurement的数据直接删除。
fieldpass	字段通过	一个glob模式的字符串数组，只有能匹配上的字段才能通过
fielddrop	字段删除	一个glob模式的字符串数组，如果匹配上了就删除这个资源。
tagpass	标签通过	一个glob模式的字符串数组，tag能匹配上的数据才能通过
tagdrop	标签删除	一个glob模式的字符串数组，tag能匹配上的数据会被删除
taginclude	标签包含	一个glob模式的字符串数据，能匹配到其中一个的整条数据才能通过。
tagexclude	标签不含	tageinclude的反函数

注意！由于YOML的解析方式，过滤器参数必须在插件定义的末尾来进行定义，负责后续的插件配置项将被截石位 tagpass或者tagdrop的一部分。

Glob用法（参考资料）

glob起源于Unix上的bash shell。我们知道的bash shell中的一个功能强大的命令，rm-rf /* 其中 * 就是glob风格的模式匹配，通常 glob最常用的地方就是匹配文件名称。它在某些方面与正则表达式相同，但是他们各自有着不同的语法和约定。

详细内容可以参考: https://github.com/whinc/whinc.github.io/issues/18

以下是表达式的说明。

基础语法

相比正则表达式大量的元字符，glob模式中元字符极少，所以掌握起来很快，glob默认不匹配隐藏文件（以点 . 开头的文件或目录），下面是glob的语法

通配符	描述	示例	匹配	不匹配
*	匹配0个或多个字符，包含空串	Law*	Law, Laws和Lawer	La, aw
?	匹配1个字符	?at	cat, bat	at
[abc]	匹配括号内字符集合中的单个字符	[cb]at	cat, bat	at, bcat
[a-z]	匹配括号内字符范围中的单个字符	[a-z]at	aat, bat, zat	at, bcat, Bat
[^abc]或[!abc]	匹配括号内字符集合中的单个字符	[cb]at	cat, bat	at, bcat
[^a-z]或[!a-z]	匹配括号内字符范围中的单个字符	[a-z]at	aat, bat, zat	at, bcat, Bat

在bash命令行中 [!abc]需要转义成[\!abc]

扩展语法

除了基础语法外，bash还支持glob的一些扩展语法，主要包含三种。

• Brace Expansion
• globstar
• extglob

三种拓展语法的定义和描述如下：

通配符	描述	示例	匹配	不匹配
{x, y, …}	Brace Expansion，展开花括号内容，支持展开嵌套括号	a.{png,jp{,e}g}	a.png, a.jpg, a.jpeg
**	globstar，匹配所有文件和任意层目录，如果**后面紧接着/则只匹配目录，不含隐藏目录	src/**	src/a.js, src/b/a.js, src/b/	src/.hide/a.js
?(pattern-list)	匹配0次或1次给定的模式	a.?(txt|bin)	a., a.txt, a.bin	a
*(pattern-list)	匹配0次或多次给定的模式	a.*(txt|bin)	a., a.txt, a.bin, a.txtbin	a
+(pattern-list)	匹配1次或多次给定的模式	a.+(txt|bin)	a.txt, a.bin, a.txtbin	a., a
@(pattern-list)	匹配给定的模式	a.@(txt|bin)	a.txt, a.bin	a., a.txtbin
!(pattern-list)	匹配非给定的模式	a.!(txt|bin)	a., a.txtbin	a.txt, a.bin

pattern-list是一组以 | 作分隔符的模式集合，例如 abc | a?c | ac*

与regexp的差异

glob 模式主要用于匹配文件路径，当然也可以用于匹配字符串，不过在匹配字符串的能力上比 regexp 要弱很多。由于 glob 模式和 regexp 存在相同的元字符，但是含义却不同，容易导致混淆，为了避免混淆，下面将 glob 模式转换成对应的 regexp 表示，以便区分他们的异同点。

glob	regexp	精确的 regexp
*	.*	(?!\.)[\/]*?$
?	.	(?!\.)[\/]$
[a-z]	[a-z]	^[a-z]$

glob匹配的是整个字符串，而regexp默认匹配的是子串，regexp如果要匹配整个字符串需显式指定^ 和 $。正则表达式中的(?!\.)，其表示不匹配隐藏文件。

Telegraf架构

责任链设计模式

Telegraf是典型的Pipeline（流水线或者管道）架构，这种架构使用了责任链设计模式的思想。

简单来说，这种设计模式的关键点就在“链”这个字上，代码的功能被拆分成一个一个独立的组件，而且能够根据需求，灵活地进行组合。

设计模式是针对代码来说的，在这里，我们还是把关注点放到Telegraf的Pipeline架构上。

Pipeline架构

Telegraf将输出的处理流程抽象为由多个插件组成的流水线。插件和插件之间用管道相连（可以理解为一个先进先出的队列）。这种架构至少能体现出两种优势。

• 插件和插件之间实现了松耦合，下一个插件可以不用管上一个插件的内部逻辑是怎么实现的。他们只要按照约定好的格式传递数据就行。

• 流程配置化，谁和谁组合的决定可以推迟到运行时决定，而不是开发人员必须在开发时就把各种处理流程写死，相当于交给了用户一堆积木。

通常的pipeline架构，除了要配置插件和组合顺序外，还会包括一层上下文配置，所以最终的常见Pipeline架构是如下图所示的。

Telegraf的实现

（1）架构角度

Telegraf内部设计了4种类型的插件。它们必须按照特定的顺序进行组合。

1. 输入插件

2. 处理插件

3. 聚合插件

4. 输出插件

而且输出插件、处理插件、聚合插件、输出插件之间，框架是如何控制他们传值的，这一点也有特别的约定。

• 所有的input插件会将数据放入同一个管道。

• 所有的processor插件会按先后顺序传递数据（在配置文件中必须显示地指定顺序，否则Processor之间会以随机顺序组合）

• Aggregator前的管道会把数据复制给所有的Aggregator插件，不过Telegraf还为插件们设计了指标过滤器，插件可以选择性地接收部分数据。

• Output前的管道也会将数据复制给所有的output组件，不过同样可以使用过滤器组件选择性地接收。

（2）性能角度

Telegraf使用Go语言开发，如果你使用的都是内部组件，那么每个插件都是一个独立的goroutine（协程、用户线程、轻量级线程）

集成官方未提供的外部插件

用python写一个查看文件数的input插件（exec版）

编写python脚本

可以自己找个地方集中存放python脚本。当前，为了方便，我们还是将python脚本放到/opt/module/telegraf_conf目录下。

在这个目录下创建我们的第一个python文件1.py。

vim dir_num_input_exec.py

键入以下内容。

import glob
import sys
import time
# 获取给定目录下的文件数

# 定义输出的 模板字符串
template = "PathFileNum,name=test num={num} {timestamp}"
# 获取传入的第一个参数
path = sys.argv[1]
# 使用glob进行文件匹配，得到匹配到文件数量
path_file_num = glob.glob(path).__len__()
# 套用模板
data = template.format(num=path_file_num)
print(data)
sys.exit(0)

程序讲解

• sys.args[1] 获取命令行的第一个参数，在这里是我们要监控的路径

• glob.glob(path).__len__( ) python提供的glob库，使用这个库可以匹配操作系统上的文件，比如/home/atguigu/*.log，就能得到/home/atguigu/目录下，所有以.log结尾的文件的列表，接着调用__len__( )方法，就能得到这个列表的长度。

• template.format( )，这行代码最终的返回值，就是符合Telegraf格式的数据了。在我们的程序里。会返回如下的数据。我们没有在字符串里声明时间戳，这是因为Telegraf会自动帮我们补上。

  PathFileNum,host=hadoop102,name=test num=0

• print(data)，打印，也就是将数据输出到stdout（标准输出）

• sys.exit(0)，对操作系统而言，以0为状态退出表示程序成功运行，过程中没有遇到异常。这里我们用代码将它显示声明了，其实不写也可以。通常，在面对不可靠场景时需要将它显示声明。比如，接口返回的数据不是我想要的，这个时候程序其实是正常退出的，但是我想将这种情况标记为异常，那么你可以写一个条件语句，后面写sys.exit(1)就行了。

编写Telegraf配置文件

创建example_dir_num_input_exec.conf。

vim example_dir_num_input_exec.conf

键入以下内容。

[agent]
  interval="3s"
  flush_interval="5s"

[[inputs.exec]]
  commands = ["python3 /opt/module/telegraf_conf/dir_num_input_exec.py /home/atguigu/*"]
  data_format = "influx"

[[outputs.file]]
  files = ["stdout"]

配置解释：

这里主要解释commands，我们最终传入的参数是 /home/atguigu/*，也就是统计/home/atguigu/目录下，所有文件的数量。

运行Telegraf

运行下面的命令，并观察控制台输出。

telegraf --config example_dir_num_input_exec.conf

可以发现，我们的Output组件已经输出了我们想要的数据，而且为我们补上了时间戳。

现在，可以尝试在/home/atguigu/路径下创建一个文件，观察数据的变化。

创建文件，观察数据变化

在Telegraf正在运行的情况下，另起一个终端，执行下述命令，在/home/atguigu/路径下创建一个文件。

touch /home/atguigu/haha

回到原先的控制台，可以看到数据已经发生变化。而且观察时间戳可以发现，指标数据是每3秒统计一次的。

用python写一个查看文件数的input插件（execd版）

上文说过exec和execd的区别，一个是到时间就调用一次，一个是将外部程序作为守护进程管理。现在，我们使用Python写一个execd版的。

（1）编写python脚本

还是在/opt/module/telegraf_conf目录下，创建dir_num_input_execd.py文件。

vim dir_num_input_execd.py

键入以下内容。

import glob
import sys

# 定义输出的 模板字符串
template = "PathFileNum,name=test num={num}"
# 获取传入的第一个参数
path = sys.argv[1]
# 获取命令行参数，这个参数应当是一个路径
for _ in sys.stdin:
    # 使用glob进行文件匹配，得到匹配到文件数量
    path_file_num = glob.glob(path).__len__()
    # 构造数据
    data = template.format(num=path_file_num)
    # 标准输出数据
    print(data)
    # 一定要手动刷掉缓冲区
    # 除了使用sys库，你还可以在print()函数中将flush参数设为True
sys.stdout.flush()

程序讲解：

• for_in sys.stdin：这其实是一个死循环，sys.stdin其实是可以阻塞程序的。程序会一直等待标准输入有内容了，才会继续向下运行。不过这里的标准输入是谁给的呢？后面会仔细讲解。
• sys.stdout.flush( )：手动刷掉缓冲区，当你使用print( )函数打印字符串时，字符串并不会直接出现在控制台上，而是会先进入缓冲区。等到缓冲区满，或者程序退出时，字符串才会打印到控制台上。我们之前写exec版的时候print( )之后用不着手动刷写缓冲区，因为程序执行完后会直接退出，退出时自动把缓冲区刷写。但是execd版的程序是要作为守护进程一直运行的，如果想要立刻得到数据就必须手动刷写缓冲区。

（2）编写Telegraf配置文件

创建example_dir_num_input_execd.conf文件。

vim example_dir_num_input_execd.conf

键入以下内容。

[agent]
    interval = "3s"
    flush_interval = "5s"
[[inputs.execd]]
    command = ["python3","/opt/module/telegraf_conf/dir_num_input_execd.py", "/home/atguigu/*"]
    data_format = "influx"
    signal = "STDIN"

[[outputs.file]]
  files = ["stdout"]

配置解释：

command：这个配置和exec插件中的commands不是一个风格，execd中的command虽然也是一个数组，但它其实是用，分隔开了一条完整的命令。在运行时，逗号会被空格取代，数组中的字符串最终会拼成一条完整的命令。

signal：字面意思，信号。是execd插件中一个非常巧妙的设计。execd会在采集时间到的时候向守护进程发送一个信号。这里将signal设为STDIN（标准输入），含义就是Telegraf会在每次采集时间到的时候，向python进程的标准输入发送一个信号。这也就是前面python脚本中，写for _ in sys.stdin 的意义。这也做是为了让python进程能够知道，到该采集指标的时候了。Telegraf上的interval配置就能作用与Python进程。否则，就需要自己写time.sleep( )和读取参数的操作。

（3）运行Telegraf

运行下面的命令，并观察控制台输出。

telegraf --config example_dir_num_input_execd.conf

可以看到，程序成功观测到了/home/atguigu/目录下的文件数量。

（4）创建文件，观察数据变化

同样，在Telegraf程序正在运行的情况下，我们新建另一个终端。使用touch命令新建一个文件，并回头观察Telegraf中指标数据的变化。

touch /home/atguigu/haha2

数据变化，说明execd版的输入插件也能成功运作。

用python写一个外部处理插件（execd版）

Telegraf还有一个processors.execd的插件。注意，exec没有提供处理插件。这个插件允许我们把Telegraf中的数据拿出来做一些花式转换。这里，我们做一个最简单的，就是给每条数据的最前面加上atguigu，这样相当于改了每条数据的measurement（测量名称）

（1）编写python脚本

/opt/module/telegraf_conf目录下，创建add_atguigu_processor.py文件。

vim add_atguigu_processor.py

键入以下内容：

import sys

# 循环获取标准输入
for line in sys.stdin:
    # 给输入前面加点东西接着输出
	print("atguigu"+line,end="",flush=True)

程序解释：

• for line in sys.stdin：循环等待标准输入，上游的processor或者input插件会将指标数据以标准输出的方式写到当前python程序里，我们只需按行读取就好了。
• print(“atguigu”+line,end=“”,flush=True)：给输入的内容前面加上一个atguigu：

（2）编写Telegraf配置文件

拷贝一份example01.conf，命名为example_processor_python.conf

cp example01.conf example_processor_python.conf

键入以下内容，红色部分是相对example01.conf新加的内容。

[agent]
  interval = "3s"
  flush_interval = "5s"

[[inputs.cpu]]
  percpu = true
  totalcpu = true
  collect_cpu_time = false
  report_active = false
  core_tags = false

[[processors.execd]]
  command = ["python3","/opt/module/telegraf_conf/add_atguigu_processor.py"]

[[outputs.file]]
  files = ["stdout"]

（3）运行Telegraf，观察数据变化

使用下面的命令，运行Telegraf程序。观察控制台数据输出

telegraf --config ./example_processor_python.conf

原先的数据输出每条以cpu打头，现在则是atguigucpu。

任务完成！

用Go语言在框架基础上实现插件

准备项目

（1）git clone Telegraf源码时指定版本

注意，我们目前使用的是v1.23.3的发行版，对于二次开发来说，原则上应以1.23.3发布时的源码作为起点。所以这里在clone时可以用-b来指定对应的版本号。

git clone -b v1.23.3 https://github.com/influxdata/telegraf.git

clone完成后，目录下会多出一个telegraf子目录。

（2）使用GoLand打开项目

进入项目后，GoLand需要对项目下的文件进行索引和依赖分析。时间会久一些。可以等待右下方的进度条跑完。

（3）对GoLand项目进行配置

点击File > Settings进入设置页面。

• GOPATH

  如果你是用的Go 1.11后的版本，在开启Go Module模式的前提下GOPATH就是一个放项目依赖的地方。我们之前在环境变量里配过一次。现在GoLand可以扫描到这个环境变量。

  另外，你也可以为当前项目单独设一个GOPATH放依赖。

• Go Modules & Environment

  Go自1.11退出Go Module包管理工具后，就一直推荐这种方式来进行包管理。当前，在项目范围内，GoLand默认是帮我们开启的，不用动。但是Go下载依赖库的时候会去访问Github，由于Github在国内不能直接访问，这里需要借助GoLand设置一个项目级的环境变量。

  GOPROXY=https://goproxy.cn,direct
  

  

下载依赖

点击项目目录下的go.mod文件。

mod文件里面就是Telegraf项目所需的依赖，第一个require快里面全是直接依赖的库。GoLand标红表示我们目前还确实这些依赖。

打开GoLand窗口下方的Terminal。使用下面的命令，下载依赖。

go mod download -x

-x的意思是将下载过程打印到控制台。

下载完成后，等待GoLand重新索引文件。时间可能会比较久。

依赖成功下载的标志就是go.mod文件中的依赖，颜色全变绿了。

示例：实现一个生成随机数的Input插件

创建自定义插件所在的路径

首先，打开项目的/plugins/inputs/目录，这里面放的是所有的输入插件。我们创建一个子目录atguigu_random，以后这里面就是我们生成随机数插件的代码。

在github上找input插件的模板

访问Telegraf在Github上的仓库（最好跳到1.23.3分支上）

https://github.com/influxdata/telegraf/tree/v1.23.3

拉到下面查看项目的README。我们可以看到一个开发引导，向你介绍该怎么开发插件的。此处，点击Input Plugins

点进来之后可以发现，具体怎么开发，人家已经列明白了。

再向下拉，可以看到一个输出插件的示例代码。

这样，我们就能愉快地做一个CV工程师了。

在 atguigu_random 目录下，创建atguigu_random.go文件。并将以下代码，复制粘贴到atguigu_random.go文件中。

注意，把包名从simple修改为atguigu_random。

//go:generate ../../../tools/readme_config_includer/generator
// package simple
package atguigu_random

import (
    _ "embed"

    "github.com/influxdata/telegraf"
    "github.com/influxdata/telegraf/plugins/inputs"
)

// DO NOT REMOVE THE NEXT TWO LINES! This is required to embed the sampleConfig data.
//go:embed sample.conf
var sampleConfig string

type Simple struct {
    
    
    Ok  bool            `toml:"ok"`
    Log telegraf.Logger `toml:"-"`
}

func (*Simple) SampleConfig() string {
    
    
    return sampleConfig
}

// Init is for setup, and validating config.
func (s *Simple) Init() error {
    
    
    return nil
}

func (s *Simple) Gather(acc telegraf.Accumulator) error {
    
    
    if s.Ok {
    
    
        acc.AddFields("state", map[string]interface{
    
    }{
    
    "value": "pretty good"}, nil)
    } else {
    
    
        acc.AddFields("state", map[string]interface{
    
    }{
    
    "value": "not great"}, nil)
    }

    return nil
}

func init() {
    
    
    inputs.Add("simple", func() telegraf.Input {
    
     return &Simple{
    
    } })
}

把自己插件的逻辑写到这个文件的函数中，我们的插件就能正常运作了。

接下来我们就一边解释一边开发我们的插件。

插件开发

（1）头部go:generate

编译阶段，帮助框架自动整合帮助文档的。它会找你包下的README.md文件，然后找到其中的toml @sample.conf代码块，然后做一些生成文档的操作。

README.md可写可不写，不会影响编译最终通过。如果你希望成为Telegraf的源码贡献者，那么是应该按照社区规范写README.md的。

（2）中间不能删除的两行

//go:embed sample.conf

这行看样子是注释，但是它更像java里面的注解。这行代码会影响程序的编译行为。在编译阶段，包下的sample.conf文件会被读取，将其中的内容作为字符串复制给sampleConfig变量。

所以，按照注释的要求，不仅这行不能删，包下还必须有sample.conf文件。

（3）创建sample.conf文件

在atguigu_random包下创建一个sample.conf文件。

（4）编写示例sample.conf

sample.conf里面的内容取决于你想用配置项如何决定程序的行为。

我决定给下面两个参数。

• size：每一个interval时间生成几条随机数数据。

• [range]：这个range是一个子配置快，在这个配置块中，可以设置我们的随机数在什么范围生成，比如[0-10]或者[0-100]。

  • min：随机数范围的最小值

  • max：随机数范围的最大值

max必须比min大。

最后，我编写的配置文件如下。

[[inputs.atguigu_random]]
  size = 1
  [inputs.atguigu_random.range]
      min = 0
      max = 10

这列的size min max 我们都给了明确的值，这样相当于给插件设了默认值。

现在我们可以尝试。

（5）将插件名注册到inputs列表中

现在，我们插件包的结构已经基本形成，可以将自己的包注册到Telegraf的插件列表中了。

在plugins/inputs/all下面，有一个all.go文件，这个文件里记录了Telegraf所有可用的input插件。

注册插件的方式，就是将自己的包import进来。在这个列表里面，增加下面的内容。

_ "github.com/influxdata/telegraf/plugins/inputs/atguigu_random

如果你是使用GoLand进行开发的，可能会发现在列表的底部打完包名，没过一会儿，包名就不见了。其实它应该是被调整到import列表的前面去了。这是因为go语言在设计时，希望所有人都能够写出格式一样的代码，不要为了什么花括号在行首还是行尾争吵。因此推出了go format工具。基于此，GoLand会将import的包，按照字母顺序a-z排序，你的包可能被放到前面了。

（6）init( )

这个函数的逻辑基本不用动，它是用来在telegraf启动时将插件实例放到inputs列表中的。第一个参数是本插件的名字，这个建议修改。它影响telegraf --input-filter，日志等一系列程序行为。

第二个参数，是一个函数，叫creator，我们的函数里面直接给了一个&Simple{}，当然你也可以给这个结构体里面的内容赋值，这样相当于给了默认值。

最终的init()实现如下。

func init() {
    
    
	inputs.Add("atguigu_random", func() telegraf.Input {
    
     return &Simple{
    
    } })
}

（7）尝试进行编译，看有没有成功注册插件

Telegraf是用make工具来进行编译的。准确来说，编译还是使用了go的编译器，不过make只不过是指定了一下编译的步骤。

在项目的根目录下，使用下面的命令编译telegraf。

make all

编译完成后，项目跟目录下会多出一个名为telegraf可执行文件。这个就是我们能用的telegraf命令了。

我们可以看一下telegraf现在能不能加载出我们的示例配置，如果能成功加载，说明我们的插件已经被编译到了telegraf的可执行文件中，项目不存在结构上的问题。

使用下面的命令，在input列表中找一下有没有atguigu_random

./telegraf --input-list | grep atguigu

如果有atguigu_random，说明现在框架是认我们的插件的。

你还可以用下面的命令看一下telegraf中，能不能返回我们的配置文件。

./telegraf --input-filter atguigu_random config

返回应当如下图所示。

现在，我们可以进一步丰富插件的逻辑了。

（8）配置文件的解析

配置文件的解析是Telegraf框架来帮我们完成的。我们只需要在插件中声明能够映射到配置文件内容结构体就行了。

配置文件在解析时，遇到子配置快，需要在程序中映射为一个单独的结构体。

在atgiugu_random.go中

创建一个新的名为RangeConf类型。

type RangeConf struct {
    
    
	Max int `toml:"max"`
	Min int `toml:"min"`
}

改写模板中的Simple类型

type Simple struct {
    
    
	Size  int `toml:"size"`
	Range *RangeConf

	Log telegraf.Logger `toml:"-"`
}

代码解释：

• 首字母大写，Go中首字母大写基本上意味着Java中的public。首字母大写的可以被外部访问。

• `toml:“xxx”`，意思是对应配置文件中的选项名，如果结构体中的参数名转为下划线命名法后能够跟配置文件对上，那么其实可以忽略。如果对不上就需要使用`toml:“xxx”`来手动映射了。

• *RangeConf，指向RangeConf类型的指针类型，来回传递指针，防止复制结构体。

（9）(s *Simple) Init( ) error校验配置的合法性

(s *Simple) Init( ) error 函数，并不是用来做配置文件解析的。这个函数被调用时，配置已经解析完了，这个函数内部适合做一些配置合法性校验和初始化的操作。

接下来在这个函数中，我们要做两个操作。

1. 配置合法性校验：判断Max是不是比Min大，如果不是就报错

2. 设置随机数生成器的种子：将当前的时间戳设为种子。

最终的(s *Simple) Init( ) error实现如下：

// Init is for setup, and validating config.
func (s *Simple) Init() error {
    
    
	if s.Range.Min >= s.Range.Max {
    
    
		return errors.New("max should be larger than min")
	}
	rand.Seed(time.Now().Unix())
	return nil
}

（10）(s *Simple) Gather(acc telegraf.Accumulator) error 发送数据

借助acc变量，我们可以借助AddFields方法向下游管道发送数据。AddFields接收4个参数。

• measurement，数据的测量名称

• fields，类型需是map[string]interface{}，key必须是string，value可以是任何类型

• tags，类型是是map[string]string，key和value的类型都得是string。

• t，time.Time类型，也就是时间，这个参数不是必须的，可以不传，不传就让Telegraf来自动补时间戳了。

最终的实现：

func (s *Simple) Gather(acc telegraf.Accumulator) error {
    
    
	for i := 1; i <= s.Size; i++ {
    
    
		acc.AddFields("atguigu_random",
			map[string]interface{
    
    }{
    
    "num": s.Range.Min + rand.Intn(s.Range.Max-s.Range.Min)},
			nil)
	}

	return nil
}

（11）再次编译

现在插件的逻辑已经写完了，使用下面的命令重新编译一次。

rm ./telegraf
make all

等待编译结束。

（12）验证插件效果

创建一个配置文件，test.conf

vim test.conf

键入以下内容：

[[inputs.atguigu_random]]
  size = 5
  [inputs.atguigu_random.range]
    min = 15
	max = 10

使用下面的命令来运行Telegraf

./telegraf --config ./test.conf --test

可以看到，插件已经能用了，它发现min比max大，并正确地抛出了异常。

修改test.conf。让min比max小

[[inputs.atguigu_random]]
  size = 5
  [inputs.atguigu_random.range]
    min = 10
	max = 20

使用下面的命令再次运行

./telegraf --config ./test.conf --test

这次，我们的插件成功运行了！

Telegraf与Prometheus结合使用

什么是Prometheus

Prometheus是一个专门为监控场景设计的服务器软件。其内部也实现了一个时序数据库。而且在当下Prometheus的热度也不低，下面简单介绍一下Prometheus的工作架构。

一般情况下，Prometheus的监控对象需要向外暴露一个接口，访问这个接口时，就能拿到程序内部的指标数据，而且这些数据应当是符合Prometheus数据格式的。

但是，如果我想要查看服务器host1上某个路径下的文件数，谁来向外暴露这个数据。这样，就必须实现一个HTTP服务，这个服务去统计本地某个目录下的文件数，并向外暴露一个API，等着Prometheus来抓。实现了这类功能的组件，在Prometheus生态中，叫做Exporter。

Prometheus的官方和社区提供了大量开源的而且是开箱即用的Exporter，生态很棒。

Exporter演示

我们使用Prometheus官方提供的Node Exporter（导出主机数据）

参考官网：https://prometheus.io/docs/guides/node-exporter/

（1）下载Node Exporter（暴露主机运行信息）

到服务器上，使用wget命令下载之。

wget https://github.com/prometheus/node_exporter/releases/download/v1.3.1/node_exporter-1.3.1.linux-amd64.tar.gz

（2）解压到目标路径

使用下面的命令将它解压到目标路径

tar -zxvf node_exporter-1.3.1.linux-amd64.tar.gz -C /opt/module/

（3）启动Node Exporter

cd到所在目录。看一下里面有什么。

cd /opt/module/node_exporter-1.3.1.linux-amd64

使用下面的命令直接启动node exporter

./node_exporter

（4）查看指标接口中的内容

node_exporter默认监听9100端口。打开浏览器，访问 http://hadoop102:9100/metrics 。如下图所示，这就是我们Prometheus可以抓取的数据了。

Prometheus数据格式

出于和InfluxDB一样的原因，Exporter导出的数据格式就是Prometheus承认的，可以写入Prometheus的格式。

当下，还有一个名为OpenMetrics的协议其热度在不断上升，而这一协议正是以Prometheus数据规范为基础的。

下面简单介绍一下Prometheus的数据格式：

• 指标名称：指标名称是必需的，不可缺少的。

• 标签集：标签集是一堆键值对，键是标签的名称，值是具体的标签内容，而且值必须是字符串。指标名称和标签共同组成索引。

• 第一个空格：第一个空格将 指标名称&标签集 与 指标值 分隔开

• 值：值默认是浮点数格式。

• 第二个空格：第二个空格将 值 与 时间戳 分隔开，但是如果省略时间戳的话，这个空格就可以省略掉。

• 时间戳：int64位的Unix时间戳，毫秒级。

Exporter模式的缺点

Exporter模式的缺点在于，当要监控的目标很多时，管理的繁琐程度就支线上升。

假如我有一台机器上部署了很多的服务，而且都想把他们的指标抓取出来。比如，监控mysql，监控cpu、内存、磁盘等硬件资源，监控MongoDB，监控SpringBoot应用的内存使用情况等等。那么每针对一个监控目标，我都要去下载一个专门Exporter，并让它运行起来。

每一个Exporter都是一个独立的进程，上述列出来的需求就要求你要安装6个Exporter，并开放6个端口了，管理起来十分麻烦。而且在Prometheus端还需要

这样，反而是Telegraf的插件模式更加友好，方便统一管理。

したがって、便宜上、Telegarf と Prometheus を組み合わせます。Telegraf を使用すると、複数の入力コンポーネントを 1 つの構成ファイルで管理できます。また、各コンポーネントはオーバーヘッドの少ない軽量のスレッドです。最後に、Prometheus はクロール ターゲットを構成するだけで、すっきりしています。

例: Telegraf を使用して CPU を監視し、Prometheus データ形式に公開する

データを Prometheus 形式で公開するには、構成ファイルに出力プラグインを追加するだけです。今回は前回のexample01.confをベースに修正を加えました。

(1) 設定ファイルの書き込み

cd でターゲット パスに移動します。

cd /opt/module/telegraf_conf

example01.conf のコピーをコピーします。

cp /opt/module/telegraf_conf/example01.conf /opt/module/telegraf_conf/example_cpu_prometheus.conf

example_cpu_prometheus.conf を編集します。

vim ./example_cpu_prometheus.conf

次の内容を入力します。赤い部分が今回の example01.conf と比較した新しい内容です。

[agent]
  interval = "3s"
  flush_interval = "5s"

[[inputs.cpu]]
  percpu = true
  totalcpu = true
  collect_cpu_time = false
  report_active = false
  core_tags = false

[[outputs.file]]
  files = ["stdout"]

[[outputs.prometheus_client]]
  listen = ":9273"

prometheus_client の設定の詳細については、telegraf/README.md at release-1.23 · influxdata/telegraf (github.com)を参照してください。

(2) Telegraf を実行する

次のコマンドを使用して、telegraf プログラムを実行します。

telegraf --config ./ example_cpu_prometheus.conf

(3) プラグインのロード情報を確認する

現在、出力プラグインは 2 つあり、1 つはファイル (標準出力コンソールへの出力) で、もう 1 つは prometheus_client です。

(4) コンソール出力を観察します。

コンソールは緻密な出力を出力し、入力データが出力にスムーズに到達できることを示します。

(5) ブラウザビューで Prometheus データが公開される

http://hadoop102:9273/metricsにアクセスして、公開されている Prometheus データを表示します。

以下のページが表示されれば成功です。