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)
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 :
Les métriques sont insérées au fil de l’eau dans 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 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.
Dans cet article, nous allons monitorer une architecture simple :
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.
Pour cet article, l’installation se fera sous Ubuntu 16.04 LTS.
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
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
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
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 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.
Les plugins permettant de remonter les métriques systèmes :
$ head /etc/telegraf/telegraf.d/system.conf [[inputs.cpu]]
percpu = true
totalcpu = true
collect_cpu_time = false …
$ head /etc/telegraf/telegraf.d/mysql.conf
[[inputs.mysql]] servers = ["db_user:db_password@tcp(127.0.0.1:3306)/?tls=false"] …
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"]
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
[[inputs.http_listener]]
service_address = ":8186"
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'
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
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
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.
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.
Avantages de TIG :
Avantages de Zabbix :
Avantages de TIG :
Avantages de Prometheus :
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 :
Le cas d’utilisation que nous avons présenté est disponible sur ce repo : https://gitlab.octo.com/tpatte/monitoring_influxdb