[TUTO] Monitoring réseau (Telegraf + InfluxDB 1.8 + Grafana)

[.Shad.]

 

   

 

AVERTISSEMENT : Ce tutoriel est adapté à InfluxDB 1.8.x, qui n'est plus la dernière version d'InfluxDB qui existe maintenant en version 2.x, dont le fonctionnement est grandement différent.

1. Préambule

Ce tutoriel est dédié à la mise en service de trois applications qui œuvrent de concert pour récolter (Telegraf), stocker (InfluxDB) et afficher (Grafana) sous la forme désirée des métriques liées à des équipements informatiques.
Les applications sont extrêmement vastes, cela va de la surveillance d'un système domotique, un système d'arrosage piloté par une vanne intelligente par exemple, à la supervision d'une infrastructure réseau, d'un serveur VPS, etc...
Ce trio d'applications va être mis en service par le biais de Docker, un paquet disponible dans le centre de paquets Synology pour les modèles "haut de gamme" du constructeur.

Comme vous le constaterez si vous parcourez les nombreuses pages de commentaires de ce tutoriel, des membres du forum ont activement apporté leur contribution à l'amélioration de ce fil et je les en remercie tous grandement, nous avons tous appris les uns des autres.
Pour illustrer le propos, quelques exemples de tableaux de bord qu'il est possible de réaliser via Grafana :

 

Fig. 1 Supervision d'un serveur Linux sous Debian 10

 

Fig. 2 Mise en place d'un speedtest régulier pour mesurer les performances de sa connexion (@oracle7 @bruno78) 

 

Fig. 3 Supervision combinée d'un DS920+ et d'un RT2600AC (@MilesTEG1)

 

Fig. 4 Supervision d'une Freebox (@bruno78)

 

Fig. 5 Supervision du trafic Wifi d'un routeur RT2600AC (@oracle7)

2. Prérequis

Difficulté : facile-moyenne

Ce tutoriel prend le temps d'expliciter la très grande majorité des commandes, néanmoins, afin de mieux comprendre ce qui est expliqué ici, il est conseillé de prendre connaissance des bases du fonctionnement de Docker, un tutoriel introductif est disponible sur le forum :

Il est également important de savoir se connecter en SSH :

3. Matériel nécessaire

Docker est un logiciel multiplateforme : Linux, Mac, Windows
Ce tutoriel aborde en particulier les spécificités liées à DSM et à son implémentation de Docker, mais il est transposable (surtout via docker-compose) à toutes les machines compatibles. Avoir un NAS n'est donc pas une obligation pour mener ce tutoriel à terme.
Vous pouvez vérifier quels NAS Synology sont capables d'utiliser Docker à cette adresse.

4. Outils et informations utiles

4-A. Docker-compose

Docker-compose est une commande embarquée avec le paquet Docker de Synology, codé en Python et disponible via SSH.
Il permet de structurer, de manière plus analytique qu'un script docker en ligne de commande, les variables, volumes, etc... d'un conteneur au sein d'un fichier au format yaml/yml.
Ce fichier reste après création du conteneur, on conserve ainsi les paramètres de personnalisation de notre image Docker à tout moment.

Pour crée un fichier docker-compose.yml, c'est assez simple :

4-A-1. Linux

Si vous utilisez une distribution avec interface graphique, vous pouvez utiliser l'éditeur de texte embarqué.
Sur DSM, vous avez le paquet éditeur de texte qui convient parfaitement.
En ligne de commande, utilisez l'outil qui vous convient le mieux : vi, vim, nano, emacs, etc...

Conseil : nano est un des éditeurs les plus simples à prendre en main, pour l'installer sur votre NAS (DSM ne l'embarque pas par défaut), vous pouvez télécharger le paquet SynoCli File Tools du dépôt Synocommunity. Je recommande d'ailleurs vivement l'installation de la suite de paquets SynoCli, ils sont très pratiques dès que vous commencez à prendre vos aises avec l'interface en ligne de commande.

4-A-1. Mac

La plupart des éditeurs de texte font l'affaire, sinon via le Terminal.

4-A-1. Windows

Je vous conseille d'utiliser Notepad++
Une fois lancé, aller dans le menu Encodage et vérifier que "Encoder en UTF-8" est sélectionné.
Une fois votre fichier prêt, Enregistrer sous pour nommer le fichier et choisir le type : YAML Ain't Makeup Language (fin de la liste déroulante).

A des fins de simplification du tutoriel, veuillez toujours nommer le fichier docker-compose (hors extension), cela permettra d'exécuter la commande de création de conteneur avec le moins d'arguments possibles.

4-B. Persistance des données

Afin de stocker de manière pérenne les données d'un conteneur, on va créer un dossier par conteneur (ou groupe de conteneurs travaillant ensemble).
A l'installation de Docker sur DSM, un dossier partagé "docker" est automatiquement créé, donc autant l'utiliser pour y stocker nos différents dossiers.
Par exemple, pour Telegraf, le chemin absolu de son dossier sera /volume1/docker/telegraf
Rien ne vous oblige à respecter cette règle.

Quelque soit le dossier choisi, on va généralement y placer le fichier docker-compose.yml 

4-C. SNMP

Aucune connaissance réellement nécessaire pour la stricte application du tutoriel, mais si vous comptez faire de la surveillance d'autres équipements réseaux, ce sera incontournable d'en comprendre le fonctionnement global.
On trouve la plupart des informations sur la page wikipédia (notamment les deux premiers paragraphes).

4-D. Fichiers MIB

Les fichiers MIB traduisent traduisent et mettent en forme pour les humains les données qui sont mises à disposition par un système pour sa supervision.
Exemple : .1.3.6.1.4.1.6574.5 => synologyDiskSMART
La suite de caractères à gauche de la flèche est un OID, et à droite son nom : synologyDiskSMART. L'OID se construit via une arborescence : pour inspecter les sous-catégories de synologyDiskSMART, l'OID va s'enrichir de nouveaux caractères :

.1.3.6.1.4.1.6574.5.1  => diskSMARTInfoIndex
.1.3.6.1.4.1.6574.5.7  => diskSMARTAttrThreshold
.1.3.6.1.4.1.6574.5.9  => diskSMARTAttrStatus

Ainsi de suite...

Synology met à disposition un PDF comprenant la liste non exhaustive des OID principaux disponibles dans DSM.

5. Serveur SNMP

Pour pouvoir récolter les informations mises à disposition par le NAS, il faut d'abord activer le serveur SNMP, désactivé par défaut.
Pour y remédier, on va dans Panneau de configuration -> Terminal & SNMP -> SNMP pour arriver à l'écran suivant :

Fig. 6 Activation du protocole SNMP

Remarques :
- SNMPv2 est parfaitement adapté à une utilisation locale. Si vous souhaitiez superviser un NAS distant depuis votre NAS local, SNMPv3 est un choix plus avisé de par sa sécurité renforcée.
- Je vous recommande de changer le nom de la communauté, j'utilise la logique suivante pour nommer mes périphériques :
<nom_du_périphérique><suite_de_chiffres_XYZ>
Exemples : vpsXYZ, nas1XYZ, raspberrypiXYZ, etc... 
- Au niveau du pare-feu, veuillez vous assurer d'avoir autorisé la plage d'IP 172.16.0.0/255.240.0.0 à communiquer avec le NAS, c'est la plage d'IP utilisée par Docker. A minima, autorisez le port UDP 161 depuis cette plage IP, si vous ne souhaitez pas autoriser tous les ports.

6. Alchimie

L'ensemble de ces trois applications, qu'on retrouve parfois sous l'appellation TIG (Telegraf InfluxDB Grafana), opère de la sorte :

- Telegraf
C'est un agent de récupération de métriques (entendez des données relatives au fonctionnement du système que vous souhaitez surveiller).
- InfluxDB
InfluxDB est une base de données qui va stocker les métriques recueillies par Telegraf.
- Grafana
C'est un outil de supervision et d'agrégation de métriques, ce qui va nous permettre de manipuler les données stockées dans InfluxDB.

7. Mise en place

7-A. Images

On télécharge les trois images docker suivantes (voir tutoriel introductif) :

telegraf
influxdb:1.8
grafana/grafana

