Monitorer votre infra avec Telegraf, InfluxDB et Grafana

Dans un article précédent, nous avons vu comment monitorer avec Prometheus et Grafana une infrastructure dynamique basée sur Kubernetes.

Nous allons voir aujourd’hui comment monitorer une infrastructure plus classique avec Telegraf pour la collecte de métriques, InfluxDB pour le stockage et Grafana pour l’affichage et l’alerting. Nous nommerons cette solution TIG, dans la suite de cet article. Nous avons choisi ces outils, mais ils peuvent être remplacés par d’autres. Nous allons comparer également cette solution à d’autres outils du marché (Zabbix et Prometheus)

Architecture

Telegraf Architecture

Telegraf

Telegraf est un agent de récupération de métriques, 1 seul agent est nécessaire par VM. Cet agent sait récupérer des métriques exposées au format Prometheus et propose 2 modes de récupération des métriques, via :

  • push : la métrique est poussée dans Telegraf par le composant qui l’expose
  • pull : Telegraf récupère la métrique en interrogeant le composant qui l’expose (le mode le plus utilisé)

Les métriques sont insérées au fil de l’eau dans InfluxDB.

InfluxDB

InfluxDB est une Time Series Database (TSDB) écrite en Go dont les principaux avantages sont les performances, la durée de rétention importante et la scalabilité (nous verrons plus loin sous quelles conditions).

Grafana

Grafana est un outil supervision simple et élégant, permettant de s’intégrer à une TSDB, ici InfluxDB. Grafana expose dans des dashboards les métriques brutes ou agrégées provenant d’InfluxDB et permet de définir de manière honteusement simple des seuils d’alertes et les actions associées.

 

Cas d’utilisation

Dans cet article, nous allons monitorer une architecture simple :

  • une application web en Go exposée derrière un Nginx
  • une base de donnée Mysql sollicitée par un cron

Telegraph permet de récupérer par le biais de plugins les métriques des composants, ainsi que les métriques systèmes. Dans le cas nominal, Telegraf récupère ses métriques en mode pull. Cependant, dans le cas d’un cron ou d’un batch qui s’exécute périodiquement, la récupération des métriques se fait en mode push (c’est au cron ou au batch d’envoyer les métriques à Telegraf). Pour ce cas d’usage, nous allons utiliser le plugin http_listener qui permet à Telegraf d’écouter en http sur un port afin de récupérer les métriques envoyées par le cron/batch.

Telegraf cas d'utilisation

 

Installation

Pour cet article, l’installation se fera sous Ubuntu 16.04 LTS.

InfluxDB

Ajoutons le repo APT officiel d’InfluxDB :

curl -sL https://repos.influxdata.com/influxdb.key | sudo apt-key add -
source /etc/lsb-release
echo "deb https://repos.influxdata.com/${DISTRIB_ID,,} ${DISTRIB_CODENAME} stable" | sudo tee /etc/apt/sources.list.d/influxdb.list

Installons le package :

sudo apt-get update
sudo apt-get install influxdb

Démarrons le service :

sudo systemctl start influxd

Telegraf

Ajoutons le repo APT officiel de Telegraf :

curl -sL https://repos.influxdata.com/influxdb.key | sudo apt-key add -
source /etc/lsb-release
echo "deb https://repos.influxdata.com/${DISTRIB_ID,,} ${DISTRIB_CODENAME} stable" | sudo tee /etc/apt/sources.list.d/influxdb.list

Installons le package :

sudo apt-get update
sudo apt-get install telegraf

Démarrons le service :

sudo systemctl start telegraf

Grafana

Ajoutons le repo APT officiel de Grafana :

curl https://packagecloud.io/gpg.key | sudo apt-key add -
echo "deb https://packagecloud.io/grafana/stable/debian/ jessie main" | sudo tee /etc/apt/sources.list.d/grafana.list

Installons le package :

sudo apt-get update
sudo apt-get install grafana

Démarrons le service :

systemctl daemon-reload
systemctl start grafana-server

Configuration

InfluxDB

Nous allons créer une base de données pour pouvoir pousser les données remontées par Telegraf :

