Rechercher dans la communauté

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 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 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. 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. Notre instance InfluxDB est donc maintenant prête à accueillir des données depuis Telegraf. 8-B. Telegraf 8-B-1. 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 Ceci fait, 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-2. Paramétrage 8-B-2-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 = "10s" ## 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 = false ## 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 notables sont : - le champ interval dans la section [agent] : il définit à quel intervalle les données sont récoltées. - le champ debug dans la même section : le passer à true passe le niveau de verbosité à debug. Pour ma part, j'ai réglé à 60s l'intervalle et réglé debug à true, toujours plus pratique pour identifier la source d'un problème. 8-B-2-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-2-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 : 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 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" ] community : On pense à changer le nom de la communauté si on l'a modifié dans DSM. 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-3. Fichier docker-compose version: '2.1' services: telegraf: image: telegraf container_name: telegraf networks: - monitoring # 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. 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 user: "1026" # Optionnel ports: - 3000:3000 restart: unless-stopped networks: monitoring: external: true 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. 8 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. 9 É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. 10 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. 11 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. 12 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. 13 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 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 user: "1026" # Optionnel ports: - 3000:3000 depends_on: - telegraf - influxdb restart: unless-stopped telegraf: image: telegraf container_name: telegraf networks: - monitoring 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 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 # # ## Only collect metrics for these containers, collect all if empty container_names = [] # # ## 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" # # ## Whether to report for each container per-device blkio (8:0, 8:1...) and # ## network (eth0, eth1, ...) stats or not perdevice = true # # ## Whether to report for each container total blkio and network stats or not total = false # # ## 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 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' Remarques : - Ne pas oublier les simples quotes autour du mot de passe. - 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 : 03/05/21