ATTENTION :
InfluxDB 2.x nécessite une configuration totalement et un usage au sein de Grafana totalement différents de ce qui est abordé par la suite.
Ce tutoriel ne s'adresse donc qu'aux installations utilisant les versions 1.x de InfluxDB.

7-B. Création d'un réseau bridge personnalisé (user-defined bridge network)

Pour permettre la communication entre deux conteneurs, on distingue deux méthodes :

7-B-1. Lien

On utilise la fonction de lien (link) présente dans l'interface de création d'un conteneur sur DSM qui pointe vers le conteneur avec lequel on souhaite établir une communication.
Cette méthode fonctionne encore, mais est dépréciée par Docker.

7-B-2. Réseau

Il y a deux catégories de réseau bridge : le réseau bridge par défaut et le réseau bridge personnalisé.

7-B-2-a. Bridge par défaut

Le conteneur est isolé dans le sous-réseau 172.17.0.0/255.255.0.0
Depuis le conteneur, le NAS est accessible à l'adresse 172.17.0.1, il est sa passerelle vers le monde extérieur. Un conteneur attaché à ce réseau est joignable uniquement par son IP (pas de résolution DNS possible).

7-B-2-b. Bridge personnalisé

C'est un réseau créé par l'utilisateur. Tous les conteneurs qui feront partie de ce réseau pourront communiquer via leur nom de conteneur, cette résolution DNS est extrêmement pratique car elle ne fait pas intervenir les IP qui peuvent être amenées à changer d'une fois à l'autre.
Via docker-compose, si on ne précise rien concernant le réseau dans le fichier docker-compose.yml, Docker créera un réseau bridge personnalisé dédié au(x) service(s) de façon automatique. C'est ce qu'on appelle un réseau interne, car il est créé dans la foulée de la mise en route d'un service
Ici, nous allons créer un réseau externe, comme ça même si tous les conteneurs sont supprimés, le réseau persiste et est prêt à accueillir de nouveaux conteneurs.

Remarque :
Au sein d'un réseau bridge personnalisé, les ports des conteneurs sont intégralement exposés les uns envers les autres, il est donc primordial de ne placer dans un même réseau que des conteneurs qui ont vocation à communiquer entre eux.

7-B-2-b-1.  Par DSM

Pour créer un réseau bridge personnalisé sur DSM, c'est très simple, on clique sur le paquet Docker -> Réseau -> Ajouter ->

 

Fig. 7 Création du réseau bridge personnalisé via DSM

On peut tout à fait choisir d'obtenir une configuration automatique, mais cela ne coûte pas bien plus cher de définir la configuration de notre réseau.
Tous nos conteneurs auront des IP dans la plage 172.18.0.1 à 172.18.0.254, l'adresse 172.18.0.1 étant réservée au NAS (passerelle), à la manière du réseau bridge par défaut.
On valide, le réseau est maintenant créé, il suffira d'indiquer à nos conteneurs de s'y connecter à leur création.

7-B-2-b-2.  Par ligne de commande (CLI)

Alternative à l'interface DSM, via SSH, on tape la commande suivante :

docker network create -d bridge \
--subnet=172.18.0.0/24 \
--gateway=172.18.0.1 \
--opt "com.docker.network.bridge.name"="br_monitoring" \
monitoring

L'avantage avec cette méthode est qu'on définit le nom de l'interface, sinon une suite de caractères aléatoires est générée, utiliser ifconfig pour le vérifier.

Remarques :
- Penser à ajouter "sudo" devant la commande si vous n'êtes pas connecté en root.
- Il est possible de faire rejoindre d'autres réseaux à un conteneur après sa création, voir dans la documentation officielle de Docker.

7-C. Docker-compose : fichiers multiples ou fichier unique

Un fichier docker-compose a l'avantage de pouvoir gérer plusieurs services simultanément (un service entrainant la création d'un conteneur), définir un ordre de démarrage, des paramètres (volumes et réseaux par exemple) communs, etc...
La méthode du fichier unique est donc toute indiquée ici, car nos conteneurs sont dépendants les uns des autres.
Cependant, à des fins didactiques, je proposerai pour chacune des applications un code autonome.
Je présente dans un premier temps la méthode avec des fichiers séparés, rendez-vous au point 9. pour des détails concernant l'utilisation d'un fichier unique.

8. Création des conteneurs

8-A. InfluxDB

8-A-1. Configuration

L'ordre dans lequel on ajoute les services dans le fichier docker-compose.yml n'a pas d'importance, c'est le paramètre "depends_on" qui permettra de définir un ordre de mise en route (uniquement pour un fichier unique, voir plus loin).
Commençons par définir les paramètres de notre conteneur InfluxDB. La liste des variables d'environnement pour InfluxDB est disponible à cette adresse. Cela peut être utile si vous souhaitez définir une police de rétention des données.

On crée un dossier influxdb dans le dossier partagé docker, soit par File Station, soit en SSH :

mkdir /volume1/docker/influxdb

Puis on va créer le fichier docker-compose.yml :

IMPORTANT:
Un fichier docker-compose.yml n'accepte pas les tabulations !!! Seuls les espaces sont acceptés !!

version: '2.1'
services:

   influxdb:
      image: influxdb:1.8
      container_name: influxdb
      networks:
         - monitoring
      environment:
         - INFLUXDB_DB=nas_telegraf
         - INFLUXDB_ADMIN_USER=admin
         - INFLUXDB_ADMIN_PASSWORD=admin
         - INFLUXDB_USER=nas_telegraf
         - INFLUXDB_USER_PASSWORD=nas_telegraf
         - INFLUXDB_HTTP_AUTH_ENABLED=true
         - INFLUXDB_META_RETENTION_AUTOCREATE=false
#      ports:              # Optionnel
#         - 8086:8086      # Optionnel
      volumes:
         - /volume1/docker/influxdb/data:/var/lib/influxdb
      restart: unless-stopped
        
networks:
   monitoring:
      external: true

Une fois ceci fait, on se place dans le répertoire d'InfluxDB :

cd /volume1/docker/influxdb

On va devoir créer un dossier data dans le dossier présent :

mkdir data

Puis :

docker-compose up -d

En cas d'erreur, pour supprimer un conteneur par docker-compose, c'est tout simplement :

docker-compose down

Remarques :
Concernant la forme, le nombre d'espaces n'a pas d'importance, le tout étant de garder la même logique, et d'aligner les éléments comme proposé.
Concernant le fond :
- On a défini un nom pour notre conteneur : influxdb
- On a créé une base de données par défaut => nas_telegraf
- On a créé un utilisateur administrateur pour gérer l'ensemble des base de données dans InfluxDB => admin / admin
- On a créé un utilisateur avec les droits de lecture et écriture sur la base de données nas_telegraf => nas_telegraf / nas_telegraf
- On a activé l'authentification HTTP (nécessaire pour que les autres variables d'environnement soient prises en compte).
- Le dossier data créé ci-avant comportera ce qu'on trouvera dans le conteneur dans son dossier /var/lib/influxdb.
Autre remarque :
Ici on n'utilise pas la dernière version d'InfluxDB mais on précise qu'on souhaite avoir la version 1.8 (dans image), car les versions 1.8.x sont les dernières supportées par ce tutoriel.

ATTENTION :
Il est important de noter que la translation de ports n'est nécessaire que si d'autres périphériques doivent accéder à cette instance d'InfluxDB. Par exemple un conteneur Telegraf sur un Raspberry Pi qui enverrait ses données vers InfluxDB. Par défaut, je commente (avec le # en début de ligne) les lignes relatives à la translation de ports. En effet, les trois applications étant dans le même réseau personnalisé, tous leurs ports sont exposés les uns aux autres, aucun besoin de redirection en ce cas. Si on souhaite que des instances Telegraf externes au NAS (sur une autre machine du réseau), décommentez la définition des ports (supprimez les #), supprimez le conteneur et recréez-le.

8-A-2. Définition de la police de rétention des données

Par défaut, InfluxDB attribue des polices de rétention de données d'une durée d'un an si on ne lui dit pas de faire autrement.
Or un an peut paraître excessif lorsque parfois seuls les derniers jours ou semaines nous intéressent.
C'est le but de la variable d'environnement :

- INFLUXDB_META_RETENTION_AUTOCREATE=false

définie dans le fichier docker-compose ci-avant.
En revanche, il est donc nécessaire d'en définir une manuellement après création du conteneur.