influx -execute "CREATE DATABASE influx_db"

Créons l’utilisateur influx_user :

influx -execute “CREATE USER influx_user WITH PASSWORD 'influx_password'”
influx -execute “GRANT ALL ON influx_db TO influx_user

Il est possible de créer une retention policy pour déterminer la durée de conservation des données :

influx -execute ‘CREATE RETENTION POLICY "one_year" ON "influx_db" DURATION 365d’

Telegraf

Telegraf fonctionne sous forme de plugin à activer pour récupérer les métriques. L’écosystème de plugins est riche : il y a des plugins pour monitorer nginx, cassandra, haproxy, postgresql… Nous allons nous intéresser à quelques plugins en particulier pour notre exemple. Dans l’ensemble, les plugins sont simples à configurer.

Nous allons voir ici des extraits de configuration.

Mode pull

Métriques systèmes

Les plugins permettant de remonter les métriques systèmes :

  • cpu
  • disk
  • diskio
  • kernel
  • mem
  • processes
  • swap
  • system
$ head /etc/telegraf/telegraf.d/system.conf
 
[[inputs.cpu]]
## Whether to report per-cpu stats or not
percpu = true
## Whether to report total system cpu stats or not
totalcpu = true
## If true, collect raw CPU time metrics.
collect_cpu_time = false
…
Métriques MySQL
$ head /etc/telegraf/telegraf.d/mysql.conf

[[inputs.mysql]]
servers = ["db_user:db_password@tcp(127.0.0.1:3306)/?tls=false"]
…
Métriques au format prometheus

Pour notre exemple, nous avons une application en Go qui expose des métriques au format prometheus sur l’url http://localhost:8080/metrics.
Nous allons utiliser le plugin prometheus pour récupérer ces données :

$ cat /etc/telegraf/telegraf.d/app.conf

[[inputs.prometheus]]
urls = ["http://localhost:8080/metrics"]

Mode push

Plugin HTTP_LISTENER

Le plugin http_listener fonctionne en mode push. Il ouvre un port http et attend qu’on lui pousse des métriques.

$ cat /etc/telegraf/telegraf.d/http_listener.conf

## Influx HTTP write listener
[[inputs.http_listener]]
## Address and port to host HTTP listener on
service_address = ":8186"

## timeouts
read_timeout = "10s"
write_timeout = "10s"

Il faut ensuite envoyer les métriques au format InfluxDB line-protocol :

$ curl -i -XPOST 'http://localhost:8186/write' --data-binary 'account_deleted,host=server01,region=us-west value=32 1434055562000000000'

Configuration du backend

Pour configurer le backend, nous allons utiliser le plugin output InfluxDB.

$ cat /etc/telegraf/telegraf.conf
…
[[outputs.influxdb]]
urls = ["http://localhost:8086"]
database = "influx_db"
username = "influx_user"
password = "influx_password"
…

Pour finir, redémarrons le service pour prendre en compte la configuration :

sudo systemctl restart telegraf

La configuration des plugins est documenté exhaustivement dans le fichier de configuration de base : /etc/telegraf/telegraf.conf

Grafana

La première étape dans Grafana est d’ajouter la source de donnée (InfluxDB dans notre cas). Allons dans “Datasource” puis “Add Datasource” et ajoutons la base Influxdb.

Database : influx_db
Username : influx_user
Password : influx_password

Grafana - Add data source

Ensuite pour créer les dashboards, vous pouvez récupérer des dashboards de la communauté Grafana ou créer vos propres dashboards. Pour notre exemple, nous avons importé le dashboard suivant prévu pour Telegraf.

Grafana - Dashboard

Il est possible d’ajouter des alertes dans les dashboards, mais nous n’allons pas détailler ce point dans cet article. Vous pouvez trouver des informations dans la documentation.

Note : Si vous utilisez Grafana en HA, pour le moment l’alerting n’est pas implémenté en mode cluster. Du coup, il faut s’assurer de l’activer sur un seul des noeuds pour ne pas recevoir les alertes en double. Néanmoins, si le noeud tombe, il n’y a plus d’alerting.

Comparaison

TIG vs Zabbix