Monitoring de la Livebox4 avec le triplet d’outils docker InfluxDB, Telegraf et Grafana 07/03/2021 Edit : 20210330 v1.0.1 : Correction bug sur le champ ‘Protocole’ de la table (measurement) ‘LB_NATports’ (voir détail à la fin du présent TUTO). Objectif de ce tutoriel : Réaliser la collecte (via « Telegraf »), le stockage (via « InfluxDB ») et l’affichage après mise en forme (via « Grafana ») des métriques spécifiques de la Livebox4 d’Orange. Nota : Il y a de forces chances que ce tutoriel soit aussi applicable à une Livebox5 mais sans aucune garantie de ma part. Ce tutoriel s’inscrit dans le prolongement du TUTO « Monitoring NAS et Réseau » de @.Shad. et représente en quelque sorte, un complément à ce dernier qui reste et restera dans tous les cas la référence tout comme son autre TUTO « Docker : Introduction ». Je n’expliquerais donc pas plus avant certaines fonctionnalités ou paramétrages de configuration du monitoring car parfaitement et clairement décrits dans les dits tutoriels. En conséquence, il est clair que le bon fonctionnement du présent tutoriel nécessite impérativement (et c’est un préalable incontournable), que vous ayez mis en place le monitoring de votre NAS selon les dispositions et recommandations du TUTO « Monitoring NAS et Réseau ». Tous mes remerciements à @MilesTEG1 qui a très aimablement joué le jeu du bêta testeur afin de m’aider à déverminer ce tutoriel. Quelques images du résultat final : Difficulté et temps de réalisation : Pour être honnête, je dirai que c’est comme pour le « fût du canon » Autant ce sera facile et rapide (quoique …) pour des « initiés », autant cela risque d’être plus compliqué et plus long pour des « novices ». Non pas je veuille décourager ces derniers de mettre en œuvre le présent tutoriel mais il n’est pas question de faire ici une course et cela prendra pour eux le temps qu’il faut à chacun selon ses compétences et ses connaissances. Du point de vue difficulté, j’ai essayé de fournir dans ce tutoriel, un maximum d’explications du moins pour ce qui n’a pas déjà été clairement explicité par @.Shad. dans ses tutoriels sus-cités. En clair, tout est fait pour que les « novices » comprennent les opérations qu’ils réalisent et en assimilent bien les tenants et aboutissants. Ainsi je l’espère, ils pourront progresser dans la connaissance de leur NAS. Genèse du TUTO : En premier lieu, il vous faut savoir qu’Orange ne met à disposition que peu de données descriptives des « entrailles » et du fonctionnement interne de la Livebox (pour les plus curieux voir ici les sources diffusées par Orange). A priori il s’avère aussi qu’il n’existe aucune API documentée chez Orange, contrairement à la « FreeBox ». Ceci étant, on verra dans la suite de ce tutoriel, que même si la Livebox4 ne permet pas de récupérer autant d'informations que la Freebox, malgré tout, celles disponibles, sont amplement suffisantes pour notre besoin. Je vous précise aussi que j’ai fait volontairement abstraction de certaines données car je les ai jugées soit non pertinentes ou soit parce que je ne connaissais pas ou ne comprenais pas leur finalité ou encore simplement parce que je n’utilise pas certaines fonctionnalités donc vous comprendrez aisément qu’il était inutile pour moi de les superviser. Il faut également relever, que très souvent les exemples de monitoring de Livebox que l’on peut trouver de ci de là sur Internet, ne concernent que des Livebox2 ou 3 avec une connexion de type « ADSL » ou « VDSL2 ». Dans mon cas avec une Livebox4 et une connexion de type « Fibre », cela ne correspondait guère d’où une difficulté supplémentaire pour obtenir de l’information sur cette configuration. Toutefois, pour les titulaires d’une ligne avec une connexion de type « ADSL » ou « VDSL2 », la porte n’est pas complétement fermée. Ils pourront tout de même visualiser des données propres à ces types de connexion. La réalisation de panels dédiés leur incombera s’ils veulent assurer la supervision des données associées. Ceci étant, vous allez tout de même découvrir au travers de ce tutoriel un certain nombre d’informations à propos de la Livebox4 sûrement insoupçonnées jusqu’à présent, car masquées par l’interface d’administration de celle-ci. Mais autant prévenir de suite les amateurs de belles courbes de suivi d’évolution que ceux-ci (tout comme moi initialement) seront déçus et vont en rester « sur leur faim » si je puis dire. En effet, force est de constater que l’essentiel des données que l’on va recueillir, sont des données que je qualifierai de « statiques ». Non pas qu’il n’existe pas de données à caractère « dynamique », mais pour élaborer des courbes significatives, il faudrait collecter ces données avec une fréquence assez importante (a minima toutes les 30 secondes à une minute pour bien faire) ce qui : d’une part et à un tel rythme, risque fort de déstabiliser la Livebox en la sollicitant trop souvent, et d’autre part, vu le processus de collecte mis en œuvre, on génèrerait alors un trafic réseau très important qui pourrait avoir un impact non négligeable sur le fonctionnement courant du réseau local. Mais libre à vous de modifier la fréquence d’acquisition que j’ai retenue, si toutefois vous avez une bonne et réelle raison. Vous êtes prévenus, c’est vous qui voyez … Donc dans cette démarche, toute la difficulté aura été de trouver : d’abord, comment accéder (se connecter) au système interne de la Livebox, et ensuite, de savoir quelles données étaient accessibles et les quelles il était possible d’extraire à des fins de supervision. Sachez néanmoins que même si l’on arrive à identifier des données particulières à certaines fonctionnalités celles-ci ne sont pas pour autant accessibles. Orange a vraiment verrouillé la Livebox sur certains points. Lors de mes recherches sur Internet, je n’ai finalement et principalement trouvé et retenu que deux sources d’informations qui m’ont permis d’atteindre l’objectif sus-cité. En premier lieu, l'idée de base m’a été inspirée par un Shell script BASH proposé par « ItHasU » sur son blog et disponible ici : https://blog.ithasu.org/2019/01/monitoring-de-la-livebox-4-avec-grafana/. Dans ce script, « ItHasU » utilise la commande « curl » pour simuler l’accès à l’API (Application Programming Interface) JSON (JavaScript Object Notation) de la Livebox4, comme si c’était le navigateur Web lui-même qui effectuait les requêtes à la Livebox4. Bien que très « light » ce script donne au moins déjà la façon de se connecter à la Livebox4 et un très simple exemple de requête pour extraire des données. Fort de cette base, d’autres recherches m’ont alors conduit aux travaux de « Rene DEVICHI » qui lui, a exploré bien plus avant le contenu logiciel de la Livebox4. Il a ainsi découvert au travers du jeu de pistes et d’énigmes offert par Orange, que la Livebox4 disposait d’un « datamodel » (modèle de données) interne qui communique avec l'extérieur via une interface HTTP et du JSON, nommée "sysbus". Il a donc développé un script Python 3 nommé « sysbus.py » qui exploite cette interface. La mise en œuvre de ce script (en ligne de commandes dans une distribution Linux ou sous Windows) permet de contrôler une Livebox4 par programme et d'en explorer les possibilités de contrôle et d’autres informations masquées. Comme le dit son auteur, je le cite : « c'est un outil ‘ expérimental ‘ », mais qui reste suffisamment abouti à mon sens pour satisfaire notre besoin de monitoring. Ce script est disponible ici : https://pypi.org/project/sysbus/ et en français sur Github : https://github.com/rene-d/sysbus. Comme vous le constaterez l’usage de la commande « curl » pour un « non initié » n’est pas des plus simple (de par notamment sa syntaxe sous Shell script BASH) pour effectuer les requêtes vers le système interne de la Livebox4. Par contre l’usage du script « sysbus.py » facilite très largement la constitution de ces requêtes. Il permet notamment de faire de façon très simple et complètement transparente pour l’utilisateur, une requête HTTP de type « GET » sur le nom d’un objet du « datamodel ». Le JSON retourné décrit alors le modèle lié à cet objet. Autre avantage et intérêt du script « sysbus.py » est qu’il est capable de rendre plus lisible le retour en détectant les fonctions, les paramètres et les instances d'objet interrogé. Ensuite, le décodage, basé uniquement sur l'observation, est peut-être incomplet selon l’auteur mais à mon humble avis il permet déjà d’avoir une bonne idée de l’objet et des données qu’il manipule ce qui me paraît suffisant pour notre utilisation finale. Mais ce n’est que mon avis, je vous laisse juger … C’est donc l’usage ce script « sysbus.py » qui aura été le centre de mes requêtes d’analyse du « datamodel » de la Livebox4 afin de déterminer d’une part les structures d’objets supportant les données que je souhaitais extraire et d’autre part identifier les procédures à utiliser pour ce faire. Autant vous dire que cette recherche n’a pas été au demeurant une mince affaire, compte tenu de la complexité du « datamodel » et du fait de l’inaccessibilité à certains objets. Cela dit, je vous rassure de suite, dans le présent tutoriel, on ne va pas installer de distribution Linux pour y installer et exécuter le script Python « sysbus.py » de « René DIVICHI ». Il vous faut simplement voir cet outil comme un outil d’analyse annexe du « datamodel » de la Livebox4. Les plus curieux ne manqueront pas de mettre en œuvre, j’en suis sûr ... Dans le cas présent, j’ai identifié avec cet outil à peu près toutes les requêtes pertinentes pour réaliser le présent monitoring donc le travail d’identification est déjà fait. Vous n’avez donc rien à faire à ce niveau, c’est cool non ? Toutefois, les « initiés » ayant de très bonnes connaissances en Shell script BASH pourront toujours rechercher et, à leur risques et périls, ajouter des requêtes spécifiques à leur propres besoins afin de récupérer d’autres données plus « exotiques ». Enfin un dernier point : pour votre information contrairement au monitoring du NAS qui utilise des MIB (Management Information Base) pour acquérir les données via le protocole SNMP (Simple Network Management Protocol), sachez que, et je cite encore « René DEVICHI », les MIBs Orange, qui semblent apparemment proches des MIB SNMP, sans toutefois en être, sont en fait des MIB propriétaires et sont inaccessibles en SNMP. Ce qui explique le présent changement de méthode d’acquisition via le module « telegraf » et qui va être détaillé ci-après. Je vous livre donc ci-après la méthode que j'ai suivie pour réaliser le monitoring/la supervision de ma Livebox 4. J’ai essayé de la rendre aussi détaillée que possible. En fait elle est conçue pour « les nuls » , mais pas que ... Principe de réalisation : Sur la base du monitoring du NAS, on va créer une seconde instance du module « telegraf » nommée « telegraf_lb4 » qui aura la charge de collecter les données de la Livebox4. Pour ce faire, ce module « telegraf_lb4 » via un plugin d’entrée spécifique, exécutera périodiquement un Shell script BASH nommé « livebox4.sh » qui lui interrogera la Livebox4 pour en extraire les données qu’il mettra en forme pour ensuite les transmettre au plugin de sortie du module « telegraf_lb4 » qui lui se chargera de les écrire dans une nouvelle base de données « Influxdb » dédiée, elle-même nommée : « livebox4_db ». Enfin, le module « grafana » exploitera cette base de données « livebox4_db » comme source de données pour les requêtes qui alimenteront dans un « Dashboard » les différents « panels » (un par thème/collection de données) de visualisation de ces données. Voilà pour le discours préliminaire, on passe maintenant aux choses sérieuses … 1 Pré-requis Disposer d’un monitoring du NAS avec le triplet de conteneurs docker « Infludb », « telegraf » et « grafana » opérationnels et actifs sur un réseau de type bridge externe. Pour mémoire, le réseau bridge externe en question a les caractéristiques suivantes : - Nom : « monitoring » - Sous réseau d’adresses IP (@IP) en 172.20.0.0 et CIDR = 28 (soit 172.20.0.0/28) - Masque de s/réseau : 255.255.255.240 - Plage d’@IP disponibles : 172.20.0.1 à 172.20.0.14 (soit 14 machines) - Passerelle du s/réseau ayant l’@IP : 172.20.0.1 (ce qui correspond normalement à votre NAS) - @IP de diffusion/broadcast : 172.20.0.15 Nota : Selon vos besoins vous pouvez réduire le nombre de machines sur ce réseau à 6 avec un CIDR = 29 De même, libre à vous d’utiliser d’autres @IP réseau, tant que vous êtes cohérents avec les choix faits précédemment pour le monitoring du NAS. Sur ce sous-réseau « monitoring » les @IP des conteneurs docker « Infludb », « telegraf » et « grafana » sont telles que : Influxdb : @IP 172.20.0.2, @MAC d2:ca:ab:cd:00:02 telegraf : @IP 172.20.0.3, @MAC d2:ca:ab:cd:00:03 grafana : @IP 172.20.0.4, @MAC d2:ca:ab:cd:00:04 · ⚠ Pour des problèmes de compatibilité, le conteneur « Influxdb » doit avoir été créé impérativement à partir d’une image en version 1.8. Ne pas utiliser la version dite « latest » qui correspond à la date de rédaction du présent tutoriel à la version 2.0.4 et qui dans tous les cas est incompatible avec l’organisation actuelle du monitoring. 2 Organisation des répertoires Comme préconisé dans le TUTO « Monitoring NAS et Réseau » on va définir une arborescence d’accueil pour le stockage du script d’installation de l’instance « telegraf_lb4 » et du Shell script BASH « livebox4.sh » ainsi que des sous-répertoires destinés à stocker les données extraites et les fichiers log de journalisation. Sous Windows ouvrez une session SSH sur le NAS (en tant qu’utilisateur « root ») avec « PuTTY » ou « WinSCP ». Sous Mac ouvrez une session SSH en lançant le « Terminal » puis tapez : o ssh utilisateur-admin@ipdunas (si le port n'est pas 22 alors il faut rajouter « -pXXXXX » où XXXXX = No du port personnalisé) o sudo -i (pour passer en « root »). Tapez successivement les commandes suivantes : Nota : Pour mémoire et ceci est valable pour toute la suite : le symbole « $ » présent en début des lignes de commandes Shell présentées ici, est ce qu’on appelle l’invite de commande du Shell. Dans le cas présent, il est propre à l’outil « WinSCP » que j’ai utilisé pour exécuter les différentes commandes Shell de cette procédure. Si vous utilisez « PuTTY » ce sera le symbole « # ». Bien évidemment, il ne faut pas le sélectionner si vous faites des Copier/Coller du texte de ces commandes. Je préfère prévenir même si c’est évident pour certains initiés … o On crée le répertoire du conteneur « telegraph_lb4 » : $ cd /volume1 $ mkdir -p docker/telegraf_lb4 o Comme je préfère séparer les genres, tous les scripts d’installation de mes conteneurs docker sont stockés dans un répertoire dédié à chaque conteneur eux-mêmes regroupés dans un répertoire nommé « scripts_instal » lequel est situé dans le dossier « /volume1/docker ». Mais libre à vous d’utiliser une autre organisation, du moment que vous vous y retrouvez et que vous restez cohérents dans la suite de ce tutoriel … On crée le répertoire du fichier d’installation du conteneur « telegraph_lb4 » : $ cd /volume1/docker/ $ mkdir -p scripts_instal/telegraf_lb4 o On crée le répertoire d’installation du Shell script BASH « livebox4 » et on s’y place : $ mkdir -p docker/livebox4 $ cd /volume1/docker/livebox4 o On crée les sous-répertoires de données et des fichiers log de journalisation : Nota : Ne les créez pas ailleurs ! Le Shell script « livebox4 » s’attend à les trouver à son niveau. $ mkdir -p data $ mkdir -p data_json $ mkdir -p log NE PAS quitter la session SSH 3 Création de l’instance « telegraf_lb4 » 3.1 Création du fichier de configuration « telegraf.conf » Avant de créer le conteneur docker proprement dit de l’instance « telegraf_lb4 », on va donc commencer ici par créer le fichier de configuration « telegraf.conf » que cette dernière utilisera. Je vous renvoie au TUTO « Monitoring NAS et Réseau » pour créer une version générique par défaut de ce fichier « telegraf.conf ». Une fois cela fait, on va « élaguer » très largement ce fichier pour ne conserver que la partie utile et que l’on va aussi adapter à notre besoin. Au final, on aura un fichier qui ressemble à celui ci-après, au détail près de quelques particularités propres à votre environnement effectif. Vous trouverez aussi ci-joint un fichier : telegraf.conf préconfiguré que vous adapterez éventuellement selon vos convenances personnelles. Donc, sur votre PC/Mac à l’aide de votre éditeur de texte préféré : Soit vous ouvrez la version générique du fichier « telegraf.conf » et vous supprimez tout ce qui n’est pas utile de façon à obtenir quelque chose qui ressemble au texte ci-dessous. Soit plus simplement, vous ouvrez la version du fichier « telegraf.conf » ci-jointe et vous l’éditez. Ou encore vous créez un nouveau document au format texte et vous Copiez/Collez le texte ci-dessous dans ce document : Nota : Si d’aventure vous ajoutez des commentaires dans ce fichier pour votre convenance personnelle, veillez à ne pas saisir de caractères accentués. En effet leur présence perturbe l’outil d’analyse (« parser ») du module « telegraf » et génère des erreurs d’exécution dont il est ensuite très difficile d’en identifier la cause (à savoir ces caractères accentués). Vous êtes donc prévenus … # Telegraf Configuration # # 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 surround # 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] # Pour test les donnees sont recoltees toutes les heures (3600s), puis en exploitation toutes les 12 heures (43200s) # ---- Vpd interval = "10s" interval = "43200s" round_interval = true metric_batch_size = 1000 metric_buffer_limit = 10000 collection_jitter = "0s" # ---- Vpd flush_interval = "10s" flush_interval = "60s" flush_jitter = "0s" precision = "" # Run telegraf with debug log messages # ---- Vpd debug = false debug = true # Run telegraf in quiet mode (error log messages only) # quiet = false # logtarget = "file" # Specify the log file name. The empty string means to log to stderr. # logfile = "" # logfile_rotation_interval = "15d" # VpD "0d" # logfile_rotation_max_size = "100MB" # VpD "0MB" # logfile_rotation_max_archives = 5 hostname = "" omit_hostname = false ############################################################################### # OUTPUT PLUGINS # ############################################################################### # Configuration for sending metrics to InfluxDB [[outputs.influxdb]] # urls = ["http://influxdb:8086"] urls = ["http://172.20.0.2:8086"] database = "livebox4_db" database_tag = "" # exclude_database_tag = false skip_database_creation = true retention_policy = "" # retention_policy_tag = "" # exclude_retention_policy_tag = false write_consistency = "any" timeout = "5s" username = "livebox4" password = "livebox4" content_encoding = "gzip" ############################################################################### # INPUT PLUGINS # ############################################################################### # Read metrics from one or more commands that can output to stdout [[inputs.exec]] # Commands array commands = [ "/bin/bash /opt/livebox4/livebox4.sh" ] # # Timeout for each command to complete. timeout = "60s" # # measurement name suffix (for separating different commands) name_suffix = "" # # Data format to consume. # Each data format has its own unique set of configuration options, read # more about them here: # https://github.com/influxdata/telegraf/blob/master/docs/DATA_FORMATS_INPUT.md data_format = "influx" ############################################################################### # SERVICE INPUT PLUGINS # ############################################################################### Dans ce fichier « telegraf.conf » quelques champs remarquables nécessitent un paramétrage spécifique : Dans la section « [agent] » : o Le champ « interval » (qui définit l’intervalle de temps entre deux récoltes de données et dont la valeur par défaut est « 10s ») sera fixé à 43200 secondes soit 12 heures. Vous le constatez, avec cette nouvelle valeur, on est aux antipodes du fonctionnement traditionnel d’une instance « telegraf » en termes de fréquence d’acquisition de données … Vous pouvez bien entendu modifier à votre guise cette valeur mais comme expliqué plus haut, vu que l’on a affaire à des données essentiellement « statiques » ces dernières n’évoluent donc que ponctuellement dans le temps voire pour certaines pas du tout. En conséquence, il ne me paraît pas utile de réduire la fréquence d’acquisition en deçà. Au contraire, peut-être même qu’un relevé journalier serait finalement suffisant. Mais c’est vous qui voyez … o Le champ « flush_interval » (qui définit l’intervalle de temps entre deux « vidage » des données de sorties) sera fixé à 60 secondes. Par défaut, ce champ est fixé à « 10s » mais à l’usage j’ai constaté que cette valeur était insuffisante. En effet, elle avait pour conséquences de tronquer une partie des données extraites du fait (c’est du moins le constat et l’analyse que j’ai pu faire mais j’ai pu me tromper …) que le Shell script « livebox4.sh » à la date de rédaction du présent tutoriel, met environ entre 15 et 20 secondes pour s’exécuter dans mon environnement (mémoire, puissance processeur du NAS, etc…). D’où ce choix (arbitraire certes, mais potentiellement ajustable) de 60 secondes dans mon cas particulier. Je vous laisse voir selon votre environnement s’il sera nécessaire/judicieux ou pas d’augmenter ou encore réduire cette valeur. o Le champ « debug » (valeur par défaut = « false ») est lui passé à la valeur « true » afin d’activer/augmenter le niveau de verbosité, ce qui est bien utile pour identifier l’origine d’un éventuel problème. Dans la section « [outputs.influxdb] » : o Le champ « urls » est définit avec la valeur « ["http://172.20.0.2:8086"] ». Il est clair que l’@IP 172.20.0.2 est celle du conteneur « influxdb » existant et défini pour le monitoring du NAS. À noter qu’il n'est pas possible d’utiliser l’URL suivante : « ["http://influxdb:8086"] ». En effet, dans son environnement d'exécution, le conteneur « telegraf_lb4 » ne "voit" pas le conteneur « InfluxDB » quand on utilise son nom. Il faut impérativement passer par son @IP. Nota : Dans cette URL, « influxdb » est le nom attribué au conteneur « InfluxDB » qui a été créé précédemment pour le monitoring du NAS. o Le champ « database » est défini avec le nom de la base de données spécifique « livebox4_db » que l’on va créer plus loin et donc utiliser pour notre monitoring. o Les champs « username » et « password » sont définis avec vos propres valeurs (attention : n’utilisez pas de caractères exotiques !). Ici par défaut pour les besoins du tutoriel c’est simplement « livebox4 » et respectivement « livebox4 ». o Le champ « content_encoding » avec la valeur "gzip" est un ajout inspiré des recommandations Influxdb (best practices) afin d’accélérer les écritures lors du chargement des données dans la base de données. Dans la section « [inputs.exec] » : Avec l’usage de cette section spécifique, réside toute « l’astuce », en quelque sorte, pour collecter les données extraites de la Livebox4. En effet, puisqu’il n’est pas possible d’utiliser comme d’ordinaire le protocole SNMP pour collecter les données (pour mémoire : pas de MIBs SNMP existantes pour la Livebox4). On va donc utiliser ce plugin de « Telegraf » dont l’objet est de permettre d’exécuter, selon l’intervalle défini dans le champ « interval » ci-avant, un (ou des) programme(s) quelconque(s) et de récupérer les données de sortie de ce(s) programme(s) sur la sortie standard (STDOUT) qui est en général l’écran, pour les envoyer au plugin « [outputs.influxdb] » qui lui se chargera de les enregistrer dans la base de données définie précédemment dans le champ « database ». On va donc configurer cette section pour que l’instance « telegraf_lb4 » exécute périodiquement le programme en question à savoir dans notre cas, le Shell script « livebox4.sh ». o Le champ « commands » (qui énumère tous les programmes à lancer est défini avec la valeur « /bin/bash /opt/livebox4/livebox4.sh ». Cette commande utilise le Shell BASH et indique d’exécuter le programme « livebox4.sh » situé dans le répertoire « /opt/livebox4 ». Vous comprendrez plus loin pourquoi on utilise ce répertoire. ⚠ATTENTION à la syntaxe ! o Le champ « timeout » (qui définit le délai d'expiration de chaque commande pour se terminer) sera fixé à 60 secondes. Par défaut, ce champ est fixé à « 5s » mais à l’usage j’ai constaté que cette valeur était très insuffisante. En effet, elle avait aussi pour conséquences de tronquer une partie des données extraites en interrompant le Shell script « livebox4.sh » avant sa fin normale. Du coup, toutes les données n’étaient pas extraites voire non traitées. o Le champ « name_suffix » (qui ajoute un suffixe au nom des tables -- « measurement » selon la terminologie InfluxDB -- de la base de données ne sera pas renseigné – valeur = vide). Libre à vous de renseigner un suffixe quand bien même, mais comme les noms des tables sont déjà « préfixées » avec « LB_ » cela me paraît inutile de surcharger plus encore leur nom. Mais c’est vous qui voyez … o Le champ « data_format » (qui définit le format des données collectées) sera fixé à la valeur « influx ». Ce format est décrit ici en détail. Donc, sachez que les données envoyées par le Shell script « livebox4.sh » sur la sortie standard STDOUT via notamment une commande Shell « echo » seront formatées au préalable selon le protocole imposé par « InfluxDB ». Maintenant que le fichier « telegraf.conf » est correctement renseigné : Enregistrez sur votre PC/Mac, le fichier « telegraf.conf ». Pour simplifier les choses, enregistrez-le de préférence à la racine d’un répertoire partagé de votre NAS : par exemple dans « //MonDossierPartage ». Transférez ensuite ce fichier dans le répertoire « /volume1/docker/telegraf_lb4/ ». o soit par Glisser/Déposer via l’interface de l’outil « WinSCP » sur PC, o soit en tapant la commande suivante dans une fenêtre « PuTTY » sur PC ou un « Terminal » sur Mac. Retournez dans la session SSH : # cp -p /volume1/MonDossierPartage/telegraf.conf /volume1/docker/telegraf_lb4/ NE PAS quitter la session SSH 3.2 Création du fichier de déclaration du service « telegraf_lb4 » Pour faire simple et éviter de se lancer dans une suite de commandes manuelles pour écrire un script docker, on va ici constituer un fichier nommé « docker-compose » au format « yaml/yml » (YAML Ain't Markup Language). Ce fichier va nous permettre de structurer, de manière plus analytique qu’en ligne de commande, les variables, volumes, etc. donc tous les paramètres propres au conteneur « telegraf_lb4 » qui lui ne sera effectivement créé qu’au §7 ci-dessous avec l’exécution du présent fichier « docker-compose.yml ». Ce fichier à l’avantage d’être persistant après la création du conteneur, on va donc ainsi conserver tous les paramètres de personnalisation de notre image Docker associée. Au final, on aura un fichier qui ressemble à celui ci-après, au détail près de quelques particularités propres à votre environnement effectif. Vous trouverez ci-joint un fichier : docker-compose.yml préconfiguré que vous adapterez éventuellement selon vos convenances personnelles. Donc, sur votre PC/Mac à l’aide de votre éditeur de texte préféré : Créez un nouveau document de type texte. Copiez/Collez le texte ci-dessous dans ce document : Notas : - Même avertissement à propos de la saisie de caractères accentués dans ce fichier. Cette fois, c’est l’outil d’analyse (« parser ») du module « docker» qui ne les aime pas ! Vous êtes donc encore prévenus … - Toutefois, si vous avez pris la précaution de coder votre fichier en UTF8 (voir les préférences de votre éditeur de texte), cela ne devrait pas poser de problèmes. - Je vous rappelle également que dans ce fichier les marques de ‘tabulations’ sont proscrites, l’indentation des différents éléments se fait avec des caractères ‘espace’ ou ‘blanc’ (peu importe leur nombre du moment que vous êtes cohérents !). # # Doc de Telegraf : https://docs.influxdata.com/telegraf/v1.17/ # Depot GitHub : https://github.com/influxdata/telegraf # #--- version: "2.1" services: telegraf_lb4: image: telegraf:latest container_name: telegraf_lb4 hostname: telegraf_lb4 environment: - TZ=Europe/Paris - PUID=1030 - PGID=101 labels: - "com.centurylinklabs.watchtower.enable=true" volumes: - "/volume1/docker/telegraf_lb4/telegraf.conf:/etc/telegraf/telegraf.conf:ro" - "/volume1/docker/livebox4:/opt/livebox4/" - "/usr/bin/jq:/usr/bin/jq" mac_address: d2:ca:ab:cd:00:06 networks: monitoring: ipv4_address: 172.20.0.6 mem_limit: 256M restart: unless-stopped networks: monitoring: external: true Dans ce fichier, les champs remarquables que l’on va configurer sont : Le champ « services » : Dans ce champ il faut nommer le service que l’on va utiliser, en l’occurrence « telegraf_lb4 ». Les champs « container_name » et « hostname » : Ces champs comme leur nom l’indique, portent en toute logique le nom de notre instance « telegraf » à savoir « telegraf_lb4 ». Le champ « volumes » : Ce champ a pour finalité de « monter » des informations nécessaires pour son bon fonctionnement dans l’environnement d’exécution du conteneur « telegraf_lb4 ». C’est un peu comme quand vous montez un lecteur réseau sur votre PC pour accéder à certaines données. Pour le coup, là c’est pareil on va indiquer de mettre à la disposition du conteneur des informations externes à un endroit bien précis dans son environnement. Donc dans notre cas ces informations externes sont : Le chemin complet d’accès au fichier de configuration « telegraf.conf » qui sera monté en lecture seulement (suffixe « :ro ») dans le répertoire « /etc/telegraf/ » du conteneur « telegraf_lb4 ». Le chemin complet d’accès au Shell script « livebox4.sh » qui sera monté dans le répertoire « /opt/livebox4 » du conteneur « telegraf_lb4 ». Ce répertoire « /opt/ » est usuellement utilisé dans le monde Linux pour y installer des programmes tiers. Vous comprenez alors mieux maintenant la configuration correspondante effectuée précédemment dans le fichier « telegraf.conf » pour le champ « commands » dans la section « [inputs.exec] » . Le chemin complet au programme « jq » qui sera monté dans le même répertoire (par le nom) que celui d’origine mais dans l’environnement propre au conteneur « telegraf_lb4 ». Ce programme « jq » est un outil qui permet d’analyser un fichier de données au format « .json ». Il permet aussi notamment de rendre « lisible » humainement un fichier de données en appliquant une méthode de transformation nommée « pretty print ». Ce programme est intensivement utilisé dans le Shell script « livebox4.sh » pour manipuler les données extraites de la Livebox4. Comme, il n’est pas naturellement intégré à l'image docker "telegraf", il est donc nécessaire de le monter pour qu’il soit utilisable par le Shell script « livebox4.sh ». Le champ « network :monitoring :ipv4 address » : Ce champ a pour finalité de simplement indiquer l’@IP du conteneur « telegraf_lb4 ». A vous d’adapter sa valeur à votre environnement tout en restant bien entendu dans la plage d’@IP que vous avez fixée lors de la création du réseau bridge externe « monitoring ». Les autres champs de ce fichier n’appellent pas de commentaires particuliers, ils sont similaires à ceux de l’instance « telegraf » que vous avez créée précédemment pour le monitoring du NAS. Nota : Si vous n’utilisez pas l’outil de mise à jour automatique des images docker « watchtower », alors supprimer purement et simplement le champ « labels » et sa valeur qui apparaissent dans l’exemple ci-dessus. Donc, Modifiez ce texte selon vos besoins comme indiqué ci-avant. Enregistrez sur votre PC/Mac, le document au format « YAML » c’est-à-dire avec l’extension de fichier « .yml » en le nommant « docker-compose » (et pas autrement !) soit « docker-compose.yml ». Pour simplifier les choses, enregistrez de préférence ce fichier « docker-compose.yml » à la racine d’un répertoire partagé de votre NAS : par exemple dans « //MonDossierPartage ». Transférez ensuite ce fichier dans le répertoire « /volume1/docker/scripts_instal/telegraf_lb4/ ». o soit par Glisser/Déposer via l’interface de l’outil « WinSCP » sur PC, o soit en tapant le commande suivante dans une fenêtre « PuTTY » sur PC ou un « Terminal » sur Mac. Retournez dans la session SSH : # cp -p /volume1/MonDossierPartage/docker-compose.yml /volume1/docker/scripts_instal/telegraf_lb4/ NE PAS quitter la session SSH 4 Création de la base de données « livebox4_db » sous InfluxDB Par rapport au monitoring du NAS, nous allons maintenant créer une nouvelle base de données (en fait une seconde) mais qui sera spécifique aux données extraites de la Livebox4 afin d’y stocker ces dernières et cela toujours dans l’environnement « InfluxDB ». Pour ce faire, retournez dans la session SSH : Connectez-vous au conteneur « influxdb » en tapant les commandes suivantes : # cd /volume1/docker/influxdb # docker exec -it influxdb influx -username admin -password admin Vous devriez obtenir quelque chose qui ressemble à cela : # docker exec -it influxdb influx -username admin -password admin Connected to http://localhost:8086 version 1.8.4 InfluxDB shell version: 1.8.4 > Nota : le symbole de l’invite de commande est maintenant le symbole « > » prouvant que l’on est bien dans l’environnement « InfluxDB ». o Tapez successivement les commandes suivantes : Nota : Bien évidemment, vous pouvez adapter le mot de passe à la valeur de votre choix (attention à le placer entre simples cotes « ‘ »). > CREATE DATABASE livebox4_db > USE livebox4_db Using database livebox4_db > CREATE USER livebox4 WITH PASSWORD 'livebox4' > GRANT ALL ON livebox4_db TO livebox4 > SHOW DATABASES name: databases name ---- nas_telegraf _internal livebox4_db > SHOW USERS user admin ---- ----- admin true nas_telegraf false livebox4 false > exit o Redémarrez le conteneur « influxdb » afin de prendre en compte immédiatement la création de la base de données « livebox4_db » : # docker restart influxdb NE PAS quitter la session SSH 5 Configuration de « Grafana » 5.1 Création de la source de données La base de données « livebox4_db » étant définie et opérationnelle, on va maintenant procéder à la définition d’une nouvelle source de données sur l’outil « Grafana ». Rendez-vous sur l’outil « Grafana » en saisissant cette URL dans un navigateur Web : http://@IPdeVotreNAS:3000. Comme je vous l’ai indiqué au début de ce tutoriel, vous avez normalement mis en place le « Monitoring du NAS », donc pour créer une nouvelle source de données il vous suffit de cliquer dans le menu vertical de gauche sur la l’icône en forme d’engrenage « Configuration » et dans le popup qui apparaît, de sélectionner l’item « Data Sources » : Dans le nouvel écran, cliquez sur le bouton bleu « Add data source » Dans le nouvel écran, pour le groupe « Times series databases » sélectionnez « InfluxDB » et cliquez sur le bouton bleu « Select » : Dans l’écran suivant, saisissez les informations ci-après dans les champs correspondants : Name : Livebox4_InfluxDB HTTP : URL : http://influxdb:8086 Access : Serveur (default) Auth : Basic auth : cochez pour activer en bleu Basic Auth Details : User : livebox4 Password : livebox4 InfluxDB Details : Database : livebox4_db User : livebox4 Password : livebox4 HTTP Method : GET Validez en cliquant sur le bouton bleu « SAVE & TEST »et si tout est OK vous obtenez ceci : Il ne vous reste plus qu'à créer le ou les Dashboard souhaités ! 5.2 Importation du Dashbord « Livebox4 » Là pas de soucis, je vous ai maché le travail. Vous trouverez ci-joint le fichier « JSON » d’un Dashboard qui regroupe un ensemble de panels préconfigurés pour chaque domaine cité au §6.2.2 ci-dessous. Si ces panels ne vous plaisent pas, libre à vous de les modifier … Mais attention, « Grafana » n’est pas un outil très convivial pour réaliser des panels. Enfin vous verrez bien par vous-même … Le fichier « JSON » : Livebox4.json Normalement après importation du fichier « JSON » du Dashboard, vous ne devriez pas avoir besoin de reprendre chacun des panels pour préciser la source origine des données affichées. Néanmoins si aucune donnée ne s’affiche, le plus simple est d’éditer avec votre éditeur de texte préféré, le fichier « JSON » et rechercher chaque champ intitulé « datasource » et de remplacer sa valeur par le nom que vous avez donné à votre source de données. Ici c’est « Livebox4_InfluxDB ». Ensuite vous supprimez le Dashboard précédemment créé et vous en créez un nouveau en important le fichier « JSON » modifié. Pour importer ce fichier « JSON » et créer le Dashboard : Depuis la page d’accueil de « Grafana » : dans le menu vertical à gauche de l’écran, cliquez sur l’icône en forme de « + » et sélectionnez dans le popup « Import » : Dans l’écran qui s’affiche alors, cliquez sur le bouton bleu « Upload JSON File » : Une fenêtre d’explorateur de fichier s’affiche, naviguez jusqu’au fichier « Livebox4.json », et validez son importation (bouton « Ouvrir ») Un nouvel écran s’affiche avec le nom prédéfini du Dashboard. Pour le champ « Folder » sélectionnez « General » et ne modifiez pas le champ « Unique Identifier (uid) » : Enfin cliquez sur le bouton bleu « Import ». Admirez … En fait il n’y a pas grand-chose à admirer puisqu’il n’y a pas encore de données dans la base de données « livebox4_db ». Rassurez-vous cela va venir, encore un peu de patience … Tout n’est pas encore en place … 6 Création du Shell script « livebox4.sh ». Compte-tenu du titre de ce paragraphe, là aussi pas d’inquiétude à avoir, on ne va pas écrire ce Shell script ! Je ne vous ferais pas ce coup-là … Je vais simplement vous décrire ses fonctionnalités afin que vous sachiez tout ce que fait le Shell script « livebox4.sh » et ce qu’il est capable de faire, ce sera déjà pas mal … Pour commencer, sachez en premier lieu que ce Shell script est paramétrable, c’est-à-dire qu’il vous laisse la possibilité d’adapter son environnement d’exécution selon vos propres besoins. Pour cela, il a besoin d’aller chercher ses paramètres de personnalisation dans un fichier particulier au format « .json » que l’on va maintenant constituer. 6.1 Création du fichier de configuration « config.json » Le fichier de configuration « config.json » est un élément incontournable pour le bon fonctionnement du Shell script « livebox4.sh ». C’est lui qui va lui fournir les éléments nécessaires pour, par exemple, établir une connexion avec le système interne de la Livebox4. Ce fichier de configuration « config.json » comporte les paramètres suivants dont vous adapterez la valeur à votre propre environnement et/ou vos propres besoins : « host » : ce paramètre correspond à l’URL de connexion à votre Livebox4, en clair c’est l’@IP de votre Livebox4. Généralement c’est « 192.168.1.1 » mais elle peut être différente. « password » : ce paramètre est le mot de passe que vous utilisez pour vous connecter habituellement à votre Livebox4 en mode « admin » notamment lorsque vous consultez son interface d’administration. Sauf si vous l’avez modifié, ce mot de passe est constitué par défaut des huit (8) premiers caractères de la clé Wifi de votre Livebox4. « url_db » : ce paramètre est l’URL de connexion à l’instance « Influxdb ». Elle est ici de la forme : http://<@IP du conteneur InfluxDB>: 8086. À vous de renseigner la bonne valeur en cohérence avec ce que vous avez défini pour le monitoring du NAS. « db » : ce paramètre est le nom de la base de données « InfluxDB » que l’on utilise pour y stocker les données extraites. En l’occurrence sa valeur sera : « livebox4_db ». « user_db » : ce paramètre est le nom d’utilisateur qui a été défini lors de la création de la base de données et qui sera le seul à pouvoir s’y connecter et écrire dans celle-ci. Donc on lui donne la valeur : « livebox4 ». « user_pass_db » : ce paramètre est le mot de passe de l’utilisateur « livebox4 » qui a été aussi fixé lors de la création de la base de données. Par défaut on lui donne la valeur « livebox4 » sinon indiquez la valeur personnalisée que vous avez retenue pour lui. « type_cnx » : ce paramètre correspond au type de connexion dont vous bénéficiez. Trois valeurs sont possibles : « Fibre », « VDSL2 » ou « ADSL » (veillez à bien respecter la syntaxe de ces valeurs). Adaptez donc la valeur à votre type de connexion. « nb_log » : ce paramètre correspond au nombre maximum de fichiers de log de journalisation qui seront conservés. Par défaut ce nombre est fixé à 9 mais rien ne vous empêche d’augmenter ou de diminuer cette valeur. C’est vous qui voyez … Ci-joint le fichier « config.json » : config.json Donc, sur votre PC/Mac à l’aide de votre éditeur de texte préféré : Créez un nouveau document de type texte. Copiez/Collez le texte ci-dessous dans ce document : Nota : N’introduisez surtout pas de commentaires dans ce fichier, sinon rien ne marchera, le parser « jq » que j’ai évoqué précédemment, ne s’accommode pas du tout de ce type d’informations. Vous noterez également que toutes les valeurs des paramètres sont à encadrer par des guillemets « " » et que chaque ligne se termine par une virgule « , » sauf la dernière. Les accolades ouvrante et fermante marquent le début et la fin du fichier. { "host": "192.168.1.1", "password": "xxxxxxxxx", "url_db": "http://172.20.0.2:8086", "db": "livebox4_db", "user_db": "livebox4", "user_pass_db": "livebox4", "type_cnx": "Fibre", "nb_log": "9" } Modifiez ce texte selon vos besoins comme indiqué ci-avant. Enregistrez sur votre PC/Mac, le document au format JSON c’est-à-dire avec l’extension de fichier « .json » en le nommant « config » (et pas autrement !) soit « config.json ». Pour simplifier les choses, enregistrez de préférence ce fichier « config.json » à la racine d’un répertoire partagé de votre NAS : par exemple dans « //MonDossierPartage ». Transférez ensuite ce fichier dans le répertoire « /volume1/docker/livebox4/ ». o soit par Glisser/Déposer via l’interface de l’outil « WinSCP » sur PC, o soit en tapant la commande suivante dans une fenêtre « PuTTY » sur PC ou un « Terminal » sur Mac : # cp -p /volume1/MonDossierPartage/config.json /volume1/docker/livebox4/ 6.2 A propos du Shell script « livebox4.sh » 6.2.1 Principe d’exécution Sans attendre, pour satisfaire la curiosité des utilisateurs « initiés », de façon succincte le Shell script « livebox4.sh » réalise les opérations suivantes : Vérification que le fichier de configuration est bien présent et accessible. Vérification que les répertoires de stockage des fichiers de données sont bien présents et accessibles. Vérification que les répertoires de stockage des fichiers log de journalisation sont bien présents et accessibles. Initialisation de la journalisation des logs. Récupération des informations pour la connexion à la Livebox4. Envoi des commandes d’extraction des données de la Livebox4. Sauvegarde des données extraites dans des fichiers ‘.txt’ pour consultation et « conversion » de chacun de ces fichiers en un fichier "lisible" humainement '.json'. Extraction des champs de données par thèmes : Caractéristiques générales de la Livebox4. Informations sur les utilisateurs enregistrés. Informations sur l’état de la ligne DSL (non significatif avec la fibre). Informations sur l'uptime débit et marge de bruit de la ligne DSL (non significatif avec la fibre). Informations sur le trafic temps réel de la ligne DSL (non significatif avec la fibre). Informations sur les caractéristiques de la ligne DSL (non significatif avec la fibre). Informations générales sur la partie WAN. Informations générales sur la partie DHCP WAN. Informations générales sur la partie DHCP LAN. Informations sur le réseau LO (boucle locale). Informations sur le réseau LAN Ethernet (ports eth1 à 4). Informations sur le réseau LAN Wifi. Informations sur le réseau VoIP-Téléphonie. Informations sur le journal des appels téléphoniques. Informations sur le module Fibre SFP. Informations sur le transfert NAT de ports. Informations sur les services Orange. Informations sur le service IPTV d’Orange. Informations sur le service Wifi partagé d’Orange. Informations sur les équipements périphériques connectés. Par table, formatage des champs selon le protocole « InfluxDB » et envoi sur la sortie STDOUT. Au-delà des opérations réalisées par le Shell script « livebox4.sh », il faut bien comprendre qu’il fonctionne selon deux modes que j’appellerai : « Docker » et « Shell ». En mode « Docker » : le Shell script « livebox4.sh » s’exécute dans l’environnement spécifique du conteneur « telegraf_lb4 » et il n’accepte et ne peux accepter aucune option en paramètre. Les données extraites de la Livebox4 sont reformatées et compilées au standard « InfluxDB » dans une chaîne spécifique constituante des champs extraits avec leurs valeurs à raison d’une chaîne par enregistrement pour chaque table (measurement). Cette chaîne est ensuite envoyée sur la sortie standard STDOUT grâce à une simple commande « echo ». Là, les chaines de données de chaque table sont tour à tour interceptées par la partie « [outputs.influxdb] » du module « telegraf_lb4 » qui se charge alors de les « décrypter » (i.e. les décomposer en champs) puis d’écrire les valeurs de ces champs dans la table correspondante de la base de données « livebox4_db ». Le module « grafana » se charge ensuite d’afficher les données de la base de données dans des « panels » dédiés. En mode « Shell » : le Shell script « livebox4.sh » s’exécute dans l’environnement « normal » du NAS et il peut alors accepter soit aucune option, soit une et une seule option en paramètre. o Si aucune option n’est passée au script : alors, on se retrouve dans une exécution dite « à blanc » dans le sens où les données extraites de la Livebox4, ne sont pas écrites dans la base de données. Elles sont simplement affichées à l‘écran (par la même commande « echo » sus-citée). En fait, on visualise simplement à l’écran, comme dans tout Shell, la chaine formatée au standard « InfluxDB » normalement destinée à être écrite en base de données avec le mode « Docker ». o Si une option est passée au script via la ligne de commande dans une session SSH : alors cette option peut prendre différentes valeurs. Chacune de ces valeurs donne lieu à une fonctionnalité spécifique. 6.2.2 Options du Shell script En mode d’exécution « Shell », les différentes options qui peuvent être passées en paramètre au Shell Script « livebox4.sh » sont consultables en tapant la commande : # cd /volume1/docker/livebox4 # ./livebox4.sh -h Vous obtenez à l’écran l’usage du Shell script « livebox4.sh » : USAGE : livebox4.sh [-eDhTv] | [xyz | all] -e | --exec : active le mode 'Shell' (ou 'Manuel') et ecrit les donnees extraites dans la BD InfluxDB (comme le fait le plugin 'outputs.influxdb' de telegraf) -D | --debug : active le mode debug -h | --help : affiche la presente aide d'usage -T | --trace : active le mode trace -v | --version : affiche la version du present Shell script xyz : affiche les informations extraites selon le domaine 'xyz' 'xyz' = igl ium eld fld tld iew iwd ild ilo ile irw ivt ivs sfp nat iso stv ctv iwc iec all : affiche toutes les informations extraites pour tous les domaines Option « D » et « T » : En utilisant l’une de ces deux options « Debug » ou « Trace », on est dans un mode d’exécution dit « à blanc » à l’instar de ne passer aucune option au Shell script « livebox4.sh ». Dans tous les cas, aucune donnée n’est écrite en base de données. Ces deux options permettent seulement d’obtenir des logs plus « verbeux » en cas de problème avec un mode « Trace » plus bavard que le mode « Debug » qui l’est lui aussi plus que le log normal/standard par défaut : « INFO ». Option « e » : Cette option permet de reproduire en mode « Shell » exactement la même exécution qu’en mode « Docker », le résultat en est strictement identique. C’est à dire que les données sont aussi écrites dans la base de données « livebox4_db ». Option « xyz » : Le terme « xyz » correspond en fait à un trigramme spécifique de chaque thème de données extraites. Cette option permet donc de visualiser à l’écran les données extraites de la Livebox4 pour un thème donné ou pour l’ensemble des thèmes en indiquant « xyz » ou « all » pour tout voir. Par exemple pour le trigramme « igl » correspondant aux données générales de la Livebox4, vous obtiendriez une sortie écran de ce type en tapant la commande : # cd /volume1/docker/livebox4 # ./livebox4.sh igl igl----------------DeviceInfo-------------------- SocFab = Sercomm Modele = SercommVD836_Livebox4 Produit = Livebox 4 NoSerie = AH1xxxxxxxxxxxxxx vHard = SR_LB4_A.0.7 vSoft = SR40_sip-fr-4.01.12.1_7.21.3.1 vSecours = SR40_sip-fr-3.103.16.1 vSoftAdd = g0-f-sip-fr TpsFonc = 1223548 DateDemar = 2021-02-15 13:54:40+01:00 AdrIpExt = 86.xxx.yyy.zzz Etat_LB = 1 NbReboot = 4 AdrMac = aa:bb:cc:dd:ee:ff NomUtil = fti/xxxxxxxx DMZ = 1 DMZAdresDest = 192.168.1.2 MemTotale = 959192 MemLibre = 724988 L’ensemble des trigrammes et de leurs thèmes de données associés est le suivant : igl : Caractéristiques générales de la Livebox4 ? ium : Informations sur les utilisateurs enregistrés. eld : Informations sur l’état de la ligne DSL (non significatif avec la fibre). fld : Informations sur l'uptime débit et marge de bruit de la ligne DSL (non significatif avec la fibre). tld : Informations sur le trafic temps réel et sur les caractéristiques de la ligne DSL (non significatif avec la fibre). iew : Informations générales sur la partie WAN. iwd : Informations générales sur la partie DHCP WAN. ild : Informations générales sur la partie DHCP LAN. ilo : Informations sur le réseau LO (boucle locale). ile : Informations sur le réseau LAN Ethernet (ports eth1 à 4). irw : Informations sur le réseau LAN Wifi. ivt : Informations sur le réseau VoIP-Téléphonie. ivs : Informations sur le journal des appels téléphoniques. sfp : Informations sur le module Fibre SFP. nat : Informations sur le transfert NAT de ports. iso : Informations sur les services Orange. stv : Informations sur le statut du service IPTV d’Orange. ctv : Informations sur la configuration du service IPTV d’Orange. iwc : Informations sur le service Wifi partagé d’Orange. iec : Informations sur les équipements périphériques connectés. 6.2.3 Gestion des répertoires de données « data », « data_json » et « log » Le chemin d’accès aux répertoires de données « data », « data_json » et « log » ne doit pas être modifié car ce chemin diffère selon l’environnement d’exécution du Shell script « livebox4.sh » . En mode « Shell » (ou « Manuel ») ces répertoires sont définis dans le dossier partagé « docker » et leur chemin d’accès naturel est : « /volume1/docker/livebox4/ ». En mode « Docker » via l’instruction « volumes : » du fichier « docker-compose.yml » du conteneur « telegraf_lb4 » ils sont montés dans l’environnement spécifique de ce conteneur et leur chemin d’accès est alors : « /opt/libebox4/ ». Répertoire « data » : ce répertoire est destiné au stockage des fichiers bruts des données extraites par thèmes. Les fichiers stockés dans ce répertoire sont tous nommés tel que : « Domaine.txt » où « Domaine » correspond au type des données extraites (DHCPv4Server, Wifi, Devices, VoiceService, SFP, etc…). Ils sont consultables avec n’importe quel éditeur de fichiers texte mais vous verrez rapidement qu’ils ne sont pas lisibles humainement ! Répertoire « data_json » : ce répertoire est destiné au stockage des fichiers dits « lisibles » des données extraites par thèmes. Ils sont le résultat d’une transformation de type « pretty print » des fichiers « Domaine.txt » sus-cités. C’est un répertoire que vous consulterez naturellement après avoir vu le caractère « imbuvable » de ce qu’était un fichier brut « Domaine.txt » de données du répertoire « data » précédent. À leur vue, vous pourrez vous rendre compte plus facilement de comment sont agencées les données dans le « datamodel » de la Livebox4. Les fichiers stockés dans ce répertoire sont tous nommés tel que : « jqDomaine.json » et sont consultables avec n’importe quel éditeur de fichiers texte. Répertoire « log » : ce répertoire est destiné au stockage des fichiers log de journalisation. En cours d’exploitation pour y trouverez un certain nombre de fichiers de log de journalisation des évènements se produisant durant l’exécution du Shell script « livebox4.sh ». Ce nombre de fichiers dépendra de la valeur que vous aurez fixée précédemment dans le paramètre « nb_log » dans le fichier « config.json ». Ces fichiers de log sont numérotés de 1 à ‘nb_log’ tel que « livebox4.log.n ». À chaque exécution du Shell script « livebox4.sh », une rotation automatique de ces fichiers de log est réalisée. Le fichier d’indice ‘nb_log’ est supprimé (c’est le plus ancien), le fichier d’indice ‘nb_log-1’ passe à l’indice ‘nb_log’ et ainsi de suite jusqu’à libérer le fichier d’indice 1 qui passe lui à l’indice 2. Un nouveau fichier d’indice 1 est alors créé dès le début de l’exécution du Shell script « livebox4.sh ». Ce fichier d’indice 1 sera toujours représentatif de la dernière exécution du Shell script « livebox4.sh » et donc forcément le plus récent. 6.2.4 Cas des données « binaires » ou booléennes Dans l’outil « Grafana », il n’est pas possible d’affecter une couleur à un champ en fonction de la valeur littérale de ce champ. Par exemple si vous vouliez colorer en vert un champ indiquant l’état d’un système lorsque sa valeur est par exemple « Enabled » ou « ON » et en rouge lorsque la valeur est « Disabled » ou « OFF », eh bien vous ne le pourriez pas. Par contre, l’outil « Grafana » ne permet une coloration du champ que si ce dernier a une valeur numérique. Vous pouvez alors mettre en correspondance la valeur numérique avec la couleur que vous souhaitez à l’aide de « Thresholds ». Donc, pour singulariser certaines données (champs) lors de leur affichage dans un panel afin que l’état correspondant soit mis plus en évidence, j’ai utilisé/exploité cette dernière caractéristique. Pour ce faire, lors de l’extraction des données lorsqu’un champ est de type « binaire », c’est-à-dire qu’il a au plus deux valeurs littérales du type « Enabled/Disabled » ou « On/Off », etc …, ou qu’il est de type « booléen » (true/false), j’ai mis en place dans le code, une conversion automatique de cette valeur littérale en valeur numérique du type « 0 / 1 ». Ainsi lors de la conception d’un panel qui contient ce type de champ, j’ai pu attribuer une couleur dite contextuelle (qu’elle soit de premier plan ou d’arrière-plan) selon la valeur de ce champ. Par exemple : vert pour un champ d’état qui indique que le système est « actif/en marche » et rouge quand il est « inactif/à l’arrêt ». Cerise sur le gâteau si je puis dire, afin de ne pas afficher les valeurs numériques « 0 ou 1 » résultantes de la précédente conversion et qui s’avèrent en pratique peu parlantes, j’en ai profité pour traduire au passage les valeurs initiales littérales en utilisant le système de « Mapping Values » de l’outil « Grafana » pour faire correspondre les valeurs numériques associées à ces valeurs initiales en valeurs littérales adaptées. Au final, par exemple pour un champ d’état initial à « Enable », j’ai maintenant ce même champ qui s’affiche sur fond vert avec comme libellé « Marche »et si sa valeur bascule à « Disable » alors il s’affichera sur fond rouge avec le libellé « Arrêt ». C’est quand même plus sympathique, non ? 6.3 Mise en place et test du Shell script « livebox4.sh » Vous trouverez ci-joint le fichier : livebox4.sh (v1.0.1) Téléchargez et enregistrez sur votre PC/Mac, ce fichier. Pour simplifier les choses, enregistrez de préférence ce fichier « livebox4.sh » à la racine d’un répertoire partagé de votre NAS : par exemple dans « //MonDossierPartage ». Transférez ensuite ce fichier dans le répertoire o soit par Glisser/Déposer via l’interface de l’outil « WinSCP » sur PC, o soit en tapant la commande suivante dans une fenêtre « PuTTY » sur PC ou un « Terminal » sur Mac. Retournez dans la session SSH : # cp -p /volume1/MonDossierPartage/livebox4.sh /volume1/docker/livebox4/ NE PAS quitter la session SSH Maintenant que tout est en place (enfin presque tout !), on va pouvoir procéder à un premier test d’exécution du Shell script « livebox4.sh » et ce en mode « Shell ». Pour ce faire, retournez dans la session SSH : Placez-vous dans le répertoire « /volume1/docker/livebox4/ » : # cd /volume1/docker/livebox4/ Exécutez le Shell script « livebox4.sh » avec l’option « e » afin de créer un premier jeu de données dans la base de données « livebox4_db ». Pour cela, tapez la commande suivante : # ./livebox4.sh -e Normalement, après environ quinze à vingt de secondes le script sera terminé et vous ne devriez pas obtenir de message d’erreur. Consultez le fichier log de journalisation : # cd log Visualisez le fichier log « livebox4.log.1 » (normalement il est le seul suite à cette première exécution du script). o Soit en l’éditant directement depuis l’interface de « WinSCP » (c’est le plus simple), o Soit à l’aide de la commande suivante dans une fenêtre « PuTTY » sur PC ou un « Terminal » sur Mac (tapez la barre ‘espace’ pour visualiser écran/écran puis ‘q’ pour sortir) : # more livebox4.log.1 Normalement, vous ne devriez avoir que des messages de type « INFO » et tout doit être OK Sinon analysez les messages d’erreur pour trouver l’origine du problème … 7 Création et mise en service du conteneur « telegraf_lb4 » Voilà, on arrive enfin à la dernière étape de mise en place du monitoring de la Livebox4. On récapitule les opérations précédentes (profitez-en pour vous assurer que tout est conforme) : Le fichier « telegraf.conf » de configuration de l’instance « telegraf_lb4 » est créé, configuré et en place dans le répertoire « /volume1/docker/telegraf_lb4 ». Le fichier « docker-compose.yml » de déclaration de service et d’installation du conteneur « telegraf_lb4 » est créé, configuré et en place dans le répertoire « /volume1/docker/scripts_insta/telegraf_lb4l ». La base de données « livebox4_db » est créée sur « InfluxDB ». La source données « Livebox4_InfluxDB » est créée dans « Grafana ». Le Dashboard « Livebox4 » a été importé dans « Grafana ». Le fichier « config.json » de configuration du Shell script « livebox4.sh » est créé, configuré et en place dans le répertoire « /volume1/docker/livebox4 ». Le Shell script « livebox4.sh » est opérationnel et en place dans le répertoire « /volume1/docker/livebox4 ». Il ne reste plus qu’à créer le conteneur « telegraf_lb4 » pour le rendre opérationnel. Pour ce faire, retournez dans la session SSH : Placez-vous dans le répertoire « /volume1/docker/scripts_instal/telegraf_lb4 » : # cd /volume1/docker/scrips_instal/telegraf_lb4/ Lancer la création du conteneur « telegraf_lb4 ». Pour cela, tapez la commande suivante : # docker-compose up -d Vérifier que la création du conteneur et son lancement se sont bien passés en examinant en « live » le log de l’instance « telegraf_lb4 ». Pour ce faire, tapez la commande suivante : # docker logs -f telegraf_lb4 Vous devriez obtenir quelque chose qui ressemble à ceci (tapez « CTRL + C » pour quitter) : # docker logs -f telegraf_lb4 2021-03-02T10:41:38Z I! Starting Telegraf 1.17.3 2021-03-02T10:41:38Z I! Using config file: /etc/telegraf/telegraf.conf 2021-03-02T10:41:38Z I! Loaded inputs: exec 2021-03-02T10:41:38Z I! Loaded aggregators: 2021-03-02T10:41:38Z I! Loaded processors: 2021-03-02T10:41:38Z I! Loaded outputs: influxdb 2021-03-02T10:41:38Z I! Tags enabled: host=telegraf_lb4 2021-03-02T10:41:38Z I! [agent] Config: Interval:12h0m0s, Quiet:false, Hostname:"telegraf_lb4", Flush Interval:1m0s 2021-03-02T10:41:38Z D! [agent] Initializing plugins 2021-03-02T10:41:38Z D! [agent] Connecting outputs 2021-03-02T10:41:38Z D! [agent] Attempting connection to [outputs.influxdb] 2021-03-02T10:41:38Z D! [agent] Successfully connected to outputs.influxdb 2021-03-02T10:41:38Z D! [agent] Starting service inputs 2021-03-02T10:42:38Z D! [outputs.influxdb] Buffer fullness: 0 / 10000 metrics 2021-03-02T10:43:38Z D! [outputs.influxdb] Buffer fullness: 0 / 10000 metrics 2021-03-02T10:44:38Z D! [outputs.influxdb] Buffer fullness: 0 / 10000 metrics ... Si tout se passe bien à 00:00:00 ou 12:00:00 heures vous devriez voir un message du type : ... 2021-03-02T11:59:38Z D! [outputs.influxdb] Buffer fullness: 0 / 10000 metrics 2021-03-02T12:00:38Z D! [outputs.influxdb] Wrote batch of 122 metrics in 15.870839ms 2021-03-02T12:00:38Z D! [outputs.influxdb] Buffer fullness: 0 / 10000 metrics ... Cela signifie alors qu’une exécution du Shell script « livebox4.sh » pilotée par l’instance docker « telegraf_lb4 » s’est bien déroulée et que les données extraites ont bien été écrites dans la base de données « livebox4_db ». Si vous retournez dans votre navigateur Web sur la page de « Grafana » (http://@IPdeVotreNAS:3000) et que vous rafraichissez votre Dashboard « Livebox4 », vous devriez maintenant pourvoir enfin admirer votre supervision de la Livebox4 cette fois avec des données ! Ci-joint le fichier PDF du présent tutoriel : [TUTO] Monitoring de la Livebox4_20210330.pdf Voilà c’est fini, profitez bien de votre supervision « Livebox4 »!!! Bien évidemment, je prendrai en compte toutes remarques et suggestions visant à corriger si besoin mais surtout à améliorer ce tutoriel. MERCI de vos retours ... Cordialement oracle7 EDIT : 20210330 v1.0.1 Correction bug sur le champ ‘Protocole’ de la table (measurement) ‘LB_NATpors’ Ce champ pouvant finalement prendre plusieurs valeurs (TCP/UDP) il a été nécessaire de modifier son type de « numérique » à « alphanumérique ». De fait, il est nécessaire de modifier la table (measurement) « LB_NATports ». Pour ce faire, voici ci-après la procédure à suivre : Dans une session SSH, connectez-vous au conteneur « influxdb » en tapant les commandes suivantes : # cd /volume1/docker/influxdb # docker exec -it influxdb influx -username admin -password admin > USE livebox4_db > SHOW MEASUREMENTS Vous devriez obtenir quelque chose qui ressemble à cela : name: measurements name ---- LB_DHCPv4_Serv LB_DeviceInfo LB_EquipmtConnect LB_IPTVConfig LB_IPTVStatus LB_LAN_Ethx LB_LO LB_NATports LB_SFP LB_ServicesOrange LB_Users LB_VoIP LB_VoiceService LB_WANStatus LB_WAN_DHCP LB_Wifi LB_Wificom On supprime la table « LB_NATports » pour qu’à la prochaine exécution du script « livebox4.sh » elle soit automatiquement recréée, cette fois avec le bon type (alphanumérique) pour le champ « Protocole ». > DROP MEASUREMENT LB_Natports > exit Dans le répertoire « /volume1/docker/livebox4 » remplacez le Shell script « livebox4.sh » par le nouveau (version 1.0.1 --> § 6.3). # cp -p /volume1/MonDossierPartage/livebox4.sh /volume1/docker/livebox4/ Reconstruisez le conteneur « telegraf_lb4 » afin de prendre en compte immédiatement ce nouveau fichier : Placez-vous dans le répertoire « /volume1/docker/scripts_instal/telegraf_lb4 » : # cd /volume1/docker/scrips_instal/telegraf_lb4/ Supprimez le conteneur « telegraf_lb4 ». Pour cela, tapez la commande suivante : # docker-compose down Relancer la création du conteneur « telegraf_lb4 ». Pour cela, tapez la commande suivante : # docker-compose up -d Voilà, c’est tout. Lors de la prochaine exécution programmée du Shell script « livebox4.sh », la table « LB_NATports » sera automatiquement recréée. À partir de là, si vous créez une translation de port dans la Livebox qui utilise à la fois les protocoles UDP et TCP, l’information s’affichera correctement dans votre panel sous réserve bien entendu que vous ayez édité votre panel en conséquence. C’est à dire pour le champ « Protocole » il suffira d’ajouter en « Overrides » le « value mappings » suivant : ⚠N’oubliez pas d’enregistrer votre dashboard !

