.Shad.

Le principe est simple, sur ton routeur tu dois préciser que tu rediriges son port 443 vers celui de ton proxy inversé, donc vers l'adresse IP du NAS. Sur ton pare-feu, tu dois autoriser le trafic sur le port 443 (voir tuto de la sécurisation des NAS de Fenrir), et créer les entrées de proxy inversé qui t'intéressent. Je ne sais pas si tu as un nom de domaine chez un prestataire, ou si tu utilises le paquet serveur DNS, mais il faut créer les entrées CNAME qui correspondent aux entrées du proxy inversé (voir tuto serveur DNS), une fois ceci fait ta redirection devrait fonctionner.

Si tu as moyen d'avoir une IP fixe c'est mieux effectivement, mais ça n'a pas de rapport avec les ports que tu ouvres ou non. Tout dépend des services que tu utilises, mais je pense qu'il te faut au minimum : - port 80 - port 443 (très important, car tu vas utiliser ton proxy inversé pour faire transiter tous tes services par ce port) - port SSH (pas le 22 par défaut, choisis-en un autre et demandes-en l'ouverture) - ports liés à Mail Server si tu comptes héberger ton propre serveur mail (surtout si tu arrives à avoir une IP fixe), voir le tuto à ce sujet pour la liste des ports qui peuvent t'intéresser. - ports VPN éventuellement (pareil voir tuto, suivant le protocole que tu comptes utiliser)

Màj du tuto : j'ai ajouté les fichiers docker-compose directement téléchargeables, pour éviter les problèmes de caractères invisibles.

Hello, Tu aurais une impression d'écran qu'on puisse se faire une idée du problème rencontré ? je n'ai pas DSM 5.2 donc je ne peux pas te dire si la démarche doit être différente.

Non le contraire, plus tu multiplies ou tu allonges tes câbles tu augmentes les chances de défaillance, si tu fais source -> switch -> destination c'est plus direct que source -> switch -> routeur -> destination, donc c'est mieux.

L'intérêt d'un switch administrable c'est de pouvoir gérer plusieurs VLAN, éventuellement régler la vitesse en 100Mbps ou 1Gbps selon les horaires sur les différents ports si tu es soucieux de ta consommation d'énergie, à toi de voir. Tu as moins de longueur de câble entre la source et la destination si toutes deux sont reliées au switch. Donc des pertes de débit potentielles en moins. J'ai le même dans le salon et il marche nickel. 🙂

Ton NAS est-il relié à ton réseau en gigabit ? Tu peux le vérifier ici : A la ligne Etat du réseau, si tu as ce que j'ai moi c'est bien du gigabit. Est-ce que tu es en 5 GHz ou 2.4 GHz sur tes périphériques wifi ? Pour la TV par contre tu ne devrais pas avoir de souci, même si elle n'a qu'une puce 100 Mbps ça ne devrait pas te poser problème pour du 1080p, même avec un bitrate élevé, c'est pour la 4K que ce serait problématique...

De ce que j'ai lu de ci de là, il faut compter environ 35-40 mbits/s pour la lecture d'un flux 4K. Par contre, il me semble que les versions récentes de DSM prennent de moins en moins de dongle WiFi en charge, donc vérifier la compatibilité éventuelle du matériel. Très hasardeux de te donner des indications quant à la qualité/fluidité, plusieurs facteurs comme l'environnement, la qualité du dongle, la puissance de ta borne wifi, celle du récepteur, etc... Si tu n'as vraiment pas moyen de tirer un câble, tu as peut-être plus à intérêt à envisager le CPL que le wifi.

Bonne idée, je vais mettre de l'ordre dans tout ça ce week-end 🙂

Je crois que le plus simple c'est encore que je mette en pièce jointe les fichiers pré-configurés avec des commentaires pour faire les modifications propres à chacun.

Salut, Il existe certaines images qui combinent les trois applications, tout fonctionne en un seul container, tu es par contre tributaire de la bonne volonté du créateur de l'image de vouloir suivre les évolutions des différentes applications et les mettre à jour. Dans le cas que je présente, tu as accès aux dernières mises à jour pour chaque application. J'ai prévu d'ajouter des impressions d'écran de la configuration des containers effectuée via l'interface docker de DSM, mais dans les faits ce ne sera pas beaucoup plus simple car il y aura des liens symboliques à créer... Bref 🙂 Concrètement si tu suis le tutoriel de Zeus pour l'accès SSH à ton NAS, et que tu suis mes instructions, tu n'y arriveras peut-être pas du premier coup, mais on est là pour t'aider en cas de problème !

Oui le graph "disk load" proposé par défaut ne fonctionne pas de base sur ce template, mais en fouillant un peu dans les champs "system" et "field" du graph (clic sur le titre du graph -> edit) tu dois pouvoir les récupérer. Sur mon screen, les 2 premiers graph concernent mon raspberry pi, et ceux tout en bas concernent Docker sur le NAS. Je n'ai pas encore commencé à rédiger la section concernant l'ajout d'autres appareils du réseau, car je ne la maîtrise pas encore suffisamment (typiquement j'essaie encore de récupérer les données de mon modem et de l'UPS) mais tu peux trouver des infos intéressantes sur ce lien. Après la plupart des graphs je les ai modifiés à ma sauce, mais bon c'est auto-didact, je suis clairement pas assez qualifié pour expliquer comment construire les graphs.

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. Je verrai à faire ça quand j'ai le temps oui, je comprends.

@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. 😉

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 :

Je ne pense pas que ce soit possible.

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.

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 :

J'ai trouvé ça : https://forum.bouyguestelecom.fr/questions/1126298-connexion-vpn-impossible-offre-multi-sim https://forum.bouyguestelecom.fr/questions/1075358-instabilite-vpn-internet-mobile Le problème de VPN revient fréquemment sur les forums de Bouygues on dirait, tu devrais essayer d'investiguer dans cette direction dans un premier temps.

Un NAS maison demande bien plus de temps, que ce soit pour la mise en service ou pour la maintenance. C'est un sujet sur lequel je me renseigne pas mal, et je me rends compte qu'il y a beaucoup de choses à prendre en considération. La plus important pour moi c'est la partie bruit et consommation énergétique, et sur ces points il te sera difficile d'atteindre les performances d'un NAS constructeur. En revanche, pour la puissance brute, pour le même prix tu peux te faire une grosse config avec un NAS maison, avec tous les risques de sur-dimensionnement par rapport au besoin. Pour la partie logicielle, il y a certains services qui sont tout de même bien pratiques sur Synology, je pense notamment au proxy inversé, ça demande déjà plus de travail sur NAS homemade, ou encore PhotoStation/Moments, ils sont loin d'être parfaits, mais franchement pour avoir testé pas mal d'alternatives open source, ce n'est vraiment pas glorieux...

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.

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

@Zeus : C'est prévu ce week-end si pas d'imprévu !

Heu non ça se connecte automatiquement chez moi. Tu as bien coché de mémoriser tes identifiants ?

Peut-être est-ce un de ces cas où il est intéressant d'utiliser Quickconnect ?