Avantages de TIG :

  • La configuration est plus simple (métriques et graphes)
    • Pour récupérer une nouvelle métrique, il suffit de configurer en quelques lignes un plugin dans Telegraf, puis créer un dashboard dans Grafana.
  • La configuration est plus souple
    • Dans Zabbix on a besoin de décrire précisément chacune des métriques remontées, alors que dans TIG, InfluxDB n’a pas besoin de connaître la métrique à l’avance pour pouvoir la stocker.
  • Simple sur une infra dynamique
    • Exemple: Autoscaling sur les principaux cloud provider, les VMs nouvellement créés (avec Telegraf configuré) poussent auto-magiquement (sans configuration supplémentaire) dans InfluxDB.
  • Historique plus complet
    • La profondeur d’historique de Zabbix et d’InfluxDB est équivalente, néanmoins  Zabbix dispose d’une stratégie d’échantillonnage (configurable) entraînant une dégradation de la qualité de la donnée sur le long terme.
  • Les dashboards dans Grafana sont plus conviviaux et plus simples

 

Avantages de Zabbix :

  • Gestion des droits
    • La gestion des droits est plus fine sur Zabbix
  • Utilisé en prod depuis des années
    • Release 1.0 sorti le 23 mars 2004
    • Stable, complet et reconnu
  • Ressources de la communauté (templates, alertes, agent …)
    • Les agents Zabbix sont disponibles pour de nombreux systèmes d’exploitation
    • De nombreux templates pour configurer les métriques/alertes/graphes sont disponibles sur internet

 

TIG vs Prometheus

TIG vs Prometheus

Avantages de  TIG :

  • Historique plus complet (plusieurs années vs plusieurs heures/semaines)
    • Le but premier de Prometheus est le monitoring temps réel, la rétention par défaut est de 1 mois. Il est cependant possible d’augmenter cette rétention.
  • Besoin d’un seul agent par VM
    • Telegraf permet de récupérer plusieurs métriques avec un seul agent et pousse les données dans InfluxDB.
  • C’est l’agent Telegraf qui envoie les données à InfluxDB
    • Pas besoin d’ouvrir de multiples ports comme c’est le cas avec Prometheus.

 

Avantages de Prometheus :

  • Prometheus peut utiliser des services discovery pour savoir quels sont les services à monitorer
    • Exemple: Dans des environnements type Kubernetes, Docker, Prometheus est particulièrement adapté pour récupérer les métriques de conteneurs à durée de vie variable.

 

Conclusion

Dans la stack TIG nous avons apprécié la simplicité d’installation et de configuration, la souplesse de collecte des métriques et la profondeur d’historique.

La version opensource d’InfluxDB ne scale pas mais il est possible de scaler en passant sur les versions payantes InfluxEnterprise ou InfluxCloud. Nous n’avons, à l’heure actuelle, pas de retour d’expérience concernant ces deux derniers produits.

Pour la scalabilité, il est également possible d’utiliser OpenTSDB qui est une “Time Serie Database” open source, mais elle est bien plus compliquée à installer, et nous n’avons pas de retour sur son utilisation.

Il est possible de mettre Grafana en HA. Néanmoins, le mode cluster de l’alerting n’est pas encore implémenté. Cela signifie que soit on ne définit les alertes que sur un nœud, soit on les définit sur tous les nœuds mais les notifications seront dupliquées.

La modularité de cette stack nous permet si besoin d’utiliser :

  • d’autres collecteurs tels que Snap  (dans le cas, par exemple, où Telegraf ne proposerait pas de plugin adapté).
  • d’autres outils d’alerting tels que Kapacitor que nous étudierons prochainement.

Le cas d’utilisation que nous avons présenté est disponible sur ce repo : https://gitlab.octo.com/tpatte/monitoring_influxdb

 

 