Pour se faire, on va dans le terminal et ton tape la commande suivante :

docker exec -it influxdb influx -username admin -password admin

Ce qui va nous faire entrer dans l'interpréteur de requête propre au conteneur InfluxDB :

On doit d'abord préciser quelle base de données utiliser :

USE nas_telegraf

Puis on va, par exemple, créer une police de rétention nommé rp_8w de 8 semaines pour notre instance nas_telegraf :

CREATE RETENTION POLICY "rp_8w" ON "nas_telegraf" DURATION 8w REPLICATION 1 DEFAULT

Pour s'assurer que ça a fonctionné, on tape la commande suivante :

SHOW RETENTION POLICIES

Qui doit renvoyer une liste de polices de rétention pour cette base de données :

Pour sortir du conteneur, on tape simplement exit.

Notre instance InfluxDB est donc maintenant prête à accueillir des données depuis Telegraf.

8-B. Telegraf

MISE A JOUR : depuis la version 1.20.3 de Telegraf, il est nécessaire de créer un utilisateur dédié à Telegraf pour pouvoir l'exploiter de manière sécurisée. 
C'est donc la première étape à réaliser.

8-B-1. Création d'un utilisateur dédié

On commence par se rendre dans DSM, et on va dans Panneau de configuration -> Utilisateur -> Créer.
A l'écran de sélection des groupes, on l'adjoint au groupe docker.

Fig. 8 Ajout de l'utilisateur telegraf au groupe docker

On s'assure que cette appartenance lui confère les droits nécessaires sur le dossier partagé docker :

On peut également lui refuser l'accès à toutes les applications de DSM :

Fig. 9 Suppression des droits d'utilisation des applications Synology

Ceci fait, on a un utilisateur dédié pour Telegraf. En réalité, cette étape n'était pas nécessaire pour son utilisation la plus basique, à savoir superviser les informations données par DSM.
Ce sera nécessaire si l'on souhaite superviser Docker ou d'autres éléments du système non pris en charge nativement par les fichiers MIB de Synology (voir plus loin).

On cherche à connaître les ID de l'utilisateur telegraf et du groupe docker :

id telegraf

Dans cet exemple, ce seraient les valeurs 1040 et 65536 qui nous intéressent. Prenez-en note.
On les insèrera dans le fichier docker-compose (point 8-B-4).

8-B-2. Génération du fichier de configuration

Telegraf utilise un fichier de configuration .conf, qu'on va générer en amont de la création du conteneur.
Comme pour InfluxDB on crée un dossier telegraf :

mkdir /volume1/docker/telegraf

Puis on va dans le dossier de Telegraf :

cd /volume1/docker/telegraf

Puis :

docker run --rm telegraf telegraf config > telegraf.conf

Un fichier telegraf.conf va apparaître dans le dossier, avant de l'éditer je vous conseille d'en faire une copie, en SSH il suffit de taper la commande suivante (merci @unPixel pour la suggestion) :

cp telegraf.conf telegraf.conf.back

Maintenant qu'on a créé tous les fichiers dont on a besoin, on va lancer File Station, et se rendre dans le dossier partagé docker, on clic droit sur le dossier telegraf, puis on va successivement choisir, dans l'onglet Propriétaire, le groupe users (vérifiez bien que c'est un groupe, on distingue deux personnages au lieu d'un devant son nom) et l'utilisateur telegraf. L'option d'application à tous les dossiers et fichiers enfants doit également être cochée dans les deux cas.

Fig. 10 & 11 Application des ACL au dossier telegraf

Pour la suite, libre à vous d'éditer le fichier de configuration via File Station et le paquet Éditeur de texte, ou de le faire par le terminal via nano.

8-B-3. Paramétrage

Le fichier de configuration de Telegraf se décompose en trois sections :

- Les paramètres globaux de Telegraf
- Les plugins de sortie
- Les plugins d'entrée

8-B-3-a. Global

Ce sont les paramètres globaux de Telegraf, c'est-à-dire ceux qui s'appliqueront si un plugin ne contient pas une directive contraire (intervalle de récolte des données par exemple).

# Telegraf Configuration
#
# Telegraf is entirely plugin driven. All metrics are gathered from the
# declared inputs, and sent to the declared outputs.
#
# Plugins must be declared in here to be active.
# To deactivate a plugin, comment out the name and any variables.
#
# Use 'telegraf -config telegraf.conf -test' to see what metrics a config
# file would generate.
#
# Environment variables can be used anywhere in this config file, simply prepend
# them with $. For strings the variable must be within quotes (ie, "$STR_VAR"),
# for numbers and booleans they should be plain (ie, $INT_VAR, $BOOL_VAR)


# Global tags can be specified here in key="value" format.
[global_tags]
  # dc = "us-east-1" # will tag all metrics with dc=us-east-1
  # rack = "1a"
  ## Environment variables can be used as tags, and throughout the config file
  # user = "$USER"


# Configuration for telegraf agent
[agent]
  ## Default data collection interval for all inputs
  interval = "60s"
  ## Rounds collection interval to 'interval'
  ## ie, if interval="10s" then always collect on :00, :10, :20, etc.
  round_interval = true

  ## Telegraf will send metrics to outputs in batches of at most
  ## metric_batch_size metrics.
  ## This controls the size of writes that Telegraf sends to output plugins.
  metric_batch_size = 1000

  ## For failed writes, telegraf will cache metric_buffer_limit metrics for each
  ## output, and will flush this buffer on a successful write. Oldest metrics
  ## are dropped first when this buffer fills.
  ## This buffer only fills when writes fail to output plugin(s).
  metric_buffer_limit = 10000

  ## Collection jitter is used to jitter the collection by a random amount.
  ## Each plugin will sleep for a random time within jitter before collecting.
  ## This can be used to avoid many plugins querying things like sysfs at the
  ## same time, which can have a measurable effect on the system.
  collection_jitter = "0s"

  ## Default flushing interval for all outputs. Maximum flush_interval will be
  ## flush_interval + flush_jitter
  flush_interval = "10s"
  ## Jitter the flush interval by a random amount. This is primarily to avoid
  ## large write spikes for users running a large number of telegraf instances.
  ## ie, a jitter of 5s and interval 10s means flushes will happen every 10-15s
  flush_jitter = "0s"

  ## By default or when set to "0s", precision will be set to the same
  ## timestamp order as the collection interval, with the maximum being 1s.
  ##   ie, when interval = "10s", precision will be "1s"
  ##       when interval = "250ms", precision will be "1ms"
  ## Precision will NOT be used for service inputs. It is up to each individual
  ## service input to set the timestamp at the appropriate precision.
  ## Valid time units are "ns", "us" (or "µs"), "ms", "s".
  precision = ""

  ## Logging configuration:
  ## Run telegraf with debug log messages.
  debug = true
  ## Run telegraf in quiet mode (error log messages only).
  quiet = false
  ## Specify the log file name. The empty string means to log to stderr.
  logfile = ""

  ## Override default hostname, if empty use os.Hostname()
  hostname = ""
  ## If set to true, do no set the "host" tag in the telegraf agent.
  omit_hostname = false

Les champs importants sont :
- le champ interval dans la section [agent] : il définit à quel intervalle les données sont récoltées, 60s est un bon compromis.
- le champ debug dans la même section : le passer à true passe le niveau de verbosité à debug, c'est un réglage que je conseille pour une première mise en route, cela vous aidera à diagnostiquer les dysfonctionnements.

8-B-3-b. InfluxDB

###############################################################################
#                            OUTPUT PLUGINS                                   #
###############################################################################

