Introduction et utilisation de Telegraf (installation, utilisation, structure de données interne-protocole de ligne InfluxDB, configuration, architecture, utilisation de Glob, intégration et implémentation de plug-in, collection de Prometheus)

Introduction

Telegraf est un outil de collecte d'indicateurs open source basé sur un plug-in. Il s'agit d'un collecteur de données conçu sur mesure pour InfluxDB (une base de données de séries chronologiques), mais il est trop performant et peut écrire les données capturées à de nombreux endroits, notamment dans le domaine des bases de données de séries chronologiques. De nombreuses bases de données de séries chronologiques peuvent être utilisées avec lui. . Habituellement, il récupère un lot de données d'indicateur de temps en temps (telles que l'utilisation du processeur de la machine, les E/S du disque, les conditions du réseau, le nombre de sessions sur le serveur MySQL, etc.) et les envoie à une base de données de séries chronologiques, un message file d'attente, ou automatiquement La définition est exportée quelque part. Pour le traitement des applications en aval (comme les alarmes). Telegraf peut également fournir un service au monde extérieur et attendre que le client envoie des données.

Il est similaire à logstash, sauf que logstash collecte les journaux. telegraf collecte des métriques .

L'officiel propose plus de 300 plug-ins optionnels. De plus, Telegraf est facile à développer. Si les plug-ins officiels ne peuvent pas répondre à vos besoins, vous pouvez toujours écrire votre propre plug-in basé sur Telegraf.

Installer et déployer Telegraf

Visitez la page de téléchargement : https://portal.influxdata.com/downloads/

La Plateforme à droite est votre système correspondant. Sélectionnez celle correspondant à votre plateforme et l'URL de téléchargement changera automatiquement.

Ici, nous avons besoin que vous écriviez un fichier yum. Il y a un problème avec la commande donnée sur la page. Elle doit être modifiée comme suit. La partie rouge est notre modification.

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

Une fois ce code exécuté, un fichier influxdata.repo apparaîtra dans le répertoire /etc/yum.repose.d/. Le contenu à l'intérieur est la partie centrale de votre code.

Ensuite, utilisez yum pour installer en ligne.

sudo yum install telegraf

Utilisez systemctl pour vérifier si Telegraf est installé avec succès.

systemctl status telegraf

utiliser

Exemple 1 : Workflow à entrée unique et à sortie unique

(1) Écrire le fichier de configuration Telegraf

Créez un répertoire spécifiquement pour les fichiers de configuration de Telegraf.

mkdir /opt/module/telegraf_conf

Créez le fichier de configuration example01.conf.

vim example01.conf

et tapez ce qui suit.

[agent]
  interval = "3s"

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

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

Le fichier de configuration example01.conf implique 3 blocs de configuration.

• [agent] Voici quelques configurations globales. Ici, nous définissons interval="3s", ce qui signifie que tous les plug-ins d'entrée du fichier de configuration collecteront des indicateurs toutes les 3 secondes. La valeur par défaut de l'intervalle est de 10 secondes.
• [[ inputs.cpu ]] Il s'agit d'un composant d'entrée. La configuration ici signifie que les indicateurs que nous exportons incluront l'utilisation de chaque cœur de processeur, ainsi que l'utilisation totale de tous les processeurs.
• [[ outputs.file ]] Il s'agit d'un composant de sortie. Ici, nous utilisons un composant de sortie nommé file, mais le paramètre files est défini sur stdout (sortie standard), qui est la console, nous devrions donc pouvoir le voir lorsque le Le programme est en cours d'exécution. Les données sont imprimées sur la console.

(2) Exécutez le programme Telegraf

Utilisez la commande suivante pour démarrer Telegraf et observez la situation sur la console. s

telegraf --config ./example01.conf

Comme le montre la figure : la sortie suivante apparaît sur la console.

Contenu de sortie de la console :

(1) Paramètres de processus et informations de chargement du plug-in

Tout d'abord, la console affichera un contenu de journal contenant des informations de description de l'un de nos processus Telegraf.

1. Le numéro de version actuel de Telegraf est 1.23.2

2. Liste des plug-ins d'entrée chargés (actuellement 1) : cpu

3. Liste des plugins d'agrégation chargés (actuellement aucun)

4. Liste des plugins de processeurs chargés (actuellement aucun)

5. Liste des plug-ins de sortie chargés (actuellement 1) : fichier

6. Les balises sont activées, le jeu de balises global est activé et les données de l'indicateur global seront ajoutées avec la balise host=hadoop102

7. agent Config, configuration globale

   1. Intervalle : 3 s, tous les composants d'entrée collectent des données d'indicateur toutes les 3 s.

   2. Silencieux : faux, ne pas exécuter en mode silencieux.

   3. Nom d'hôte : "hadoop102", nom de la machine hadoop102

   4. Intervalle de rinçage : 10 s Tous les composants de sortie produisent des données d'indicateur toutes les 10 s. Ainsi, une fois Telegraf exécuté, vous devriez voir un lot de sorties sur la console toutes les 10 secondes.

(2) Sortie de données

Une fois le contenu de configuration Telegraf sorti, nous pouvons voir un tas de données denses. Vous constaterez qu’il ne ressemble pas à json ni à csv. Il s'agit en fait de la structure de données intégrée de Telegraf, appelée protocole de ligne InfluxDB. Cette structure de données sera expliquée plus tard.

Exemple 2 : Activer le plugin de traitement

Nous utilisons ici un exemple plus complexe pour apprendre à utiliser le plug-in de processeur dans Telegraf.

(1) Écrire le fichier de configuration Telegraf

Ensuite, nous apportons de légères améliorations sur la base de example01.conf et écrivons un nouveau fichier de configuration example02.conf.

cp example01.conf example02.conf
vim example02.conf

Tapez le contenu suivant (la partie rouge est notre nouveau contenu relatif à 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) Exécutez le programme Telegraf

Exécutez la commande suivante pour démarrer un processus telegraf avec le fichier de configuration example02.conf

telegraf --conf ./example02.conf

La console peut émettre normalement, indiquant que tout est normal.

(3) Différence par rapport au résultat de l'exemple 1

1) Les plug-ins chargés sont différents