Il s'agit ici de présenter un tuto pour monitorer sa Freebox, avec les outils telegraf / influxdb / grafana, en complément du [TUTO] Monitoring NAS et Réseau qui reste la référence. En conséquence, je suppose déjà opérationnelle chez vous une chaine complète telegraf / influxdb / grafana pour la supervision de votre NAS Il faudra bien entendu faire les adaptations spécifiques à votre environnement. Principe : Le docker telegraf va utiliser un script python pour récupérer les infos de la Freebox. Limites : je n'ai pu valider cette méthode que sur ma Freebox, et donc pour les autres modèles et/ou configuration ... ? Freebox Révolution au dernier Firmware (4.0.7) à ce jour. Accès réseau fibre ftth (et donc pas testé les compteurs xDSL) Chaine existante (hypothèse) : je suppose donc que vous avez une chaine telegraf / influxdb / grafana opérationnelle pour votre NAS, en docker mode bridge. Ajout Freebox : On va rajouter un second docker telegraf, qui portera le script Python. Ce docker telegraf dédié Freebox va transmettre ses données vers une seconde database que l'on va créer dans le docker Influx Sur grafana, on créera une nouvelle source de données (la nouvelle database d'influx) qui nous permettra d'afficher les données Freebox. Voir schéma de principe ci-dessous : Configuration des dockers existants : subnet: 172.20.0.0/29 gateway: 172.20.0.1 ip_range: 172.20.0.0/29 Adressage existant grafana d2:ca:ab:cd:00:02 172.20.0.2 influxdb d2:ca:ab:cd:00:03 172.20.0.3 nas_telegraf d2:ca:ab:cd:00:04 172.20.0.4 Création du nouveau docker : fbx_telegraf Adressage sur le réseau bridge : fbx_telegraf d2:ca:ab:cd:00:05 172.20.0.5 Déclaration du service fbx_telegraf dans le docker-compose.yaml (extrait): EDIT du 02/septembre 2020 : la dernière branche de developpement du docker telegraf, 1.15.x, semble poser problème avec Python. Il faut donc se limiter au max à la version 1.14.5. L'image à charger sera donc telegraf:1.14.5 au lieu de telegraf:latest EDIT du 08/septembre 2020 : installation résolue pour python sur la branche telegraf 1.15.x (i.e. tag : latest). Voir détails plus bas. services: fbx_telegraf: image: telegraf:latest container_name: fbx_telegraf hostname: fbx_telegraf mac_address: d2:ca:ab:cd:00:05 networks: monitoring: ipv4_address: 172.20.0.5 environment: - PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/bin:/sbin:/usr/local:/usr/src - TZ=CET mem_limit: 75M volumes: - "/volume1/docker/monitoring/fbx_telegraf/telegraf.conf:/etc/telegraf/telegraf.conf:ro" # pour le fichier de commande python d'acces a la freebox, # pour le fichier de commande python, # pour le fichier get-pip.py (install module pip puis requests) - "/volume1/docker/monitoring/fbx_telegraf/py:/usr/local/py" # pour le fichier log si on le met en place - "/volume1/docker/monitoring/fbx_telegraf/log:/usr/local/log" ports: - 9125:8125/udp - 9092:8092/udp - 9094:8094 restart: unless-stopped On notera la création et le mapping de 2 répertoires pour le docker fbx_telegraf: un répertoire pour le fichier Python et le fichier d'installation de l'utilitaire python "pip" : /usr/local/py un répertoire pour d’éventuels logs : /usr/local/log Création et démarrage du docker fbx_telegraf: docker-compose pull fbx_telegraf docker-compose up -d fbx_telegraf Via un accès ssh sur le NAS : mise à jour du docker fbx_telegraf docker exec -it fbx_telegraf apt update docker exec -it fbx_telegraf apt upgrade docker exec -it fbx_telegraf apt install -y software-properties-common Installation de python3 dans le docker telegraf télécharger get-pip.py (https://bootstrap.pypa.io/get-pip.py) dans le répertoire /usr/local/py installation des modules pip et requests docker exec -it fbx_telegraf wget https://bootstrap.pypa.io/get-pip.py docker exec -it fbx_telegraf python3 get-pip.py --prefix=/usr/local docker exec -it fbx_telegraf python3 -m pip install requests docker exec -it fbx_telegraf pip install unidecode EDIT du 08/septembre 2020 : installation Python sur la branche telegraf:1.5.x (i.e. tag latest) Au lieu des 7 commandes ci-dessus, on procèdera de la sorte : docker exec -it fbx_telegraf apt update docker exec -it fbx_telegraf apt upgrade docker exec -it fbx_telegraf dpkg --configure -a docker exec -it fbx_telegraf apt-get install apt-transport-https ca-certificates curl gnupg-agent software-properties-common docker exec -it fbx_telegraf wget https://bootstrap.pypa.io/get-pip.py docker exec -it fbx_telegraf apt-get install python3-distutils docker exec -it fbx_telegraf python3 get-pip.py --prefix=/usr/local docker exec -it fbx_telegraf python3 -m pip install requests docker exec -it fbx_telegraf pip install unidecode Il se peut que vous ayez une erreur du type : E: dpkg was interrupted, you must manually run 'dpkg --configure -a' to correct the problem Dans ce cas, .... suivre à la lettre la consigne et lancer donc la commande # dpkg --configure -a . Puis poursuivre normalement Script Python : On place le script Python fbx_telegraf_059.py dans le répertoire /usr/local/py (ce script a été mis à jour pour mes propres besoins. N’hésitez pas à le reprendre, en particulier en fonction de l'API Freebox si il vous manque des éléments) EDIT du 27/04/2021 : mise à jour du fichier python en version ed061. version basée sur l'API V8 de FreeboxOs compatibilité avec Freebox POP je conseille de repartir d'une database InfluxDB vierge cf message en page 9 pour plus de détails c'est par ici : https://github.com/bruno78310/Freebox-Revolution-Monitoring.git Modification du fichier de configuration telegraf : 1) Dans la section "Input Plugin" : ############################################################################### # INPUT PLUGINS # ############################################################################### ############################################################################### # INPUT PLUGINS FREEBOX # ############################################################################### # Read metrics from one or more commands that can output to stdout [[inputs.exec]] ## Commands array # commands = [ "python3 /usr/local/py/freebox_059.py -SPHDIWX" ] ## Timeout for each command to complete. timeout = "5s" ## Data format to consume. ## Each data format has it's own unique set of configuration options, read ## more about them here: ## https://github.com/influxdata/telegraf/blob/master/docs/DATA_FORMATS_INPUT.md # data_format = "graphite" data_format = "influx" A noter : le script python "freebox_059.py" est lancé avec un certain nombre d'options, chacune correspondant à un groupe de données récupérées. Si on n'a pas besoin de toutes ces données, selon les besoins, il est tout à fait possible de supprimer les options que l'on ne souhaite pas grapher. freebox_059.py -SPHDIWX : S : état du switch 4 ports X : liste les hosts connectés P : état des ports du switch H : system status D : status disque interne I : status des interfaces LAN W : status du Wifi 4 : status aggregation xdsl / 4g 2) modification de la base influxdb cible, section "Output Plugins" : On va envoyer nos données vers une base de données du nom de fbx_database, user fbx_databse, password fbx_database De plus, on va créer nous même cette database => skip_database_creation = true ############################################################################### # 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://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 = "fbx_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, the database tag will not be added to the metric. # exclude_database_tag = false ## 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 = "30s" ## HTTP Basic Auth username = "fbx_telegraf" password = "fbx_telegraf" ## HTTP User-Agent # user_agent = "telegraf" On redémarre le docker fbx_telegraf pour prise en compte Création de la database fbx_telegraf sur influxdb Se connecter en console sur le docker influxdb, puis créer la database : root@influxdb:/# influx -username admin -password admin Connected to http://localhost:8086 version 1.7.9 InfluxDB shell version: 1.7.9 > show databases name: databases name ---- _internal nas_telegraf > create database fbx_telegraf > use fbx_telegraf Using database fbx_telegraf > create user fbx_telegraf with password 'fbx_telegraf' > grant all on fbx_telegraf to fbx_telegraf > > show databases name: databases name ---- _internal nas_telegraf fbx_telegraf > show users user admin ---- ----- admin true nas_telegraf false fbx_telegraf false > On redémarre le docker influxdb pour prise en compte. Autorisation de l'application sur le Freebox. il faut autoriser l'application sur la Freebox. Pour cela se placer dans une console fbx_telegraf et aller dans le dossier /usr/local/py root@fbx_telegraf:/usr/local/py# python3 freebox_059.py -h usage: freebox_050.py [-h] [-s] [-r] [-n app_name] [-i app_id] [-d device_name] [-f format] [-e endpoint] [-S] [-P] [-H] [-D] [-L] [-W] [-I] [-X] optional arguments: -h, --help show this help message and exit -s, --register-status Get register status -r, --register Register app with Freebox API -n app_name, --appname app_name Register with app_name -i app_id, --appid app_id Register with app_id -d device_name, --devicename device_name Register with device_name -f format, --format format Specify output format between graphite and influxdb -e endpoint, --endpoint endpoint Specify endpoint name or address -S, --status-switch Get and show switch status -P, --status-ports Get and show switch ports stats -H, --status-sys Get and show system status -D, --internal-disk-usage Get and show internal disk usage -L, --lan-config Get and show LAN config -W, --wifi-usage Get and show wifi usage -I, --lan-interfaces Get and show lan interfaces -X, --interfaces-hosts Get and show interfaces hosts On va demander d'enregistrer notre application sur la Freebox: root@fbx_telegraf:/usr/local/py# python3 freebox_059.py -r => il faut valider sur l'ecran LCD de la Freebox. => le nom de l'application codée dans le fichier fbx_telegraf_059.py est : grafanamonitor. => controler sur la Freebox que l'application a bien été acceptée : Paramètres / Gestion des Accès / Applications on peut aussi vérifier sur la console fbx_telegraf : root@fbx_telegraf:/usr/local/py# python3 freebox_059.py -s Status: auth already done root@fbx_telegraf:/usr/local/py# root@fbx_telegraf:/usr/local/py# python3 freebox_059.py -r Already registered, exiting root@fbx_telegraf:/usr/local/py# Vous trouverez alors un fichiers .credentials dans le répertoire /usr/local/py . A partir de là, fbx_telegraf est en mesure de collecter les données sur la Freebox, et de les envoyer sur la base de données fbx_telegraf du docker influxdb. on peut contrôler à la main que les valeurs sont bien accessibles, par exemple : root@fbx_telegraf:/usr/local/py# python3 freebox_059.py -H | grep System freebox,endpoint=mafreebox.freebox.fr,tag1=System,tag2=NULL,tag3=NULL sys_uptime_val=2787529 freebox,endpoint=mafreebox.freebox.fr,tag1=System,tag2=NULL,tag3=NULL uptime="32 jours 6 heures 18 minutes 49 secondes" freebox,endpoint=mafreebox.freebox.fr,tag1=System,tag2=NULL,tag3=NULL firmware_version="4.2.5" freebox,endpoint=mafreebox.freebox.fr,tag1=System,tag2=NULL,tag3=NULL board_name="fbxgw2r" freebox,endpoint=mafreebox.freebox.fr,tag1=System,tag2=NULL,tag3=NULL disk_status="active" freebox,endpoint=mafreebox.freebox.fr,tag1=System,tag2=NULL,tag3=NULL user_main_storage="Disque dur" freebox,endpoint=mafreebox.freebox.fr,tag1=System,tag2=NULL,tag3=NULL has_ext_telephony=True freebox,endpoint=mafreebox.freebox.fr,tag1=System,tag2=NULL,tag3=NULL has_speakers_jack=True freebox,endpoint=mafreebox.freebox.fr,tag1=System,tag2=NULL,tag3=NULL wifi_type="2d4_5g" freebox,endpoint=mafreebox.freebox.fr,tag1=System,tag2=NULL,tag3=NULL pretty_name="Freebox Server (r2)" freebox,endpoint=mafreebox.freebox.fr,tag1=System,tag2=NULL,tag3=NULL customer_hdd_slots=0 freebox,endpoint=mafreebox.freebox.fr,tag1=System,tag2=NULL,tag3=NULL name="fbxgw-r2/full" freebox,endpoint=mafreebox.freebox.fr,tag1=System,tag2=NULL,tag3=NULL has_speakers=True freebox,endpoint=mafreebox.freebox.fr,tag1=System,tag2=NULL,tag3=NULL internal_hdd_size=250 freebox,endpoint=mafreebox.freebox.fr,tag1=System,tag2=NULL,tag3=NULL has_femtocell_exp=True freebox,endpoint=mafreebox.freebox.fr,tag1=System,tag2=NULL,tag3=NULL has_internal_hdd=True freebox,endpoint=mafreebox.freebox.fr,tag1=System,tag2=NULL,tag3=NULL has_dect=True freebox,endpoint=mafreebox.freebox.fr,tag1=System,tag2=Fan,tag3=NULL id="fan0_speed" freebox,endpoint=mafreebox.freebox.fr,tag1=System,tag2=Fan,tag3=NULL name="Ventilateur 1" freebox,endpoint=mafreebox.freebox.fr,tag1=System,tag2=Fan,tag3=NULL value=2436 freebox,endpoint=mafreebox.freebox.fr,tag1=System,tag2=Sensor,tag3=temp_hdd id="temp_hdd" freebox,endpoint=mafreebox.freebox.fr,tag1=System,tag2=Sensor,tag3=temp_hdd name="Disque dur" freebox,endpoint=mafreebox.freebox.fr,tag1=System,tag2=Sensor,tag3=temp_hdd value=36 freebox,endpoint=mafreebox.freebox.fr,tag1=System,tag2=Sensor,tag3=temp_sw id="temp_sw" freebox,endpoint=mafreebox.freebox.fr,tag1=System,tag2=Sensor,tag3=temp_sw name="Temperature Switch" freebox,endpoint=mafreebox.freebox.fr,tag1=System,tag2=Sensor,tag3=temp_sw value=48 freebox,endpoint=mafreebox.freebox.fr,tag1=System,tag2=Sensor,tag3=temp_cpum id="temp_cpum" freebox,endpoint=mafreebox.freebox.fr,tag1=System,tag2=Sensor,tag3=temp_cpum name="Temperature CPU M" freebox,endpoint=mafreebox.freebox.fr,tag1=System,tag2=Sensor,tag3=temp_cpum value=58 freebox,endpoint=mafreebox.freebox.fr,tag1=System,tag2=Sensor,tag3=temp_cpub id="temp_cpub" freebox,endpoint=mafreebox.freebox.fr,tag1=System,tag2=Sensor,tag3=temp_cpub name="Temperature CPU B" freebox,endpoint=mafreebox.freebox.fr,tag1=System,tag2=Sensor,tag3=temp_cpub value=53 root@fbx_telegraf:/usr/local/py# Dans la console du docker influxdb, on verifie que l'on recoit bien les données de nas_telegraf et fbx_telegraf Grafana : sur grafana, definir une nouvelle source de données : Name : InfluxDB-1 Freebox (example) URL : http://@NAS:8086 (comme pour le nas_telegraf,car c'est le même docker influxdb) Access : serveur Basic auth : yes Basic auth details : user : fbx_telegraf password : fbx_telegraf Database : fbx_telegraf User : fbx_telegraf password : fbx_telegraf http method : GET On valide (SAVE & TEST) et ce doit être OK. Il ne reste plus qu'à créer le ou les Dashboard souhaités ! => Ne pas oublier de préciser l'origine des données : InfluxDB-1 Freebox Pour ma part, j'ai réalisé: un Dashboard général (trafic, CPU, status des ports du switch, températures ....) un Dashboard listant les stations actives (globales et Wifi) Resterait à faire : l'API de la Freebox est accessible ici en http. Je n'ai pas réussi par manque de connaissances à passer en https je n'ai pas regardé du tout le cas d'un accès xDSL .... le script python s'appuie sur l'API V8 de la Freebox, et est donc compatible avec les Freebox Revolution et POP. La description de cet API peut se trouver ici : https://dev.freebox.fr/sdk/os/# Enfin, tous les paramètres disponibles n'ont pas forcement été implémentés dans le script. Mais les principaux sont là. SI il y avait un besoin particulier, faites le moi savoir. Freebox-1585840825569.json Liste stations FreeBox-1585840845020.json freebox_054.py freebox_058.py

