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

oracle7 · le 23 septembre 2020

@.Shad.

Bonjour,

Souhaitant monitorer aussi mon routeur RT2600ac, j'ai donc activé Snmp dans SRM et je me suis dis que j'allais aller voir les MIBS correspondants dans /usr/share/snmp/MIBS comme cela existe dans DSM. Eh bien perdu, en fait, ils sont dans /usr/syno/share/snmp/mibs et ils semblent identiques à ceux de DSM. Moi qui voulaient voir les champs spécifiques de SRM ... Éventuellement sais-tu où on peux trouver ces MIBS ?

Mon problème est que, par exemple pour les valeurs de statut de mise à jour de SRM, celles-ci semblent différentes entre DSM et SRM. Pour DSM le statut 2 correspond à "DSM à jour" alors que sur SRM cela correspond a priori au statut 3. D'où ma question, saurais-tu par hasard comment et où obtenir (de façon générale) les différentes valeurs que peuvent prendre certains champs tels que par exemple "upgradeAvailable" de la table "snmp.SYNO" ?

Sinon, en parcourant les posts, à un moment donné tu parles d'examiner les OID disponibles avec une commande "snmpwalk" mais là c'est du chinois pour moi malgré le help de la commande sous SSH. Pourrais-tu STP m'expliquer brièvement de quoi il retourne avec cette commande ?

Merci de ton aide.

Cordialement

oracle7😉

Modifié le 23 septembre 2020 par oracle7

.Shad. · le 23 septembre 2020

Ca demanderait beaucoup plus d'explications et d'expertise pour te faire un exposé fidèle.
Mais grossièrement les OID renferment les valeurs qui caractérisent ton système.
Les OID sont une arborescence, on le voit bien ici :

https://global.download.synology.com/download/Document/Software/DeveloperGuide/Firmware/DSM/All/enu/Synology_DiskStation_MIB_Guide.pdf

La colonne "Name" correspond au MIB, une désignation qui permet d'identifier plus facilement la stat recherchée qu'une suite de chiffres qui n'ont rien d'intuitif.
Quand tu fais un snmpwalk, le système va sonder le périphérique et te renvoyer tous ses OID.
Si tu disposes des MIBs adéquats au périphérique (si mis à disposition par le constructeur), le snmpwalk sera "traduit" et te permettra d'identifier plus facilement ce qui est quoi.

Plus d'infos ici : https://www.comparitech.com/net-admin/snmpwalk-examples-windows-linux/#:~:text=snmpwalk is the name given,SNMP data from a device.&text=An OID is an object,within an SNMP-enabled device.

Par exemple, D-Link, quand j'ai regardé du moins, ne mettait pas de MIB à disposition pour ses switchs, du coup j'avais bien réussi à faire un snmpwalk dessus, mais ça ne m'a pas beaucoup aidé. 😄

De ce que j'ai pu lire, c'est plus compliqué avec SRM qu'avec DSM, je ne peux malheureusement pas t'aider là-dessus outre mesure, je n'ai pas de RT. 🙂

oracle7 · le 24 septembre 2020

@.Shad.

Bonjour,

Merci pour ta réponse et pour le lien sur snmpwalk. dans un premier temps c'est bien suffisant pour moi pour comprendre.

Juste un truc, dans une session SSH je tapes "snmpwalk -v1 -c public @IPlocaleMonNAS" ou "snmpwalk -v1 -c public @172.20.0.1" je n'ai pas de réponse (Timeout). Aurais-tu une idée pourquoi ?

Cordialement

oracle7😉

.Shad. · le 24 septembre 2020

Tu exécutes la commande depuis une session SSH du NAS ?
Ou une autre machine du réseau ?

PS : Évite d'utiliser le protocole SNMPv1 -v1, utilise plutôt -v2c

oracle7 · le 24 septembre 2020

@.Shad.

Bonjour,

Je viens de refaire l'essai tel que :

Session SSH DSM sur le NAS : snmpwalk -v2c -c public 172.20.0.1 et snmpwalk -v2c -c public @IPlocaleNAS
Dans les deux cas : Timeout: No Response from @IPxxx
Session SSH SRM sur le routeur : snmpwalk -v2c -c public @IPlocaleRouteur
Idem : Timeout: No Response from @IPxxx

Bizarre, non ?

D'un autre coté : ces trois @IP sont déclarées dans le champ "agents" dans le fichier telegraf.conf.