6 commentaires sur “Monitorer votre infra avec Telegraf, InfluxDB et Grafana”

  • Salut, Quelques mots sur OpenTSDB que nous utilisons chez nous en interne. OpenTSDB historiquement ne supportait que HBase comme backend de stockage, de fait c'est vrai qu'il n'est pas simple de monter une stack Hadoop même s'il existe maintenant des distributions qui facilite grandement leur gestion (exemple : horton works). Depuis la dernière version stable opentsdb supporte google bigtables ou cassandra (j'admets ça reste pas simple à installer/utiliser). Le gros avantage qu'on a trouvé pour nous à opentsdb c'est son historique illimité et le fait de pouvoir remonter des métriques à la seconde. On peut garder autant de données qu'on veut sans altération. opentsdb ne supprime jamais de données ni ne la dégrade. On a 3 ans d'historique pour des milliers de serveurs et ça représente 3To de stockage sur notre cluster hbase (sur les 90To disponible... on est large ^^). L'historique illimité pour la partie capa planning sur des projets long terme c'est le top ! La fault tolerance d'opentsdb est surtout assurée par le cluster hadoop. Il suffit d'aligner quelques instances d'opentsdb avec un loadbalancer en frontal et vous avez votre haute dispo. Hadoop gère nativement la fault tolerance de part son architecture (6 serveurs minimum recommandé pour un cluster de production résiliant). Le seul point négatif avec opentsdb c'est que la communauté est assez pauvre et qu'on a souvent du mal à avoir des réponses à nos problèmes. Il y a assez peu de retour d'expérience sur son utilisation. Côté agent on utilise tcollector qui fonctionne de la même façon que telegraf. Et Grafana en front end. On utilise Bosun (et des outils internes) pour gérer des alertes complexes qu'on remplacera peut-être par grafana à terme quand ça aura gagné en maturité. Bosun est vraiment pas simple à utiliser donc ça serait plutôt cool. On utilise aussi des algos R (https://github.com/twitter/AnomalyDetection) pour faire de l'analyse prédictive des métriques remontées etc... opentsdb reste une solution top pour de très gros volumes de serveurs sans dégradation des métriques collectées :)
  • Waowww. Il serait temps que vous regardiez Dynatrace new Generation. Il a été conçu exprès... par le créateur de Dynatrace APM. Je retrouve chez ces acteurs R&D autrichiens les mêmes gènes que chez octo. Y compris un ovni devops ????
  • Je suis moi aussi convaincu par la stack TIG. Telegraph est trivial a installer et supporte beaucoup de plugins en natif (i.e les plugins sont dispo dans le code source, y'a juste à les activer en conf). Les dashboard Grafani mis à dispo dans la communauté sont faciles à importer et facile à personaliser. Par contre, je suis moins convaincu par Influx. On a eu pas mal de memory leak jusqu'à la version 1.2 et la strategie de l'éditeur vis à vis de l'open source est "changeante". De meme, je n'ai jamais lu/entendu de retour vis à vis de la version cluster du produit.
  • Autre avantage Zabbix : Il existe une datasource zabbix pour Grafana ! Autre avantage TIG (ou TICK) : Kapacitor pour l'alerting, qui est configurable via chronograf et super puissant !
  • Bonjour, Merci pour ce superbe tuto ! Je voudrais pour ma part exploiter des données exclusivement avec le service snmp et pour cela j'ai vu qu'il y avait un addon sur github : https://github.com/influxdata/telegraf/blob/master/plugins/inputs/snmp/ Je ne comprends pas la marche à suivre pour installer ce plugin dans telegraf. Je ne sais pas quoi faire du fichier snmp.go, pouvez-vous m'aider svp ? Avec mes remerciements anticipés.
  • Bonjour A tous, Au niveau d'influxDb pour la création de la rétention policy, j'ai une erreur : influx -execute ‘CREATE RETENTION POLICY "one_year" ON "influx_db" DURATION 365d’ ERR: error parsing query: found EOF, expected REPLICATION at line 1, char 64 Il faut ajouté REPLICATION 1 au bout : influx -execute ‘CREATE RETENTION POLICY "one_year" ON "influx_db" DURATION 365d REPLICATION 1’ D'après la doc, c'est un paramètre obligatoire : https://docs.influxdata.com/influxdb/v1.7/guides/downsampling_and_retention/ Cordialement
    1. Laisser un commentaire

      Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *


      Ce formulaire est protégé par Google Recaptcha