# Configuration for sending metrics to InfluxDB
[[outputs.influxdb]]
  ## The full HTTP or UDP URL for your InfluxDB instance.
  ##
  ## Multiple URLs can be specified for a single cluster, only ONE of the
  ## urls will be written to each interval.
  # urls = ["unix:///var/run/influxdb.sock"]
  # urls = ["udp://127.0.0.1:8089"]
  # urls = ["http://127.0.0.1:8086"]
    urls = ["http://influxdb:8086"]

  ## The target database for metrics; will be created as needed.
  ## For UDP url endpoint database needs to be configured on server side.
    database = "nas_telegraf"

  ## The value of this tag will be used to determine the database.  If this
  ## tag is not set the 'database' option is used as the default.
  # database_tag = ""

  ## If true, no CREATE DATABASE queries will be sent.  Set to true when using
  ## Telegraf with a user without permissions to create databases or when the
  ## database already exists.
    skip_database_creation = true

  ## Name of existing retention policy to write to.  Empty string writes to
  ## the default retention policy.  Only takes effect when using HTTP.
    retention_policy = ""

  ## Write consistency (clusters only), can be: "any", "one", "quorum", "all".
  ## Only takes effect when using HTTP.
  # write_consistency = "any"

  ## Timeout for HTTP messages.
    timeout = "5s"

  ## HTTP Basic Auth
    username = "nas_telegraf"
    password = "nas_telegraf"

  ## HTTP User-Agent
  # user_agent = "telegraf"

  ## UDP payload size is the maximum packet size to send.
  # udp_payload = "512B"

  ## Optional TLS Config for use on HTTP connections.
  # tls_ca = "/etc/telegraf/ca.pem"
  # tls_cert = "/etc/telegraf/cert.pem"
  # tls_key = "/etc/telegraf/key.pem"
  ## Use TLS but skip chain & host verification
  # insecure_skip_verify = false

  ## HTTP Proxy override, if unset values the standard proxy environment
  ## variables are consulted to determine which proxy, if any, should be used.
  # http_proxy = "http://corporate.proxy:3128"

  ## Additional HTTP headers
  # http_headers = {"X-Special-Header" = "Special-Value"}

  ## HTTP Content-Encoding for write request body, can be set to "gzip" to
  ## compress body or "identity" to apply no encoding.
  # content_encoding = "identity"

  ## When true, Telegraf will output unsigned integers as unsigned values,
  ## i.e.: "42u".  You will need a version of InfluxDB supporting unsigned
  ## integer values.  Enabling this option will result in field type errors if
  ## existing data has been written.
  # influx_uint_support = false

Remarques :
- urls = ["http://influxdb:8086"] -> Si vous avez bien suivi, notre conteneur Telegraf peut contacter InfluxDB directement par son nom de conteneur, et tous les ports étant exposés entre eux, on peut l'écrire de la sorte.
- database = "nas_telegraf" -> c'est le nom qu'on a donné à notre base de données lors de la création du conteneur influxdb (variable d'environnement INFLUXDB_DB).
- skip_database_creation = true -> créée en même temps que le conteneur influxdb, on peut régler cette option sur "true".
- HTTP Basic Auth : on entre le nom d'utilisateur et le mot de passe (respectivement les variables d'environnement INFLUXDB_USER et INFLUXDB_USER_PASSWORD) qu'on a également définis dans notre fichier docker-compose pour InfluxDB : nas_telegraf / nas_telegraf

En l'état, le fichier de configuration est suffisamment paramétré pour envoyer certaines données que Telegraf collecte par défaut à notre base de données InfluxDB : CPU, mémoire, kernel, etc...
C'est là que vont intervenir les fichiers MIB, ceux-ci permettent une supervision plus poussée du NAS, mais pour cela il va falloir donner à Telegraf les OID relatifs aux informations que Synology fournit via SNMP.

8-B-3-c. SNMP

Pour cela on peut se baser sur le travail de jperillo sur Github, notamment son listing des OID de DSM.
Au fil des mois, les différents contributeurs de ce tutoriel ont fourni une aide précieuse pour compléter les OID liés au monitoring d'un onduleur branché au NAS, vous retrouverez dans le fichier suivant une version plus complète que ce proposé sur le lien ci-dessus : snmp-dsm.conf
Le contenu de ce fichier est à placer juste après le début de la section INPUT PLUGINS.

Il reste quelques champs à personnaliser.

8-B-3-c-1.  agents

agents = [  "xxx.xxx.xxx.xxx", "xxx.xxx.xxx.xxx" ]

Ce sont les IP des NAS à superviser, vous pouvez parfaitement passer par l'IP passerelle du NAS sur lequel Telegraf est installé : 172.18.0.1 (si le réseau bridge utilisé est 172.18.0.0, à adapter au besoin).
Si vous souhaitez superviser d'autres NAS, il faut entrer l'IP par laquelle vous-même les contacteriez : IP locale si sur le réseau local, IP publique si NAS à distance, etc...
Si vous ne supervisez qu'un seul NAS, pensez à supprimer la virgule et le deuxième bloc IP :

agents = [  "xxx.xxx.xxx.xxx" ]

8-B-3-c-2.  community

On pense à changer le nom de la communauté si on l'a modifié dans DSM.

8-B-3-c-3.  interval

Intervalle entre chaque récolte de données (écrase la valeur donnée dans les paramètres généraux de Telegraf pour ce plugin uniquement).

8-B-4. Fichier docker-compose

version: '2.1'
services:

   telegraf:
      image: telegraf
      container_name: telegraf
      networks:
         - monitoring
      user: 1040:65536        # A adapter suivant vos valeurs
#      ports:                 # Optionnel
#         - 8125:8125         # Optionnel
#         - 8092:8092/udp     # Optionnel
#         - 8094:8094         # Optionnel
      volumes:
         - /volume1/docker/telegraf/telegraf.conf:/etc/telegraf/telegraf.conf:ro
         - /usr/share/snmp/mibs:/usr/share/snmp/mibs:ro
         - /etc/localtime:/etc/localtime:ro
         - /etc/TZ:/etc/timezone:ro
      restart: unless-stopped
        
networks:
   monitoring:
      external: true

On vérifie qu'on se trouve bien dans /volume1/docker/telegraf puis :

docker-compose up -d

Remarques :
- Le suffixe ":ro" à la fin du montage de volume signifie read-only (lecture seule), pour éviter toute modification indésirable des fichiers par le conteneur.
- Les fichiers MIB de Synology sont déjà présents sur le NAS, on va donc monter le dossier dans le conteneur pour que Telegraf y ait accès.
- Si votre instance Telegraf collecte les données d'un NAS distant, et que l'hôte de Telegraf n'est pas un NAS Synology, il aura besoin des fichiers MIB disponibles à cette adresse.
- Une fois de plus je n'expose aucun port sur le NAS même, ce serait utile uniquement si je souhaitais qu'un script envoie des données à Telegraf par exemple.
- On spécifie pour le paramètre user les ID relevées au point 8-B-1.

Telegraf va dorénavant envoyer périodiquement les métriques à InfluxDB, on peut le vérifier en tapant dans le dossier de Telegraf :

docker-compose logs -f

telegraf    | 2021-01-08T23:55:02Z D! [outputs.influxdb] Wrote batch of 469 metrics in 109.726214ms
telegraf    | 2021-01-08T23:55:02Z D! [outputs.influxdb] Buffer fullness: 0 / 10000 metrics
telegraf    | 2021-01-08T23:55:12Z D! [outputs.influxdb] Buffer fullness: 0 / 10000 metrics
telegraf    | 2021-01-08T23:55:22Z D! [outputs.influxdb] Buffer fullness: 0 / 10000 metrics
telegraf    | 2021-01-08T23:55:32Z D! [outputs.influxdb] Wrote batch of 469 metrics in 144.489076ms
telegraf    | 2021-01-08T23:55:32Z D! [outputs.influxdb] Buffer fullness: 0 / 10000 metrics
telegraf    | 2021-01-08T23:55:42Z D! [outputs.influxdb] Buffer fullness: 0 / 10000 metrics
telegraf    | 2021-01-08T23:55:52Z D! [outputs.influxdb] Buffer fullness: 0 / 10000 metrics
telegraf    | 2021-01-08T23:56:02Z D! [outputs.influxdb] Wrote batch of 469 metrics in 145.368898ms
telegraf    | 2021-01-08T23:56:02Z D! [outputs.influxdb] Buffer fullness: 0 / 10000 metrics
telegraf    | 2021-01-08T23:56:12Z D! [outputs.influxdb] Buffer fullness: 0 / 10000 metrics
telegraf    | 2021-01-08T23:56:22Z D! [outputs.influxdb] Buffer fullness: 0 / 10000 metrics
telegraf    | 2021-01-08T23:56:32Z D! [outputs.influxdb] Wrote batch of 469 metrics in 119.228603ms
telegraf    | 2021-01-08T23:56:32Z D! [outputs.influxdb] Buffer fullness: 0 / 10000 metrics
telegraf    | 2021-01-08T23:56:42Z D! [outputs.influxdb] Buffer fullness: 0 / 10000 metrics