Et j'arrive tout de même à récupérer quelques informations avec la table snmp.SYNO

Juste la valeur du champ mise à jour qui sur la base des valeurs DSM donne ceci "2 --> soit en cours" qui correspond en fait à "3" dans DSM. (en clair : le 2 de SRM est en fait le 3 de DSM) ???

Cordialement

oracle7😉

Modifié le 5 juillet 2021 par oracle7

.Shad. · le 24 septembre 2020

Je viens de tester sur mon NAS, le snmpwalk marche très bien, que ce soit l'adresse IP locale ou l'adresse passerelle.
Essaie avec localhost ?

Est-ce que "public" est bien le nom de ta communauté ?

il y a 6 minutes, oracle7 a dit :

D'un autre coté : ces trois @IP sont déclarées dans le champ "agents" dans le fichier telegraf.conf.

Pourquoi tu as à la fois l'IP locale du NAS et l'adresse passerelle ? tu pointes vers le NAS dans les deux cas.

oracle7 · le 24 septembre 2020

@.Shad.

Bonjour,

Quel Id... je suis 🤭, c'est sûr que cela marche bien mieux avec la bonne communauté 😅 Merci pour la question. 👍

il y a 4 minutes, .Shad. a dit :

Pourquoi tu as à la fois l'IP locale du NAS et l'adresse passerelle ?

En fait je voulais dire IPlocaleNAS2 ...

Cordialement

oracle7😉

MilesTEG1 · le 12 octobre 2020

Hello @.Shad. @oracle7

Hier j'ai vu qu'il y avait de nouvelles version pour InfluxDB et Grafana, j'ai donc mis à jour les conteneur en les recréant dans Portainer (en utilisant des stacks créé à cette occasion) après avoir téléchargé la dernière version des images.

Et ce matin je me suis dit que ce serait bien de faire un fichier docker-compose tout en un pour les 3 services, afin de faciliter les MAJ.