En comparant les informations d'en-tête obtenues en exécutant Telegraf deux fois sur la console. Nous pouvons constater que le fichier example02.conf permet à notre programme telegraf de charger un plug-in de convertisseur supplémentaire.

2) La sortie des données a changé

Pour l'instant, nous n'avons pas expliqué le format de données interne de Telegraf. Mais nous pouvons nous concentrer uniquement sur les en-têtes des données de sortie des deux exemples pour l’instant.

Comme indiqué ci-dessous:

L'en-tête d'une donnée se compose de deux parties.

• mesure (nom de la mesure). Ici, nous utilisons le plug-in d'entrée CPU pour mesurer l'utilisation du CPU, il est donc approprié que le nom de la mesure soit appelé CPU.
• balises (jeu de balises). Étant donné que telegraf est un composant de collecte d'indicateurs développé par InfluxData pour InfluxDB, les balises ici sont en fait destinées à faciliter l'indexation par InfluxDB. Les détails de l'index ne seront mentionnés que plus tard.

En comparant les données de la figure ci-dessus, nous pouvons voir que le format des données a changé après l'ajout d'un plug-in de processeur. Le contenu du jeu d’étiquettes d’origine a été utilisé pour remplacer la mesure (nom de la métrique). Cela reflète également la fonction du plug-in du processeur pour exploiter, convertir et traiter les données.

Exemple 3 : Utilisation de la configuration à distance (http.server)

Le paramètre –cofnig de Telegraf peut également spécifier une URL pour permettre à Telegraf d'obtenir à distance le fichier de configuration via le réseau.

(1) Utilisez le propre http.server de Python pour créer rapidement un service de fichiers statique

cd dans le répertoire où nous plaçons le fichier de configuration /opt/module/telegraf_conf et utilisons la commande suivante pour démarrer rapidement un service de fichiers statique.

python3 -m http.server

Par défaut, il écoute sur le port 8000 et autorise l'accès externe.

(2) Exécutez Telegraf

Ensuite, nous pouvons essayer d'utiliser ce service pour obtenir le fichier de configuration.

Exécutez Telegraf en utilisant la commande ci-dessous

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

Comme vous pouvez le voir, nous avons obtenu avec succès le fichier de configuration et les données peuvent être sorties normalement.

Toutefois, cette méthode ne peut pas surveiller les modifications de configuration.

Exemple 4 : exemple complet