Bonjour, je possède un DS211j. J'en suis plutôt content. J'hésite à le laisser allumé en permanence car ma hantise c'est la panne du ventilateur et le risque d'incendie. Je rebondis donc sur ce précédent post : J'y ai lu que le NAS a une fonction qui lui permet de s'arrêter automatiquement si le ventilateur tombe en panne. En gros je comprends qu'il y a un monitoring de la température et qu'il est possible d'être averti en cas de problème. Voici donc mes questions : 1/ Cette fonction de monitoring est elle fiable ? Certains d'entre vous ont ils déjà été avertis qu'un problème était survenu ? 2/ J'ai désactivé la mise en veille du NAS car quand j'y accédais depuis mon PC XP je trouvais ça pénible d'attendre que le NAS se réveille. Dans le cas ou je décide de laisser le NAS toujours allumé, est il préférable d'activer la mise en veille ? Lorsque le NAS est au repos, le ventilo baisse de régime ? Pouvez vous me dire les choix que vous avez fait à ce sujet ? 3/ Remarque : j'ai une freebox v6 , et donc le module server qui possède un DD de 250Go est toujours allumé. Free a t il implémenté un arrêt automatique en cas de pépin ? Merci d'avance pour votre aide.

Bonjour à tous. Le monitoring des ressources n'affiche pas la courbe du flux réseau LAN 2 sur un RS-408 RP (DMS 3.1) . Est ce le cas pour tous le monde? Merci