et vérifier dans InfluxDB également en se plaçant dans son dossier et en utilisant la même commande :

[httpd] 172.18.0.3,172.18.0.2 - nas_telegraf [08/Jan/2021:23:59:07 +0000] "POST /write?consistency=any&db=nas_telegraf HTTP/1.1" 204 0 "-" "Telegraf/1.16.3 Go/1.15.2" 7e616302-520d-11eb-aead-0242ac130002 15706

8-C. Grafana

8-C-1. Fichier docker-compose

Il ne reste plus qu'à configurer Grafana pour pouvoir visualiser les données stockées dans InfluxDB.
Comme pour les deux autres conteneurs, on crée un dossier dédié pour Grafana, et un dossier data dans ce dernier.

version: '2.1'
services:

   grafana:
      image: grafana/grafana
      container_name: grafana
      networks:
         - monitoring
      volumes:
         - /volume1/docker/grafana/data:/var/lib/grafana
      ports:
         - 3000:3000
      restart: unless-stopped
        
networks:
   monitoring:
      external: true

A la différence des autres logiciels, on va devoir ici étendre les permissions du dossier contenant les données de Grafana à tous les utilisateurs :

cd /volume1/docker/grafana
chmod 777 data

Puis :

docker-compose up -d

Remarques :
- Ici je suis forcé de translater le port correspondant à l'interface de Grafana si je souhaite pouvoir y accéder d'une autre machine que le NAS, ce qui sera nécessairement le cas.
- Il est possible d'accéder à Grafana au travers d'un proxy inversé.

8-C-2. Création de la source de données

On se rend sur la page http://IP_DU_NAS:3000 (ou le port qu'on a choisi) pour accéder à Grafana :

Fig. 12 Page d'authentification de Grafana

Les accès par défaut sont admin/admin, la première fois qu'on se connecte on nous invite à changer le mot de passe du compte admin.

Fig. 13 Écran d'accueil de Grafana

On suit les indications de Grafana et on commence par ajouter la source de données, ici notre conteneur InfluxDB. On clique sur Add data source. On choisit InfluxDB.

On remplit ensuite l'écran suivant de la sorte :

Fig. 14 Configuration de la source de données InfluxDB pour les données du NAS

Remarques :
- On donne un nom à notre datasource, ici j'ai choisi NAS_InfluxDB.
- influxdb dans http://influxdb:8086 représente le nom que vous avez donné au conteneur.
- On coche Basic Auth car on a activé l'authentification http à la création du conteneur InfluxDB.
- Les informations à entrer dans "InfluxDB Details" correspondent aux variables d'environnement du conteneur InfluxDB :

• Database : INFLUXDB_DB
• User : INFLUXDB_USER
• Password : INFLUXDB_USER_PASSWORD

- Basic Auth Details :

• User : INFLUXDB_USER
• Password : INFLUXDB_USER_PASSWORD

On clique sur Save & Test, on obtient un message écrit en vert Datasource is working si tout est bien paramétré.

8-C-3. Création d'un tableau de bord (dashboard)

On peut soit créer son propre tableau de bord, soit en importer un, pour cela il suffit d'aller sur le site de Grafana, plus précisément sur cette page.
En tapant Synology dans le cadre de recherche, on peut par exemple choisir le tableau de bord de Yann Bizeul.

Fig. 15 Page du tableau de bord publique de Yann Bizeul sur le site de Grafana

On clique sur "Copy ID to Clipboard", on retourne sur notre instance de Grafana et on clique sur import dans le menu rapide à la gauche de l'écran :

Fig. 16 Importation d'un tableau de bord 1/2

Dans l'écran suivant on colle dans "Grafana.com dashboard" le numéro de du tableau de bord qu'on a choisi.
On valide en cliquant sur "Load" et on arrive sur l'écran suivant :

Fig. 17 Importation d'un tableau de bord 2/2

Dans InfluxDB on choisit la datasource définie ci-avant, on valide en cliquant sur "Import".