(Ok, y a moyen de faire "plus simple" pour les MAJ, ou du moins plus automatique, mais là je n'utilise que Portainer ^^)

Donc voilà mon fichier docker-compose, utilisé avec Portainer pour créer les 3 conteneurs :

version: "2"
services:

    influxdb:
        image: influxdb:latest
        container_name: monitoring_influxdb
        hostname: monitoring_influxdb
        networks:
          - monitoring_nas
        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
        volumes:
            - "/volume1/docker/monitoring/influxdb/data:/var/lib/influxdb"
        ports:
            - 8086:8086
        restart: unless-stopped
    
    telegraf:
        image: telegraf:latest
        container_name: monitoring_telegraf
        hostname: monitoring_telegraf
        networks:
          - monitoring_nas
        volumes:
            - "/volume1/docker/monitoring/telegraf/telegraf.conf:/etc/telegraf/telegraf.conf:ro"
            - "/proc:/host/proc:ro"
            - "/usr/share/snmp/mibs:/usr/share/snmp/mibs:ro"
            - "/var/run/docker.sock:/var/run/docker.sock:ro"
        ports:
            - 8125:8125/udp
            - 8092:8092/udp
            - 8094:8094
        restart: unless-stopped

    grafana:
        image: grafana/grafana:latest
        container_name: monitoring_grafana
        hostname: monitoring_grafana
        networks:
          - monitoring_nas
        volumes:
            - "/volume1/docker/monitoring/grafana/data:/var/lib/grafana"
        user: "1111"
        ports:
            - 3030:3000
        restart: unless-stopped
        
networks:
    monitoring_nas:
      external:
        name: monitoring_nas

J'ai copié les 3 dossiers des 3 précédents conteneurs dans un dossier monitoring afin de centraliser le tout aussi au niveau du stockage.

Voilà voilà 🙂
Si ça peut servir à quelqu'un 😉

PS : si vous êtes plus doué que moi avec docker-compose, vous pourrez probablement répondre à ceci :
J'ai du mettre ceci comme version : erreur : version: "2"

Car si je mets ce qui suit, le stack n'est pas créé... j'ai une erreur : version: "2.4"

Si vous savez pourquoi ça ne veut pas fonctionner avec une version 2.4, je suis preneur ^^

Jeff777 · le 12 octobre 2020

@MilesTEG1

Merci pour cette info. Je vais essayer.

.Shad. · le 12 octobre 2020

@MilesTEG1

Il faut essayer autant que possible de n'exposer que les ports qui ont une utilité.
Sauf utilisation extérieure des données de Telegraf, et que Telegraf n'exporterait pas celles-ci mais qu'un autre programme viendrait les importer, les ports n'ont pas besoin d'être translatés (il y a une note à ce sujet après chaque docker-compose.yml dans le tutoriel).

Le seul port que tu as besoin d'exposer c'est celui de Grafana, a priori tout le reste est superflu dans ton cas.

MilesTEG1 · le 12 octobre 2020

il y a 11 minutes, .Shad. a dit :

@MilesTEG1

Il faut essayer autant que possible de n'exposer que les ports qui ont une utilité.
Sauf utilisation extérieure des données de Telegraf, et que Telegraf n'exporterait pas celles-ci mais qu'un autre programme viendrait les importer, les ports n'ont pas besoin d'être translatés (il y a une note à ce sujet après chaque docker-compose.yml dans le tutoriel).

Le seul port que tu as besoin d'exposer c'est celui de Grafana, a priori tout le reste est superflu dans ton cas.

Tu parles des ports de InfluxDB et de Telegraf ?
Faut que j'enlève les ports du fichier docker-compose ?

.Shad. · le 12 octobre 2020

Ben si tu les enlèves ils sont toujours là, c'est juste qu'ils ne sont plus accessibles par un périphérique extérieur qui interrogerait le NAS.
Mais Telegraf peut parfaitement communiquer avec InfluxDB et Grafana sans translater les ports, ils sont dans le même réseau bridge personnalisé.

MilesTEG1 · le 12 octobre 2020

Ok, je vais essayer de refaire les conteneurs sans les ports.

Kramlech · le 12 octobre 2020

J'ai une petite question, je ne sais pas si la réponse a déjà été données dans les 11 pages de ce fil (que j'ai parcourues assez rapidement, veuillez m'en excuser 😉).

Si j'ai bien compris, des informations sont stockées toutes les 10 secondes dans InfluxDB... Est-ce que cela ne risque pas de faire rapidement des volumes assez conséquents ? Y a-t-il un paramètre qui permet de limiter la taille des log ou la taille des données stockées ?

.Shad. · le 12 octobre 2020

Salut @Kramlech

Si tu laisses InfluxDB créer la base de données, la durée par défaut de la politique de rétention des données est de 0s, donc infinie.
Et la durée des "shard groups" est de 7j (168h).
Donc en l'état, tu gardes tes données infiniment, sous forme de paquets de 7 jours de données.
En l'état pour info, pour en moyenne 9 mois de monitoring de 5 périphériques, j'ai au total 3 Go de données.
Sur un NAS ce n'est pas spécialement gênant, mais si on cherche à optimiser l'espace, ça peut effectivement être gênant ! (sur un VPS par exemple)
Dans ce cas-là, il y a plusieurs possibilités :

- Si la base de données existe, il faut se connecter au conteneur InfluxDB puis à Influx, et effectuer une requête pour modifier la politique de rétention des données :

https://docs.influxdata.com/influxdb/v1.7/query_language/database_management/#modify-retention-policies-with-alter-retention-policy

- Si on crée une nouvelle base de données, tu peux suivre ce qui est indiqué ici :

https://docs.influxdata.com/influxdb/v1.7/query_language/database_management/#create-retention-policies-with-create-retention-policy

Kramlech · le 12 octobre 2020

Ok, merci pour ces informations ...

Pour le moment je tombe sur un problème d'identification lorsque je veux créer la datasource dans Grafana...

Telegraf ecrit bien dans infludb(si j'en crois les log !). Mais lorsque je veux créer la datasource dans grafana, j'ai le message suivant :

image.png.98ef22af547983fd46c8879c7ec864dd.png

Bien sur, je suis certain que les user/mot de passe sont OK !!!

J'ai du rater quelque chose ... Vers où je dois chercher ?

MilesTEG1 · le 12 octobre 2020

il y a 30 minutes, Kramlech a dit :

Ok, merci pour ces informations ...

Pour le moment je tombe sur un problème d'identification lorsque je veux créer la datasource dans Grafana...

Telegraf ecrit bien dans infludb(si j'en crois les log !). Mais lorsque je veux créer la datasource dans grafana, j'ai le message suivant :

Bien sur, je suis certain que les user/mot de passe sont OK !!!

J'ai du rater quelque chose ... Vers où je dois chercher ?

Tes conteneurs sont-ils bien tous dans le même réseau ?

.Shad. · le 12 octobre 2020

Est-ce que tu t'y es repris à plusieurs fois ?
Si oui, tu peux essayer de vider le cache de ton navigateur ou tester un autre, outre les problèmes de mauvais login/mdp que je mets de côté d'après tes dires, ça peut être un problème de cache de tentatives antérieures.

Modifié le 12 octobre 2020 par .Shad.

MilesTEG1 · le 12 octobre 2020

Bon sinon sans les ports, j'ai ces erreurs :

Il ne semble pas y avoir de soucis avec les mesures, par exemple les températures des dernières 30s sont bien remontées :

image.png.e0c476dfbdeeb08ee7fd73e4235a1b2c.png

Mais dans les autres j'ai pas d'erreurs qui remonte, si ce n'est ceci pour telegraf (la ligne contenant "warn" mise en évidence au milieu) :

t=2020-10-12T06:22:48+0000 lvl=info msg="Starting Grafana" logger=server version=7.2.1 commit=72a6c64532 branch=HEAD compiled=2020-10-08T09:00:32+0000,
t=2020-10-12T06:22:48+0000 lvl=info msg="Config loaded from" logger=settings file=/usr/share/grafana/conf/defaults.ini,
t=2020-10-12T06:22:48+0000 lvl=info msg="Config loaded from" logger=settings file=/etc/grafana/grafana.ini,
t=2020-10-12T06:22:48+0000 lvl=info msg="Config overridden from command line" logger=settings arg="default.paths.data=/var/lib/grafana",
t=2020-10-12T06:22:48+0000 lvl=info msg="Config overridden from command line" logger=settings arg="default.paths.logs=/var/log/grafana",
t=2020-10-12T06:22:48+0000 lvl=info msg="Config overridden from command line" logger=settings arg="default.paths.plugins=/var/lib/grafana/plugins",
t=2020-10-12T06:22:48+0000 lvl=info msg="Config overridden from command line" logger=settings arg="default.paths.provisioning=/etc/grafana/provisioning",
t=2020-10-12T06:22:48+0000 lvl=info msg="Config overridden from command line" logger=settings arg="default.log.mode=console",
t=2020-10-12T06:22:48+0000 lvl=info msg="Config overridden from Environment variable" logger=settings var="GF_PATHS_DATA=/var/lib/grafana",
t=2020-10-12T06:22:48+0000 lvl=info msg="Config overridden from Environment variable" logger=settings var="GF_PATHS_LOGS=/var/log/grafana",
t=2020-10-12T06:22:48+0000 lvl=info msg="Config overridden from Environment variable" logger=settings var="GF_PATHS_PLUGINS=/var/lib/grafana/plugins",
t=2020-10-12T06:22:48+0000 lvl=info msg="Config overridden from Environment variable" logger=settings var="GF_PATHS_PROVISIONING=/etc/grafana/provisioning",
t=2020-10-12T06:22:48+0000 lvl=info msg="Path Home" logger=settings path=/usr/share/grafana,
t=2020-10-12T06:22:48+0000 lvl=info msg="Path Data" logger=settings path=/var/lib/grafana,
t=2020-10-12T06:22:48+0000 lvl=info msg="Path Logs" logger=settings path=/var/log/grafana,
t=2020-10-12T06:22:48+0000 lvl=info msg="Path Plugins" logger=settings path=/var/lib/grafana/plugins,
t=2020-10-12T06:22:48+0000 lvl=info msg="Path Provisioning" logger=settings path=/etc/grafana/provisioning,
t=2020-10-12T06:22:48+0000 lvl=info msg="App mode production" logger=settings,
t=2020-10-12T06:22:48+0000 lvl=info msg="Connecting to DB" logger=sqlstore dbtype=sqlite3,


t=2020-10-12T06:22:48+0000 lvl=warn msg="SQLite database file has broader permissions than it should" logger=sqlstore path=/var/lib/grafana/grafana.db mode=-rwxrwxrwx expected=-rw-r-----,



t=2020-10-12T06:22:48+0000 lvl=info msg="Starting DB migrations" logger=migrator,
t=2020-10-12T06:22:48+0000 lvl=info msg="Starting plugin search" logger=plugins,
t=2020-10-12T06:22:48+0000 lvl=info msg="Registering plugin" logger=plugins name="Direct Input",
t=2020-10-12T06:22:48+0000 lvl=info msg="Registering plugin" logger=plugins name="Pie Chart",
t=2020-10-12T06:22:48+0000 lvl=info msg="Registering plugin" logger=plugins name="Worldmap Panel",
t=2020-10-12T06:22:50+0000 lvl=info msg="HTTP Server Listen" logger=http.server address=[::]:3000 protocol=http subUrl= socket=,

En réactivant le port pour InfluxDB, je n'ai plus ce message de warning de Grafana.
Et en réactivant les ports de Telegraf, je n'ai plus le message d'erreur cité précédemment.

Bon après, je ne suis pas sur que ce soit dramatique comme message d'erreur compte tenu que tout semblait fonctionner...
Mais là, je vais laisser avec les ports actifs. Ces ports ne sont pas routés en dehors du LAN, et normalement sur mon LAN, je n'ai rien qui pourrait tenté de se connecter sur ces ports là du NAS...

Mais je retiens l'avertissement pour les futurs conteneurs : ne pas exposer les ports pour rien 😉

Kramlech · le 12 octobre 2020

il y a 34 minutes, .Shad. a dit :

Si oui, tu peux essayer de vider le cache de ton navigateur ou tester un autre, outre les problèmes de mauvais login/mdp que je mets de côté d'après tes dires, ça peut être un problème de cache de tentatives antérieures.

Bien vu, le coup de l'autre navigateur !!!! Ca marche !

Je continue mon exploration ....

.Shad. · le 13 octobre 2020

Il y a 17 heures, MilesTEG1 a dit :

Bon sinon sans les ports, j'ai ces erreurs :

monitoring_influxdb c'est bien le nom du conteneur ?

oracle7 · le 13 octobre 2020

@MilesTEG1

Bonjour,

Pour info, on fichier docker-compose.yml comporte aussi les champs "ports" et je n'ai jamais eu aucun problème.

Sinon, je ne saurais l'expliquer mais pour la version j'utilise sur les conseils de @.Shad. la version "2.1" et là aussi aucun problème.

C'est pas grand chose mais cela peut t'aider ?

Cordialement

oracle7😉

MilesTEG1 · le 13 octobre 2020

il y a 34 minutes, .Shad. a dit :

monitoring_influxdb c'est bien le nom du conteneur ?

Oui oui 😉 Cf. mon fichier docker-compose mis dans le post suivant :

il y a 8 minutes, oracle7 a dit :

@MilesTEG1

Bonjour,

Pour info, on fichier docker-compose.yml comporte aussi les champs "ports" et je n'ai jamais eu aucun problème.

Sinon, je ne saurais l'expliquer mais pour la version j'utilise sur les conseils de @.Shad. la version "2.1" et là aussi aucun problème.

C'est pas grand chose mais cela peut t'aider ?

Cordialement

oracle7😉

Le fait que le fichier contienne les champs ports ne me pose pas de soucis de fonctionnement, mais comme le dit @.Shad. ça peut poser des soucis de sécurité dans certains cas.

Sinon, ok pour la version 2.1 qui fonctionne aussi.
Je pense qu'il doit y avoir un formatage différent avec la v2.4... mais où est-ce que ça bloque... Faudrait que je regarde plus en détail ^^

MilesTEG1 · le 13 octobre 2020

@.Shad. :

Pour faire suite à cette histoire de ports exposés, je viens de voir ceci qui pourrait faire ce qu'il faut :

image.png.6c30b1cb0ab600f4e07601766a99b20b.png

Qu'en penses-tu ?

.Shad. · le 13 octobre 2020

Ca implique à première vue d'utiliser la fonction de lien qui est dépréciée, au profit des réseaux bridge créés par l'utilisateur justement.
Si tu essaies d'utiliser l'IP du conteneur InfluxDB à la place du nom de conteneur, est-ce que tu as toujours l'erreur ?

Connexion

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

Messages recommandés

Meilleurs contributeurs dans ce sujet

Jours populaires

Meilleurs contributeurs dans ce sujet

Jours populaires

Messages populaires

.Shad.

oracle7

.Shad.

Images postées

Rejoindre la conversation

Qui est en ligne 9 membres, 0 anonyme, 285 invités (Afficher la liste complète)

Contributeurs populaires

Annonces

Information importante