Dans cet exemple, nous allons essayer d’enchaîner tous les concepts évoqués ci-dessus pour rédiger un cas. Il aura 2 entrées, 2 plugins de traitement et 2 plugins d'agrégation. Et enfin, exécutez Telegraf en mode --test.

(1) Écrire les fichiers de configuration

Créer le fichier example04.conf

vim example04.conf

Tapez ce qui suit.

[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 : balises globales, qui appartiennent à la configuration du contexte. Une balise sera ajoutée à l'ensemble du workflow Telegraf.

• processeurs.date : extrayez l'horodatage des données et convertissez-le en balise. Le format de date ici doit transmettre un format d'heure de référence 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, plug-in d'agrégation, compteur de valeurs, compte le nombre de valeurs au cours des 30 dernières secondes. Seules les données portant les noms de mesure cpu0 et cpu1 entreront dans ce plug-in.

• aggregators.minmax, plug-in d'agrégation, valeurs maximales et minimales, statistiques des valeurs maximales et minimales des champs au cours des 30 dernières secondes, seules les données portant le nom de mesure mem seront saisies.

(2) Exécutez le programme Telegraf

Exécutez Telegraf en utilisant la commande ci-dessous.

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

Observez les informations de fonctionnement :

chargé

• 2 plugins de sortie

• 2 plugins de traitement

• 2 plugins d'agrégation

• 0 plug-ins de sortie (le mode test ne charge pas les plug-ins de sortie)

Observez les changements de données :

Comme le montre la figure, vous pouvez voir que les données originales non agrégées se trouvent dans la case verte.

À l’intérieur de la case rouge se trouvent les données agrégées.

• Dans la mesure mem agrégée, chaque champ a un champ _min et _max correspondant, indiquant les valeurs maximales et minimales au cours des 30 dernières secondes.

• Après l'agrégation des mesures cpu1 et cpu0, le champ usage_idle d'origine devient usage_idle_98.xxxx=1i, ce qui signifie qu'au cours des 30 dernières secondes, il n'y a qu'une seule donnée avec une valeur usage_idle de 98.xxx. Cet exemple ne convient donc pas, valuecount doit être utilisé sur des données de type chaîne avec une plage limitée de valeurs, comme le code d'état d'une requête.

Exemple 5 : fichiers de configuration et variables d'environnement

Le fichier de configuration de Telegraf prend en charge la syntaxe des valeurs.

(1) Écrire les fichiers de configuration

Copiez example01.conf dans example05.conf

cp example01.conf example05.conf

Tapez ce qui suit :

[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) Le fichier de déclaration de variable par défaut de Telegraf

/etc/default/telegraf est le fichier de déclaration de variables par défaut de Telegraf. Vous pouvez également déclarer des variables directement dans ce fichier. Mais la priorité n'est pas aussi élevée que les variables d'environnement.

vim /etc/default/telegraf

Ajoutez ce qui suit

USER=atguigu

Sauvegarder et quitter.

(3) Exécutez le programme Telegraf

Utilisez la commande suivante pour exécuter le programme Telegraf

telegraf --config ./example05.conf

(4) Observer la sortie des données

Plus de balises user=atguigu

(5) Déclarez les variables dans la ligne de commande

Cela équivaut également à avoir une variable USER dans la variable d'environnement, dont la valeur est dengziqi.

USER=dengziqi

(6) Exécutez le programme Telegraf

Exécutez à nouveau le programme Telegraf en utilisant la procédure suivante

telegraf --config example05.conf --test

(7) Observer la sortie des données

La valeur de l'utilisateur devient dengziqi

Apprendre à utiliser la documentation du plug-in

A travers les deux exemples ci-dessus, nous pouvons constater que les fichiers de configuration des trois plug-ins (1 entrée, 1 processeur et 1 sortie) ont chacun leur propre méthode d'écriture. Alors en tant qu’utilisateur, comment savoir écrire la configuration de chaque accessoire ?

Cela nécessite de la documentation !

Ensuite, nous essayons de comprendre l’utilisation du plug-in Processor tout à l’heure à travers la documentation officielle. s

Comment utiliser la documentation du plugin

(1) Différentes versions de Telegraf prennent en charge différents plug-ins

Tout d'abord, veuillez noter que si vous utilisez la version 1.23 de Telegraf, alors lorsque vous lisez la documentation du plugin, vous devez également lire la documentation de la version 1.23. En effet, les projets développés dans le langage Go compileront tout ce qui est impliqué dans l'ensemble du projet dans un fichier exécutable binaire distinct.

De plus, tout ce qui est écrit dans ce fichier exécutable est en code natif et ne nécessite pas d'environnement d'exécution spécial en langage Go. L'environnement du système d'exploitation peut l'exécuter directement.

À ce stade, le plug-in et le code principal du framework de Telegraf sont compilés ensemble et ils se trouvent tous dans un seul fichier exécutable.

Par conséquent, les plug-ins uniques de la v1.23 ne seront pas disponibles dans les versions précédentes, à moins que vous ne téléchargiez l'ancienne version du code source de Telegraf, que vous y écriviez le code source du plug-in souhaité, puis que vous le recompiliez.

Avis! Les plug-ins mentionnés ci-dessus sont les plug-ins intégrés de Telegraf. Telegraf nous a également laissé un plug-in d'entrée exec. Grâce à ce plug-in, nous pouvons intégrer des plug-ins externes qui capturent les données des indicateurs. Les cours suivants impliquent des cas détaillés.

(2) Répertoire des plug-ins Telegraf

Tout d'abord, dans la documentation officielle de Telegraf, il y a une colonne appelée Répertoire des plugins. Ici, vous pouvez voir tous les plug-ins disponibles sur la version Telegraf correspondante.

Le lien ci-dessous est le répertoire des plug-ins de Telegraf v1.23.

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

(3) Filtrage des plug-ins

En haut de la page se trouve un ensemble de filtres. Vous pouvez cocher les catégories de plug-ins que vous souhaitez afficher, de sorte que la liste des plug-ins en bas de la page soit beaucoup plus courte, ce qui vous permet de les trouver plus facilement. votre cible rapidement.

Ici, cliquez sur l'option Processeur, de sorte qu'il ne reste plus que 27 composants en bas de la page à parcourir.

(4) Trouver le document d'aide du plug-in correspondant

Faites défiler la page et nous pouvons voir une liste de plugins, ce sont les plugins que nous avons filtrés.

La deuxième carte est le plug-in Converter utilisé dans notre exemple 2. Comme le montre l'image ci-dessous, des informations d'aide figureront sur la carte. Cliquez sur le bouton Afficher dans le coin supérieur droit pour voir des instructions plus détaillées.

Tout d’abord, vous pouvez voir quelles options une configuration complète de plugin peut contenir.

Mieux encore, l’auteur du plugin vous donnera généralement quelques exemples pour vous aider à comprendre le fonctionnement du plugin.

Des informations utiles sont également disponibles dans l'exemple de configuration

Ce qui précède explique comment utiliser le plug-in via le site officiel. De plus, vous pouvez utiliser la commande telegraf pour afficher un exemple de configuration pour un plugin.

La commande suivante imprime des exemples de configurations pour tous les plugins intégrés dans Telegraf.

telegraf config

Cependant, imprimer sur la console est de peu d’utilité. La bonne pratique consiste à l'exporter dans un fichier, puis à le rechercher et à l'afficher dans l'éditeur.

telegraf config \> tmp.conf

Comme le montre la figure, après l'avoir ouvert avec l'éditeur vim, utilisez directement des expressions régulières pour trouver le plug-in souhaité. Il contient tous les éléments de configuration disponibles de ce plug-in, ainsi que les descriptions de chaque élément de configuration. Mais il n’existe aucun cas d’utilisation pour combiner des données.

Structure de données interne de Telegraf (protocole de ligne InfluxDB)

La structure de données interne de Telegraf est appelée protocole de ligne InfluxDB. Comme indiqué ci-dessous:

Telegraf lui-même est un collecteur de données développé spécifiquement pour InfluxDB par InfluxData. Le format de données ci-dessus est utilisé par la base de données InfluxDB. Tant que les données sont conformes au format ci-dessus, les données peuvent être importées dans la base de données via l'API InfluxDB. Par conséquent, bien entendu, notre propre plug-in prend en charge notre propre écosystème, InfluxDB.

Ensuite, nous présenterons ses différents composants.

mesure (nom de la mesure)

Au fur et à mesure que vous étudierez plus tard, vous comprendrez progressivement ce concept plus profondément. Actuellement, vous pouvez le comprendre comme une table dans une base de données relationnelle.

• requis
• Le nom de la mesure. Chaque point de données doit déclarer à quelle mesure il appartient et ne peut être omis.
• Sensible aux majuscules et minuscules
• Impossible de commencer par le trait de soulignement_

Ensemble de balises

Les étiquettes doivent être utilisées sur des attributs qui ont une plage de valeurs limitée et qui sont peu susceptibles de changer. Tels que le type et l'identifiant du capteur, etc. Dans InfluxDB, un Tag équivaut à un index . L'ajout de balises aux points de données facilite la récupération future des données. Mais s’il y a trop d’index, cela ralentira la vitesse d’insertion des données.

• Facultatif
• La relation clé-valeur est représentée par =
• Utilisez des virgules pour séparer plusieurs paires clé-valeur.
• Les clés et valeurs des balises sont sensibles à la casse
• Les clés de balise ne peuvent pas commencer par un trait de soulignement_
• Type de données de la clé : chaîne
• Type de données de valeur : chaîne

Ensemble de champs

• requis
• Toutes les paires clé-valeur de champ sur un point de données. La clé est le nom du champ et la valeur est la valeur du point de données.
• Un point de données doit avoir au moins un champ.
• Les clés Fieldset sont sensibles à la casse.
• Champ
• Type de données de la clé : chaîne
• Type de données de la valeur : float | entier | entier non signé | chaîne | booléen

Horodatage

• Facultatif
• Horodatage Unix du point de données, chaque point de données peut spécifier son propre horodatage.
• Si l'horodatage n'est pas spécifié. Ensuite, InfluxDB utilise l'horodatage actuel du système.
• Type de données : horodatage Unix
• Si les horodatages de vos données ne sont pas en nanosecondes, vous devez spécifier la précision de l'horodatage lors de l'écriture des données.

espace

Les espaces dans le protocole de ligne déterminent comment InfluxDB interprète les points de données. Le premier espace non échappé sépare l’ensemble de mesures et d’étiquettes de l’ensemble de champs. Un deuxième espace sans échappement sépare le Field Set (niveau du champ) et l'horodatage.

Types de données et leurs formats dans le protocole

(1) Float (nombre à virgule flottante)

Nombre à virgule flottante 64 bits standard IEEE-754. Il s'agit du type de données par défaut.

Exemple : protocole de ligne avec type de valeur float au niveau du champ

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

(2) Entier (entier)

Entier signé de 64 bits. Vous devez ajouter un chiffre i minuscule à la fin du numéro.

valeur minimale entière	valeur maximale entière
-9223372036854775808i	9223372036854775807i

Exemple : Le type de valeur du champ est entier

(3) UInteger (entier non signé)

Entier 64 bits non signé. Vous devez ajouter un chiffre u minuscule à la fin du numéro.

Valeur minimale entière non signée	Valeur maximale entière non signée
0u	18446744073709551615u

Exemple : Protocole de navigation dont le type de valeur de champ est un entier non signé

myMeasurement fieldKey=1u
myMeasurement fieldKey=12485903u

(4) Chaîne

Chaîne de texte ordinaire, dont la longueur ne peut pas dépasser 64 Ko

Exemple:

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

(5) Booléen (valeur booléenne)

vrai ou faux.

Exemple:

Valeur booléenne	Syntaxe prise en charge
Vrai	t, T, vrai, vrai, vrai
FAUX	f, F, faux, Faux, FAUX

Exemple:

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

N'utilisez pas de guillemets autour des valeurs booléennes, sinon elles seront interprétées comme des chaînes

(6) Horodatage Unix (horodatage Unix)

Si vous écrivez un horodatage,

myMeasurementName fieldKey="fieldValue" 1556813561098000000

note

Une ligne commençant par le signe dièse # sera traitée comme un commentaire.

Exemple:

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

Utilisation de la ligne de commande Telegraf

introduire

Une fois Telegraf installé, vous pouvez utiliser la commande telegraf.

usage:

telegraf [ 命令 ]
telegraf [ 选项 ]

Commande:

Commande	décrire
configuration	Imprimer l'exemple de configuration complet sur la sortie standard (console stdout)
version	Imprimer le numéro de version sur la sortie standard (console stdout)

Possibilités :

paramètre	décrire
–agrégateur-filtre <filtre>	Filtre Pour activer l'agrégateur, le délimiteur est
–config <fichier>	Fichier de configuration à charger
–répertoire-config<répertoire>	Répertoire contenant d'autres fichiers de configuration. Le nom du fichier de configuration doit se terminer par .conf
–liste de dépréciation	Imprimez tous les plugins ou options de plugin obsolètes.
–watch-config	Lorsque le fichier de configuration local est modifié, redémarrez le processus Telegraf et la méthode d'écoute utilise la notification du système de fichiers ou les fichiers d'interrogation. La fonction --watch-config est désactivée par défaut.
–répertoire-plugin <répertoire>	Répertoire des plug-ins, ce répertoire sera recherché de manière récursive pour trouver les plug-ins disponibles, et les plug-ins trouvés seront chargés. Le suffixe du fichier du plug-in est .so
-déboguer	Démarrer le fichier journal de niveau débogage
–filtre d'entrée <filtre>	Filtrer les plugins d'entrée à activer, séparés par : .
–liste d'entrée	Imprimer les plugins de saisie disponibles
–filtre de sortie	Filtrez les plugins de sortie à activer, séparés par : .
–liste de sortie	Imprimer les plugins de sortie disponibles
–pidfile <fichier>	Le fichier dans lequel le pid doit être écrit.
–pprof-addr <adresse>	Adresse pprof, désactivée par défaut. pprof est un outil d'analyse du temps d'exécution d'un programme dans Go. Il peut fournir diverses données de performances. Par exemple, échantillonner des informations sur l'allocation de mémoire, échantillonner des informations sur l'utilisation de la mémoire, etc.
–processeur-filtre <filtre>	Filtrez les plug-ins de filtrage à activer. Utilisez : pour séparer les plug-ins.
-calme	Exécuter en mode silencieux
–section-filter <filtre>	Ce paramètre n'a de sens que lorsqu'il est utilisé avec la commande config. Filtrez les sections de configuration à imprimer (agent, global_tags, sorties, processeurs, agrégateurs et entrées). Les sections de configuration sont séparées par :.
–exemple-config	Imprimer l'exemple de configuration complet (même fonction que la commande config)
-une fois	Collectez les métriques une fois, notez-les, puis quittez le processus.
-test	Collectez les métriques une fois et imprimez-les une fois, puis quittez le processus.
–test-attente	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的插件模式更加友好，方便统一管理。

Par conséquent, nous avons combiné Telegarf et Prometheus pour plus de commodité. Avec Telegraf, nous pouvons gérer plusieurs composants d'entrée avec un seul fichier de configuration. Et chaque composant est un thread léger avec moins de surcharge. Enfin, Prometheus configure simplement une cible d'analyse, qui est soignée et bien rangée.

Exemple : utilisez Telegraf pour surveiller le processeur et l'exposer au format de données Prometheus

Pour exposer les données au format Prometheus, ajoutez simplement un plugin de sortie au fichier de configuration. Cette fois, nous modifions l’exemple01.conf précédent.

(1) Écrire les fichiers de configuration

cd vers le chemin cible :

cd /opt/module/telegraf_conf

copiez une copie de example01.conf :

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

Modifiez example_cpu_prometheus.conf :

vim ./example_cpu_prometheus.conf

Tapez le contenu suivant, la partie rouge est le nouveau contenu par rapport à example01.conf cette fois :

[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"

Pour plus de configuration sur prometheus_client, veuillez vous référer à : telegraf/README.md à la version 1.23 · influxdata/telegraf (github.com)

(2) Exécutez Telegraf

Utilisez la commande suivante pour exécuter le programme telegraf.

telegraf --config ./ example_cpu_prometheus.conf

(3) Observez les informations de chargement du plug-in

Il existe désormais deux plugins de sortie, un pour le fichier (sortie vers la console de sortie standard) et l'autre pour prometheus_client.

(4) Observez la sortie de la console

La console produit une sortie dense, indiquant que les données d'entrée peuvent atteindre la sortie en douceur.

(5) Le navigateur affiche les données Prometheus exposées

Visitez http://hadoop102:9273/metrics pour afficher les données Prometheus exposées.

Si vous voyez la page ci-dessous, vous avez réussi.