Il est aussi possible d'importer des tableaux de bord depuis un fichier JSON, n'hésitez pas à en demander sur ce fil, plusieurs des participants sont prêts à partager les leurs (impressions d'écran en début de tutoriel).

 9. Fichier docker-compose unique

Si on avait voulu le définir en un seul fichier, on aurait pu faire ainsi :

- Créer un dossier monitoring dans /volume1/docker :

cd /volume1/docker
mkdir monitoring

Puis créer des dossiers data pour InfluxDB et Grafana :

mkdir influxdb-data grafana-data telegraf-data

Et créer enfin un fichier docker-compose.yml :

version: '2.1'
services:

   influxdb:
      image: influxdb:1.8
      container_name: influxdb
      networks:
         - monitoring
      environment:
         - INFLUXDB_DB=nas_telegraf
         - INFLUXDB_ADMIN_USER=admin
         - INFLUXDB_ADMIN_PASSWORD=admin
         - INFLUXDB_USER=nas_telegraf
         - INFLUXDB_USER_PASSWORD=nas_telegraf
         - INFLUXDB_HTTP_AUTH_ENABLED=true
         - INFLUXDB_META_RETENTION_AUTOCREATE=false
#      ports:                 # Optionnel
#         - 8086:8086         # Optionnel
      volumes:
         - /volume1/docker/monitoring/influxdb-data:/var/lib/influxdb
      restart: unless-stopped

   grafana:
      image: grafana/grafana
      container_name: grafana
      networks:
         - monitoring
      volumes:
         - /volume1/docker/monitoring/grafana-data:/var/lib/grafana
      ports:
         - 3000:3000
      depends_on:
         - telegraf
         - influxdb
      restart: unless-stopped

   telegraf:
      image: telegraf
      container_name: telegraf
      networks:
         - monitoring
      user: 1040:65536        # A adapter suivant vos valeurs
#      ports:                 # Optionnel
#         - 8125:8125         # Optionnel
#         - 8092:8092/udp     # Optionnel
#         - 8094:8094         # Optionnel
      depends_on:
         - influxdb
      volumes:
         - /volume1/docker/monitoring/telegraf-data/telegraf.conf:/etc/telegraf/telegraf.conf:ro
         - /usr/share/snmp/mibs:/usr/share/snmp/mibs:ro
         - /etc/localtime:/etc/localtime:ro
         - /etc/TZ:/etc/timezone:ro
      restart: unless-stopped
        
networks:
   monitoring:
      external: true

__________________________________________

10. Supervision de Docker

La manipulation est très simple, dans le fichier telegraf.conf, il suffit de décommenter les options qui nous intéressent.
Il y a possibilité de trier les conteneurs dont on souhaite réaliser la surveillance suivant différents critères : nom, état, label...

# # Read metrics about docker containers
  [[inputs.docker]]
#   ## Docker Endpoint
#   ##   To use TCP, set endpoint = "tcp://[ip]:[port]"
#   ##   To use environment variables (ie, docker-machine), set endpoint = "ENV"
    endpoint = "unix:///var/run/docker.sock"
#
#   ## Set to true to collect Swarm metrics(desired_replicas, running_replicas)
#   gather_services = false
#
#   ## Set the source tag for the metrics to the container ID hostname, eg first 12 chars
#   source_tag = false
#
#   ## Containers to include and exclude. Globs accepted.
#   ## Note that an empty array for both will include all containers
#   container_name_include = []
#   container_name_exclude = []
#
#   ## Container states to include and exclude. Globs accepted.
#   ## When empty only containers in the "running" state will be captured.
#   ## example: container_state_include = ["created", "restarting", "running", "removing", "paused", "exited", "dead"]
#   ## example: container_state_exclude = ["created", "restarting", "running", "removing", "paused", "exited", "dead"]
    container_state_include = [ "created" , "restarting" , "running" , "removing" , "paused" , "exited" , "dead" ]
    container_state_exclude = []
#
#   ## Timeout for docker list, info, and stats commands
#   timeout = "5s"
#
#   ## Specifies for which classes a per-device metric should be issued
#   ## Possible values are 'cpu' (cpu0, cpu1, ...), 'blkio' (8:0, 8:1, ...) and 'network' (eth0, eth1, ...)
#   ## Please note that this setting has no effect if 'perdevice' is set to 'true'
    perdevice_include = [ "cpu" , "blkio" , "network" ]
#
#   ## Specifies for which classes a total metric should be issued. Total is an aggregated of the 'perdevice' values.
#   ## Possible values are 'cpu', 'blkio' and 'network'
#   ## Total 'cpu' is reported directly by Docker daemon, and 'network' and 'blkio' totals are aggregated by this plugin.
#   ## Please note that this setting has no effect if 'total' is set to 'false'
    total_include = [ "cpu" , "blkio" , "network" ]
#
#   ## Which environment variables should we use as a tag
#   ##tag_env = ["JAVA_HOME", "HEAP_SIZE"]
#
#   ## docker labels to include and exclude as tags.  Globs accepted.
#   ## Note that an empty array for both will include all labels as tags
#   docker_label_include = []
#   docker_label_exclude = []
#
#   ## Optional TLS Config
#   # tls_ca = "/etc/telegraf/ca.pem"
#   # tls_cert = "/etc/telegraf/cert.pem"
#   # tls_key = "/etc/telegraf/key.pem"
#   ## Use TLS but skip chain & host verification
#   # insecure_skip_verify = false

Une étape supplémentaire est nécessaire, il faut qu'on donne accès au fichier docker.sock en lecture seule à Telegraf, il suffit pour cela de rajouter dans le fichier docker-compose de Telegraf (ou pour le fichier unique, le service telegraf) le volume suivant :

- /var/run/docker.sock:/var/run/docker.sock:ro

On relance le conteneur, en SSH via la commande suivante :

docker restart telegraf

11. Supervision de Raspi OS (ou tout autre distribution Linux)

Dans mon cas, j'ai choisi de continuer à utiliser l'instance InfluxDB du NAS et avoir une instance de Telegraf sur le Raspberry Pi, pourquoi ? Vous aurez pu remarquer qu'InfluxDB est friand de mémoire vive.
Donc autant limiter la charge sur le Raspberry Pi, dont les performances sont généralement en deçà d'un modèle de NAS "+".

11-A. Docker

ATTENTION :
Si vous n'avez pas activé l'accès SSH sur votre Raspberry Pi, c'est une option à cocher sur le bureau, le service SSH est désactivé par défaut à l'installation depuis 2016, voir guide ici.
Pour installer Docker sous Raspbian, on passe par le script tout-en-un. Si vous n'utilisez pas Raspbian, mais une Debian, Ubuntu, ou autre... sélectionnez votre système d'exploitation sur cette page et suivez le guide.
Si vous avez une installation précédente de Docker et que vous ne seriez pas passé par cette méthode, vous risquez de vous retrouver avec des versions obsolètes du Docker Engine et donc potentiellement de Docker-compose (merci @Jeff777), veuillez donc avant tout désinstaller Docker et ses reliques en suivant ces étapes.

Remarques :
On n'oublie pas d'ajouter notre utilisateur au groupe docker, ça évitera par la suite de devoir utiliser "sudo" pour chaque commande liée à Docker, pour l'utilisateur "pi" par exemple :

sudo usermod -aG docker pi

Pour que la modification soit effective, il faut redémarrer sa session SSH.

11-B. Docker-compose

Pour installer Docker-compose, on va utiliser la source la plus à jour : pip3
Toujours en SSH :

sudo apt-get install -y libffi-dev libssl-dev python3 python3-pip
sudo pip3 install docker-compose

11-C. Telegraf

On télécharge l'image de Telegraf :

docker pull telegraf

Comme précédemment on va créer un dossier dans lequel stocker notre fichier telegraf.conf, personnellement j'ai utilisé le dossier /opt qui est généralement réservé aux applications tierces :

sudo mkdir -p /opt/containers/telegraf

On va générer le fichier originel telegraf.conf :

cd /opt/containers/telegraf
docker run --rm telegraf telegraf config | sudo tee telegraf.conf

Une fois la configuration faite, on va créer le fichier docker-compose.yml pour Telegraf. On s'inspire du fichier docker-compose qu'on a utilisé pour le NAS, en opérant quelques modifications :

version: '2.1'
services:

   telegraf:
      image: telegraf
      container_name: telegraf
      hostname: raspberrypi
      network_mode: bridge
      environment:
         - HOST_PROC=/hostfs/proc
         - HOST_MOUNT_PREFIX=/hostfs
#      ports:                 # Optionnel
#         - 8125:8125         # Optionnel
#         - 8092:8092/udp     # Optionnel
#         - 8094:8094         # Optionnel
      volumes:
         - /opt/containers/telegraf/telegraf.conf:/etc/telegraf/telegraf.conf:ro
         - /proc:/hostfs/proc:ro
         - /run/udev:/run/udev:ro
         - /etc/localtime:/etc/localtime:ro
         - /etc/timezone:/etc/timezone:ro
      restart: unless-stopped

Remarques :
- Pour plus d'info sur les variables et volumes avec "hostfs", voir : https://github.com/influxdata/telegraf/blob/master/docs/FAQ.md
- On remarquera l'ajout du paramètres hostname, qui permettra de voir un nom à la place d'une suite de chiffres dans Grafana.
- On remarquera également le paramètre network_mode: bridge => Ici je n'ai pas créé de réseau bridge personnalisé, mon conteneur telegraf est tout seul, il peut être donc être dans le réseau bridge par défaut.

Pour l'instant on ne démarre pas le conteneur, il va falloir créer la base de données dans laquelle stocker nos informations.

11-D. Création d'une base de données dans InfluxDB

Rappelez-vous, sur le NAS nous avions précisé dans le fichier telegraf.conf un nom de base de données à utiliser, ainsi que les données d'identification pour les droits d'écriture.
Cette base de données avait été créée à la création du conteneur influxdb, donc il n'y avait rien eu à configurer manuellement. Ici on va stocker les données dans une base de données séparée, donc il va falloir créer un nouvel utilisateur, et une nouvelle base de données.
Pour cela il faut se connecter directement dans le conteneur influxdb du NAS. Donc retour en SSH sur celui-ci.

On se connecte en root et on entre la commande suivante :

docker exec -it influxdb influx -username admin -password admin

Remarques :
docker exec -it influxdb permet la connexion au conteneur influxdb, influx c'est la commande ouvrant la base de données, si on avait écrit bash à la place on serait arrivé sur l'invite de commande propre au conteneur et on aurait pu écrire influx pour faire la même chose, mais en plus long. 😛 
Vu qu'on a activé l'authentification HTTP dans notre conteneur, si on ne précise rien à la connexion, toute tentative de modification se soldera pas un échec dû à un défaut de permission. De plus, vu qu'on souhaite créer de nouveaux éléments, il faut que le compte utilisé ait les pouvoirs d'administration. Il faut donc préciser les données d'authentification administrateur au lancement de la commande influx. Ces données sont celles que l'on avait renseignées à la création du conteneur InfluxDB, dans le tutoriel on a choisi admin / admin comme username / password.

Fig. 14 Connexion à InfluxDB par ligne de commande

Première étape : on crée la base de données, il suffit de taper la commande suivante :

CREATE DATABASE raspi_telegraf

puis on sélectionne la base de données qu'on vient juste de créer :

USE raspi_telegraf

On crée maintenant l'utilisateur dédié au raspberry :

CREATE USER raspi_telegraf WITH PASSWORD 'raspi_telegraf'

On peut également choisir sa police de rétention de données (voir point 8-A-2) :

CREATE RETENTION POLICY "rp_8w" ON "raspi_telegraf" DURATION 8w REPLICATION 1 DEFAULT

Remarques 
- Si on s'est trompé dans l'écriture, il est toujours possible de supprimer un utilisateur ou une base de données avec les commandes DROP USER nom_utilisateur et DROP DATABASE nom_bdd.

On peut vérifier à ce stade que tout se passe bien, il suffit de taper les commandes SHOW DATABASES et SHOW USERS :

Fig. 15 Listing utilisateurs et bases de données dans InfluxDB

La dernière étape consiste à donner des droits à notre utilisateur raspi_telegraf sur la base de données du même nom, ce qui se fait par la commande :

GRANT ALL ON raspi_telegraf TO raspi_telegraf

On tape ensuite exit pour sortir de influx (gestion de la base de données). On relance ensuite le conteneur pour s'assurer que les modifications ont été prises en compte :

docker restart influxdb

On peut maintenant quitter la session SSH sur le NAS et revenir sur celle du Raspberry Pi.

A ce stade, notre base de données est prête à l'emploi, il suffit maintenant de renseigner dans notre fichier telegraf.conf sur le Raspberry Pi les données d'exportation vers influxdb sur le NAS.
On peut le faire avec la commande nano ou vi :

cd /opt/containers/telegraf
nano telegraf.conf

###############################################################################
#                            OUTPUT PLUGINS                                   #
###############################################################################

# Configuration for sending metrics to InfluxDB
[[outputs.influxdb]]
  ## The full HTTP or UDP URL for your InfluxDB instance.
  ##
  ## Multiple URLs can be specified for a single cluster, only ONE of the
  ## urls will be written to each interval.
  # urls = ["unix:///var/run/influxdb.sock"]
  # urls = ["udp://127.0.0.1:8089"]
  # urls = ["http://127.0.0.1:8086"]
    urls = ["http://192.168.0.51:8086"]

  ## The target database for metrics; will be created as needed.
  ## For UDP url endpoint database needs to be configured on server side.
    database = "raspi_telegraf"

  ## The value of this tag will be used to determine the database.  If this
  ## tag is not set the 'database' option is used as the default.
    database_tag = ""

  ## If true, no CREATE DATABASE queries will be sent.  Set to true when using
  ## Telegraf with a user without permissions to create databases or when the
  ## database already exists.
    skip_database_creation = true

  ## Name of existing retention policy to write to.  Empty string writes to
  ## the default retention policy.  Only takes effect when using HTTP.
    retention_policy = ""

  ## Write consistency (clusters only), can be: "any", "one", "quorum", "all".
  ## Only takes effect when using HTTP.
    write_consistency = "any"

  ## Timeout for HTTP messages.
    timeout = "5s"

  ## HTTP Basic Auth
    username = "raspi_telegraf"
    password = "raspi_telegraf"

Notes :
- Dans urls, on doit entrer l'adresse IP locale du NAS (ou son nom NetBios), et préciser le port sur lequel InfluxDB est exposé, par défaut 8086 dans notre installation précédente.
- On s'assure d'avoir exposé le port 8086 du conteneur influxdb sur le NAS (ce qui était optionnel ne l'est plus).
- On pense bien à préciser le nom de la base de données dans database et les login/password de notre utlisateur dans la partie HTTP Basic Auth.
- On passe skip_database_creation à true.

Tout est maintenant configuré sur le Raspberry Pi, il suffit de lancer le conteneur Telegraf :

docker-compose -f /opt/containers/telegraf/docker-compose.yml up -d

L'argument -f permet de créer un conteneur depuis un fichier compose n'importe où, et avec un nom différent de "docker-compose.yml". Cela permet d'éviter de devoir se placer dans le dossier du fichier docker-compose.yml avant d'exécuter la commande.

11-D. Création de la source de données

Direction Grafana => panneau latéral : Configuration (roue dentée) => Datasources
On clique sur Add data source :

Fig. 16 Configuration de la source de données InfluxDB pour les données du Raspberry Pi

On valide, si tout a bien été configuré, on verra le message "Datasource is working" apparaître en vert au moment du clic.

11-D. Création d'un tableau de bord

Il s'agit juste ici de vérifier que les données sont accessibles :

Fig. 17 Exemple de configuration d'une requête

Ici j'ai créé un graphique pour suivre l'état d'utilisation de la mémoire vive :
- On notera le choix de la datasource relative au raspberry.
- Dans la liste "host" vous devriez voir le nom que vous avez précisé dans le champ hostname du script de création du conteneur. Si vous avez laissé le réglage par défaut, il affichera la valeur hostname du système. 

MàJ : 29/03/2022

Modifié le 29 mars 2022 par .Shad.
Re-modification conf inputs.docker

[Einsteinium]

J’ai testé vive fait, mais telegraf (cela a pas changer depuis ?) a du mal avec les mib du synology.

Je vais voir à mettre un équivalent en place, sa peut être utile vue tout ce que j’ai chez moi qui tourne.

[.Shad.]

J'ai reproduit le tuto en repartant de rien de mon côté, pour être certain que c'était faisable, j'ai corrigé pas mal de petites choses, n'hésite pas à réessayer, il se peut que tu aies suivi de mauvaises directives de ma part (notamment la partie HTTP AUTHENTICATION).

Je laisse temporairement de côté la partie ajouter d'autres équipements réseaux, j'ai trouvé des pistes intéressantes mais ça nécessite que j'y consacre du temps avant de les mettre dans un tutoriel.

En équivalent il y a LibreNMS, tout-en-un, mais qui je trouve offre moins de possibilités.

Modifié le 3 juin 2019 par shadowking

[unPixel]

Bravo pour ce tuto qui a l'air bien détaillé 😉

J'avais un soucis pour faire discuter les containers avec ce qui se passait sur le NAS, je vais pouvoir corriger ça 🙂

Merci !

[_Megalegomane_]

Bonjour,

Merci pour ce beau tuto 👍

Est-ce qu'il y a possibilité de suivre l'état des sauvegardes  et réplications de cette façon  ?
De souvenir, il me semble que SNMP ne le permettait pas sur Synology mais ça a peut-être changé depuis... Je suis preneur de l'info 🙂 

[unPixel]

Bon pour ma part, je ne sais pas pourquoi mais ça ne passe pas l'installation des fichiers docker-compose.

 

Voilà l'erreur :

 

Je cherche la cause...

[.Shad.]

Vérifie que tu n'as pas mis de tabulation dans ton fichier docker-compose, ça paraît bête mais ce sont des espaces qu'il faut mettre...
Parallèlement, je t'envoie mon fichier docker-compose.yml par MP.

Ca a peut-être un rapport aussi avec la variable locale, ce que j'ai moi :

Modifié le 3 juin 2019 par shadowking

[unPixel]

J'ai bien des espaces et non tabulations pourtant. Je l'ai même réécrit manuellement dans un nouveau fichier pour tester. J'utilise Sublimetext 3. Peut-être que le soucis vient de ce dernier ou comme je te l'ai dit par MP, des lettres cachées dans ton code.

Ça m'est déjà arrivé sur un tuto que j'avais fait sur le forum avec un script SSH qui ne passait pas quand on le copier coller du forum.

J'avais du le modifier pour m'apercevoir que des lettres étaient cachées.

Merci en tout cas pour le fichier par MP.

Sinon, j'ai ça avec la commande locale :

[.Shad.]

J'ai pas pensé qu'en insérant du code via la balise code ça pourrait poser problème effectivement.
J'ai réécrit les fichiers docker-compose.yml pour les besoins du tutoriel, et ça a marché, donc le conseil que je peux vous donner c'est de les écrire manuellement (l'avantage de docker-compose c'est que vous n'aurez plus à le refaire) en suivant la procédure que j'ai proposée pour ceux qui auraient des soucis d'exécution.
 

[unPixel]

Bon alors comme dit en MP à Shadowking, mon soucis venait de Sublime Text 3. C'est lui qui faisait que mes fichiers étaient erronés.

En les créant avec un autre programme, les containers se sont créés sans poser de soucis.

[.Shad.]

Il y a 5 heures, _Megalegomane_ a dit :

Bonjour,

Merci pour ce beau tuto 👍

Est-ce qu'il y a possibilité de suivre l'état des sauvegardes  et réplications de cette façon  ?
De souvenir, il me semble que SNMP ne le permettait pas sur Synology mais ça a peut-être changé depuis... Je suis preneur de l'info 🙂 

Je ne pense pas que ce soit possible.

[unPixel]

Bon, je reviens donner des nouvelles. Ça ne fonctionne pas de mon côté mais je ne vois pas pourquoi 🙄

L'erreur qui je pense devrai s'afficher en bas de la configuration de la source ne s'affiche pas correctement.

Est-ce qu'il y a des journaux dans Grafana afin de voir les erreurs svp ?

Parce que ça m'affiche ça quand je valide la configuration alors que je suis sûr de ce qui est inscrit :

 

Et ça dans général :

 

J'en profite pour revenir sur le soucis que j'ai eu avec mes fichiers docker-compose. Je confirme bien qu'il y a des caractères cachés. Est-ce du au navigateur, forum, autres, je ne sais pas.

Exemple avec le code qu'il faut placer dans le fichier .conf de telegraf.

Voici une capture d'écran d'un copier coller simple dans le fichier :

C'est bien parce que l'éditeur intégré de DSM m'interpelle directement en me mettant en surbrillance le soucis.

[.Shad.]

J'ai modifié le lien vers GitHub pour les stats du Syno pour Telegraf avec la version RAW du texte directement.
J'ai oublié de préciser qu'on ne copie/colle pas directement depuis la page, c'est vrai que ce n'est pas évident.

Est-ce que tu as déjà bien Influx qui reçoit les données de Telegraf ?
Copie des logs de Influx chez moi :

[unPixel]

Ça a l'air d'être bon de ce côté là :

 

 

Par contre, côté telegraf, j'ai ça dans les logs :

Bien entendu, je suis certain de l'IP locale de mon NAS qui est bien 192.168.10.100 😤

Modifié le 4 juin 2019 par Zeus

[Einsteinium]

Le 01/06/2019 à 15:05, shadowking a dit :

J'ai reproduit le tuto en repartant de rien de mon côté, pour être certain que c'était faisable, j'ai corrigé pas mal de petites choses, n'hésite pas à réessayer, il se peut que tu aies suivi de mauvaises directives de ma part (notamment la partie HTTP AUTHENTICATION).

Je laisse temporairement de côté la partie ajouter d'autres équipements réseaux, j'ai trouvé des pistes intéressantes mais ça nécessite que j'y consacre du temps avant de les mettre dans un tutoriel.

En équivalent il y a LibreNMS, tout-en-un, mais qui je trouve offre moins de possibilités.

Effectivement un caractère à la con, en regardant les logs sa va mieux xD

Sinon on a pas tous envies de passé par docker compose et de donné des droits un peu superflus... ("/proc:/host/proc:ro" et "/usr/share/snmp/mibs:/usr/share/snmp/mibs:ro")

Il suffit juste de faire un cp des tous les mibs du nas (/usr/share/snmp/mibs) et d’en faire le point de montage ensuite.

[unPixel]

Citation

Il suffit juste de faire un cp des tous les mibs du nas (/usr/share/snmp/mibs) et d’en faire le point de montage ensuite.

C'est ce que j'avais fait et j'ai mit la variable dans le docker compose.

Par contre, j'ai pas touché à /proc

Bon, j'ai toujours ce soucis sur telegraf et je comprend vraiment pas pourquoi il ne veut pas de mon IP.

J'ai testé d'autres IP ou domaine comme localhost et j'ai aussi essayé avec le port :161 mais rien n'y fait.

[Einsteinium]

Moi il c’est via interface, qu’en le réseau par défaut en bridge, donc j’ai mis tout simplement 172.17.0.1 (afin de ne pas à avoir à ouvrir de port)

[unPixel]

Citation

Moi il c’est via interface, qu’en le réseau par défaut en bridge

🤔

Tu peux répéter stp 😂

J'ai essayé avec 172.17.0.1 et ça passe pas non plus.

Modifié le 4 juin 2019 par Zeus

[Einsteinium]

Met tes dock en bridge ou regarde l’ip de la passerelle du nouveau réseau créé, cela sera le nas, après j’ai juste testé pour voir granafa car je connaissais pas.

[unPixel]

Non, tu avais raison en faite, ça fonctionne avec 172.17.0.1 comme IP. J'ai recréer le container telegraf parce qu'un redémarrage ne suffisait pas et direct ça fonctionnait.

Bon par contre, l'affichage des infos est limité. Je vais me renseigner pour en ajouter.

[.Shad.]

Il y a 3 heures, Einsteinium a dit :

Effectivement un caractère à la con, en regardant les logs sa va mieux xD

Sinon on a pas tous envies de passé par docker compose et de donné des droits un peu superflus... ("/proc:/host/proc:ro" et "/usr/share/snmp/mibs:/usr/share/snmp/mibs:ro")

Il suffit juste de faire un cp des tous les mibs du nas (/usr/share/snmp/mibs) et d’en faire le point de montage ensuite.

@Einsteinium
Docker-compose c'est tout sauf obligatoire en effet, c'est juste que je trouve ça quand même plus pratique que de la ligne de commande ou que l'interface de Docker sur DSM, donc autant l'expliquer pour ceux que ça intéresse.
LIbre à chacun de faire comme il l'entend. 😄
Quant aux MIBs oui tu peux faire ça, seulement en cas de mise à jour des fichiers par Syno tu ne bénéficieras pas des ajouts/changements éventuels.
De plus, le volume est monté en lecture seule, ça limite l'exposition des fichiers système.
Pour le host/proc:ro, il est précisé dans la doc officielle de telegraf que c'est requis, je ne me suis pas posé plus que ça la question je dois t'avouer... si ça marche sans tant mieux !

@Zeus
Tant mieux si tu as résolu ton problème, d'après les logs j'ai l'impression que telegraf n'arrivait pas à voir ton NAS, avais-tu autorisé les adresses 172.16.0.0/255.240.0.0 dans ton pare-feu pour tous les ports ? Telegraf communique via le port 161 par défaut avec l'hôte. Et en effet, dans chaque réseau docker, le 172.xx.0.1 est ton hôte, donc ça ne m'étonne pas que ça marche aussi ainsi, et c'est même mieux je dirais, car si l'IP de ton NAS devait changer, ça n'aurait aucune répercussion sur la configuration de Telegraf. 😉

Modifié le 4 juin 2019 par shadowking

[unPixel]

Citation

Docker-compose c'est tout sauf obligatoire en effet, c'est juste que je trouve ça quand même plus pratique que de la ligne de commande ou que l'interface de Docker sur DSM, donc autant l'expliquer pour ceux que ça intéresse.

Mouais. J'aime la ligne de commande mais pour moi ça se discute. Là, en l’occurrence, faut avouer que l'interface Docker dans DSM va plus vite que de taper manuellement un fichier docker-compose.

Citation

Quant aux MIBs oui tu peux faire ça, seulement en cas de mise à jour des fichiers par Syno tu ne bénéficieras pas des ajouts/changements éventuels.

Au pire, un petit script qui copie par exemple à chaque redémarrage du NAS les fichiers au bon endroit et voilà 😉

Je le fais déjà personnellement pour les fichiers erreurs html de WebStation.

Citation

Tant mieux si tu as résolu ton problème, d'après les logs j'ai l'impression que telegraf n'arrivait pas à voir ton NAS, avais-tu autorisé les adresses 172.16.0.0/255.240.0.0 dans ton pare-feu pour tous les ports ?

Oui oui, j'ai bien les règles dans mon pare feu. Sauf que l'agent n'était pas l'IP de mon NAS mais l'IP " 172.17.0.1 " du réseau bridge de Docker ce qui est étonnant puisque mes trois containers sont bien dans un réseau créé pour l'occasion qui lui a l'IP "172.19.0.0". Bref, à ne rien y comprendre pour ma part.

 

Par hasard, la copie d'écran de Grafana sur ton tuto vient de toi ? Parce que moi, j'ai pratiquement rien en informations sur l'écran. L'UPS, c'est normal car il est connecté sur un autre serveur mais par exemple, je n'ai pas les statistiques sur le stockage du volume ou encore l'uptime. Merci

[Einsteinium]

@shadowking Tu devrais proposé aussi en version graphique pour les néophytes ou ceux qui comme moi aime bien la version graphique (pour une fois que synology nous fait quelque chose de bien)

[.Shad.]

Non ce n'est pas ma capture d'écran, voici la mienne :

Pour l'UPS, je n'ai pas réussi à récupérer les métriques, visiblement telegraf ne collecte rien à ce sujet, alors que les MIBs le prévoient. Après quelques recherches, je ne suis pas le seul dans ce cas, mais aucun début de solution de mon côté, donc je l'ai sorti des graph.

il y a 11 minutes, Einsteinium a dit :

@shadowking Tu devrais proposé aussi en version graphique pour les néophytes ou ceux qui comme moi aime bien la version graphique (pour une fois que synology nous fait quelque chose de bien)

Je verrai à faire ça quand j'ai le temps oui, je comprends.

[unPixel]

Ah oui en effet, il en manque pas mal de mon côté...

J'ai ça moi :