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

kestouf · le 18 avril 2020

J'ai hate de voir ton tuto. Pour ma part, je sais que je vais avoir un problème car il va falloir que je trouve le moyen de faire tourner 2 instances Telegraf, un pour le Syno et un pour la Freebox.

bruno78 · le 18 avril 2020

Hello,

pour revenir sur le problème du monitoring de l'UPS, j'ai pas mal fouillé et regardé ce qui se passe avec ces MIBs.

Je suis parti avec PRTG, récupéré les MIBs, les exportées pour PRTG monitoring , puis créé une sonde pour le NAS ... bref 3 heures plus tard PRTG arrive à sortir via SNMP les infos suivantes :

J'imagine donc que telegraf devrait en être capable, en tout cas les infos existent et sont populées par le Syno. Je vais reprendre le OIDs correspondants au tests ci-dessus, et voir si telegraf est capable de les interroger et de récupérer les infos.

.Shad. · le 18 avril 2020

Avec LibreNMS j'avais réussi à avoir les infos aussi, et LibreNMS n'utilisent que le SNMP, en tout cas si tu arrives à trouver ça ce serait super ! Et bravo pour le tutoriel pour la Freebox, je vais ajouter un lien dans mon tutoriel.

kestouf · le 18 avril 2020

Bonsoir,
Je me suis dit que se serais pas mal si je pouvais récuperer le status du SMART pour chaque disque.
J'ai donc ajouté dans le fichier de conf ces lignes:

#  System SMART
	[[inputs.snmp.table]]
    oid = "SYNOLOGY-SMART-MIB::diskSMARTTable"
    [[inputs.snmp.table.field]]
       is_tag = true
    oid = "SYNOLOGY-SMART-MIB::diskSMARTAttrStatus"

Mais lors du redémarrage de l'agent telegraf il me remonte une erreur sur l'info "diskSMARTAttrRaw"

[agent] [inputs.snmp] did not complete within its interval
Apr 18 20:50:25 odroid telegraf[3086]: 2020-04-18T20:50:25Z E! [inputs.snmp] Error in plugin: agent 192.168.0.9: gathering table diskSMARTTable: performing bulk walk for field diskSMARTAttrRaw: Request timeout (after 3 retries)

Auriez vous une idée?

Merci

bruno78 · le 19 avril 2020

Bonjour,

@.Shad. à propos de l'UPS.

pour arriver à mes fins, j'ai installé snmpd sur une VM Ubuntu Mini qui me sert de tests. Puis pour récupérer l'ensemble des OIDs relatifs à l'UPS, j'ai lancé un snmpwalk sur l'OID racine de l'ups dans les MIBs syno, à savoir .1.3.6.1.4.1.6574.4 . Cela me donne l'ensemble des OIDs qui sont implémentés et vont me répondre (je ne sais pas si cela dépendra du modèle d'ups et de NAS Syno ?). Grace aux fichiers descripteurs de la MIB, on récupère facilement le descriptif (rajouté ici en fin de ligne)

root@ubuntumini:/etc/snmp# snmpwalk -v2c 192.168.1.171 -c public .1.3.6.1.4.1.6574.4					
iso.3.6.1.4.1.6574.4.1.1.0 = STRING: "Ellipse ECO 800"		upsDeviceModel		
iso.3.6.1.4.1.6574.4.1.2.0 = STRING: "EATON"			upsDeviceManufacturer		
iso.3.6.1.4.1.6574.4.1.3.0 = STRING: "000000000"		upsDeviceSerial		
iso.3.6.1.4.1.6574.4.1.4.0 = STRING: "ups"			upsDeviceType		ups, pdu, scd, psu
iso.3.6.1.4.1.6574.4.2.1.0 = STRING: "OL CHRG"			upsInfoStatus		
iso.3.6.1.4.1.6574.4.2.5.0 = STRING: "Ellipse ECO 800"		upsInfoModel		
iso.3.6.1.4.1.6574.4.2.6.1.0 = STRING: "EATON"			upsInfoMfr		
iso.3.6.1.4.1.6574.4.2.7.0 = STRING: "000000000"		ups info serial		
iso.3.6.1.4.1.6574.4.2.8.0 = STRING: "0463"			ups info vendor id		
iso.3.6.1.4.1.6574.4.2.9.0 = STRING: "ffff"			ups info product id		
iso.3.6.1.4.1.6574.4.2.10.1.0 = STRING: "02"			ups info firmware name		
iso.3.6.1.4.1.6574.4.2.12.1.0 = Opaque: Float: 0.000000		upsInfoLoadValue		
iso.3.6.1.4.1.6574.4.2.14.1.0 = INTEGER: 30			upsInfoDelayStart		
iso.3.6.1.4.1.6574.4.2.14.3.0 = INTEGER: 20			upsInfoDelayShutdown		
iso.3.6.1.4.1.6574.4.2.15.1.0 = INTEGER: 0			upsInfoTimerStart		
iso.3.6.1.4.1.6574.4.2.15.3.0 = INTEGER: 0			upsInfoTimerShutdown		
iso.3.6.1.4.1.6574.4.2.20.2.0 = Opaque: Float: 800.000000	upsInfoPowerNominal		
iso.3.6.1.4.1.6574.4.2.22.0 = STRING: "enabled"			ups info beeper status		
iso.3.6.1.4.1.6574.4.3.1.1.0 = Opaque: Float: 100.000000	upsBatteryChargeValue		
iso.3.6.1.4.1.6574.4.3.1.2.0 = Opaque: Float: 20.000000		upsBatteryChargeLow		
iso.3.6.1.4.1.6574.4.3.6.1.0 = INTEGER: 2700			upsBatteryRuntimeValue		
iso.3.6.1.4.1.6574.4.3.12.0 = STRING: "PbAc"			ups battery type		
iso.3.6.1.4.1.6574.4.4.2.2.0 = Opaque: Float: 184.000000	ups input transfer low		
iso.3.6.1.4.1.6574.4.4.2.3.0 = Opaque: Float: 264.000000	ups input transfer high		
iso.3.6.1.4.1.6574.4.5.1.1.0 = Opaque: Float: 230.000000	ups output voltage value		
iso.3.6.1.4.1.6574.4.5.1.2.0 = Opaque: Float: 230.000000	ups output voltage nominal		
iso.3.6.1.4.1.6574.4.5.2.2.0 = Opaque: Float: 50.000000		ups output frequency nominal		
iso.3.6.1.4.1.6574.4.7.1.0 = STRING: "usbhid-ups"		ups driver name		
iso.3.6.1.4.1.6574.4.7.2.0 = STRING: "DSM6-2-2-24922-broadwell-fmp-repack-24922-190507"			ups driver version		
iso.3.6.1.4.1.6574.4.7.3.0 = STRING: "MGE HID 1.33"		ups driver version data		
iso.3.6.1.4.1.6574.4.7.4.0 = STRING: "0.38"			ups driver version internal		
iso.3.6.1.4.1.6574.4.7.5.0 = INTEGER: 5			        ups driver poll interval		
iso.3.6.1.4.1.6574.4.7.6.0 = STRING: "auto"			ups driver port		
iso.3.6.1.4.1.6574.4.7.7.0 = INTEGER: 30			ups driver poll frequency		
root@ubuntumini:/etc/snmp#

Ensuite, il suffit dans le fichier telegraf.conf qui se charge du Syno, de renseigner les OIDs qui nous intéressent pour que telegraf aille les récupérer, ce qui nous donne par exemple pour les 2 premiers :

   # UPS Model
   [[inputs.snmp.field]]
     name = "upsModel"
     oid = ".1.3.6.1.4.1.6574.4.1.1.0"

   # UPS Device Manufacturer
   [[inputs.snmp.field]]
     name = "upsManufacturer"
     oid = ".1.3.6.1.4.1.6574.4.1.2.0"

Ne reste plus ensuite qu'à les grapher sur Grafana. Par exemple :

image.png.bf0a6d914989b3f30cbc2e40f317cede.png

Reste à vérifier les changements d'états et de compteurs sur coupure d'alimentation principale.

Suivant les modèles d'ups, il y aura peut-être quelques différences de champs présents / absent. A ajuster donc.

Bruno78

.Shad. · le 19 avril 2020

Super !!

Je viens d'essayer aussi ça marche nickel !!
Les MIB sont identiques pour tous les Syno 😉

@kestouf : En suivant la logique de @bruno78 voici ce que donne le fichier MIB de Synology (https://global.download.synology.com/download/Document/Software/DeveloperGuide/Firmware/DSM/All/enu/Synology_DiskStation_MIB_Guide.pdf)

image.png.34ce5abe6f931179e8b333b777e9cc50.png

image.png.a6c3c941d07c1b5faad5a020c91b7245.png

Essaie d'utiliser les OID directement à la place des descripteurs, ça marchera sûrement.

Encore merci, je n'avais pas pris le temps de jeter un œil à ça, c'est tout bête 🙂
Je mettrai le tutoriel à jour à l'occasion.

Modifié le 19 avril 2020 par .Shad.

bruno78 · le 19 avril 2020

@kestouf

il semble que la table que tu essaies de charger soit une table complète. Je ne sais pas comment telegraf peut récupérer des valeurs multiples, pas un simple OID.

Pour info, ci joint un fichier texte qui liste cette table sur ma machine. Je pense qu'il faut la générer une première fois sur ta machine, spécifique à ta configuration, pour ensuite identifier et aller chercher les OIDs individuels qui t’intéressent. Il y a peut-être un moyen de charger toute le table, mais je ne le connais pas.SmartMib.txt

Jeff777 · le 23 avril 2020

Bonjour,

Et merci Shad pour ce tuto 👍. Je n'ai pas eu trop de mal pour arriver au bout ce qui veut dire qu'il est bien débogué.

J'ai fait bien sûr quelques erreurs n'ayant pas trop l'habitude de docker-compose mais en relisant le tuto j'ai pu rapidement corriger.

Maintenant je vais explorer les différentes possibilités, rajouter mon deuxième NAS (je pense qu'il suffit d'installer docker et influxDB mais je me demande si mon DS212 va supporter) et plus tard ma freebox grace au tuto de bruno78.

Edit : J'avais oublié que le DS212+ ne supportait pas docker.

EDIT2 :pas besoin d'installer docker ni quoi que ce soit dans le second NAS. Il faut juste déclarer son IP dans telegraf et activer snmp.

Modifié le 23 avril 2020 par Jeff777

.Shad. · le 24 avril 2020

Oui telegraf peut faire du "polling" sur des périphériques distants via SNMP.
Telegraf est surtout intéressant pour l'export d'information (output plugins), car il prend en charge une multitude de base de données et d'aggrégateur.

Jeff777 · le 25 avril 2020

Bonsoir,

Et moi j'ai ça, mais je crois que je vais épurer car il y a beaucoup d'info que je ne sais pas exploiter. Je voulais faire la Freebox aussi mais ça me semble beaucoup plus complexe et je me dis que Freebox OS donne toutes les informations nécessaires.

En tout cas ce tuto est très sympa à mettre en place et docker-compose m'a un peu réconcilié avec docker que j'avais essayé puis abandonné il y a plus d'un an.

.Shad. · le 8 mai 2020

Je profite de te répondre ici 😛
Ce n'est pas ce qu'il y a de plus intuitif au début, mais quand on a compris la logique derrière, on a du mal à s'en passer.

Pour ma part j'ai arrêté le monitoring en local, parce que dès qu'on a 4-5 db dans InfluxDB, ça bouffe assez vite la RAM.
Maintenant j'ai un VPS à 3€/mois chez OVH (dont je me sers à la base de serveur VPN pour accéder aux replays des chaines françaises), sur lequel j'héberge une instance InfluxDB et mes différentes instances Telegraf y envoient leurs métriques via TLS.
Idéalement j'aurais aimé réussir à utiliser Wireguard comme pont local pour faire transiter toutes les données Telegraf par VPN, mais je trébuche sur quelques points techniques, ça viendra 😛

Plus généralement sur ce tutoriel, il mériterait que je le reprenne car avec le temps je me rends compte que certaines choses sont à améliorer, mais il faut trouver la motivation. 👍

Modifié le 8 mai 2020 par .Shad.

Lunz_ · le 18 mai 2020

Bonjour à tous,

J'ai enfin décidé de m'inscrire afin d'essayer d'apporter une pierre à l'édifice: J'ai enfin pu rajouter les données de l'UPS en faisant un mix des dashboards de Yann Bizeul et de https://github.com/chvvkumar/Monitoring ; (testé avec deux UPS APC)

J'ai simplement modifié le fichier telegraf.conf au niveau du #UPS Status, et j'ai rajouté ".0" à l'oid. J'ai ensuite recopié les graphs du Json de chvvkumar que j'ai rajouté au tableau de Yann Bizeul.

# UPS Status
[[inputs.snmp.field]]
name = "upsModel"
oid = "SYNOLOGY-UPS-MIB::upsDeviceModel.0"
[[inputs.snmp.field]]
name = "upsStatus"
oid = "SYNOLOGY-UPS-MIB::upsInfoStatus.0"
[[inputs.snmp.field]]
name = "upsLoad"
oid = "SYNOLOGY-UPS-MIB::upsInfoLoadValue.0"
[[inputs.snmp.field]]
name = "upsBatteryCharge"
oid = "SYNOLOGY-UPS-MIB::upsBatteryChargeValue.0"
[[inputs.snmp.field]]
name = "upsBatteryChargeLow"
oid = "SYNOLOGY-UPS-MIB::upsBatteryChargeLow.0"
[[inputs.snmp.field]]
name = "upsBatteryChargeWarning"
oid = "SYNOLOGY-UPS-MIB::upsBatteryChargeWarning.0"
[[inputs.snmp.field]]
name = "upsBatteryVoltage"
oid = "SYNOLOGY-UPS-MIB::upsBatteryVoltageValue.0"
[[inputs.snmp.field]]
name = "upsBatteryRuntime"
oid = "SYNOLOGY-UPS-MIB::upsBatteryRuntimeValue.0"
[[inputs.snmp.field]]
name = "upsInputVoltage"
oid = "SYNOLOGY-UPS-MIB::upsInputVoltageValue.0"

En esperant que ça puisse aider quelques personnes.

.Shad. · le 19 mai 2020

Merci de ton apport je vais tester ça et l'ajouter au tutoriel.

bruno78 · le 19 mai 2020

Bonjour @Pierre-Adrien Bernabeu, @.Shad.,

effectivement, cela fonctionne aussi. Heureusement d'ailleurs.

Soit on met l'OID "brut", soit on met l'alias.

   [[inputs.snmp.field]]
     name = "upsModel"
     oid = ".1.3.6.1.4.1.6574.4.1.1.0"

Ou

  [[inputs.snmp.field]]
       name = "upsModel"
       oid = "SYNOLOGY-UPS-MIB::upsDeviceModel.0"

Merci.

Bruno78

aware · le 29 mai 2020

Bonjour,

Merci et bravo pour ce tuto ! 👍

A part quelques erreurs de ma part que j'ai vite compris et corrigé, tout roule !

J'ai rajouté également l'uptime, mais je n'arrive pas à tomber sur la même valeur, il y a environ 2 jours d'écart, bizarre

bruno78 · le 30 mai 2020

Bonjour,

merci pour ton commentaire 🙂

A propos de l'uptime, ..... c'est extrèmement surprenant ! Le script est capable de remonter 2 valeurs depuis la freebox :

"uptime_val" : il s'agit du uptime en secondes
"uptime" : il s'agit du uptime, exprimé par la Freebox en valeur lisible (chaine de caractères). C'est la Freebox qui fait la conversion.

Je viens de faire le test directement depuis un terminal sur fbx_telegraf:


root@fbx_telegraf:/usr/local/py# python3 freebox_058.py -H | grep uptime
freebox,endpoint=mafreebox.freebox.fr,tag1=System,tag2=NULL,tag3=NULL sys_uptime_val=1976296
freebox,endpoint=mafreebox.freebox.fr,tag1=System,tag2=NULL,tag3=NULL uptime="22 jours 20 heures 58 minutes 16 secondes"
root@fbx_telegraf:/usr/local/py#

sys_time = 1976296 secondes, ce qui équivaut à 22j, 20h, 58 min, 16sec
uptime remonté lisible par la Freebox = "22 jours 20 heures 58 minutes 16 secondes".

=> c'est cohérent.

A moins que ta Freebox ne soit pas à l'heure ????? mais je ne vois pas comment ! Peux-tu faite la vérification ci-dessus et reverifier avec l'uptime directement sur la Freebox ?

Bruno78

PS : j'ai peut-être été trop vite ! C'est sur la Freebox ou sur le NAS que tu as 2 jours de décalage ?? . Ceci dit, pas plus de raison d'avoir 2 jours de décalage sur le NAS !

Modifié le 30 mai 2020 par bruno78
question supplementaire

aware · le 30 mai 2020

Hello

Je parlais du NAS 😁

Mais oui en effet, ça reste bizarre !

Je me suis basé sur ton post page précédente.

Je posterai tout à l'heure à screen de la config

Modifié le 30 mai 2020 par aware

aware · le 30 mai 2020

mon uptime est de 13:57:23 up 3 days, 15:35

Voilà ce que j'ai configuré pour l'uptime du NAS :

image.png.7638cb7119880afdb6a1e3b607b66f5e.png

image.png.0d2afe375c2b24bdd38c80ebe11afe95.png

bruno78 · le 30 mai 2020

Bonjour @aware

j'utilise la visualisation "Single Stat", Show "Current"

image.png.328d0019004be3e1133048ab890fd70b.png

Ceci dit, je ne sais pas pourquoi a priori ce que tu utilises ne semble pas fonctionner .....

aware · le 31 mai 2020

Etrange, après reboot j'ai retrouvé une valeur identique

Jeff777 · le 31 mai 2020

Avec la méthode de @bruno78 j'ai un décalage de 2 minutes environ sur les 2 NAS.

Grafana en retard par rapport aux infos NAS.

aware · le 31 mai 2020

Oui pareil, ~ 2 minutes.

Avant le reboot c'était 2 jours 🧐

LeMorse · le 1 juin 2020

Le 04/06/2019 à 22:18, unPixel a dit :

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

Ah merci !

Tout fonctionnait bien hier sauf une erreur dans mon instance telegraf et en effet c'est ça.

Dans le fichier de configuration de telegraf, il faut bien mettre :

agents = [  "172.18.0.1" ]

Screenshot_2020-06-01_11-09-17.png.da8a154623a68c2b353e01bc0418308d.png

Dans la variable agents ce n'est pas IP_LOCALE_DU_NAS mais l'adresse de passerelle de notre sous réseau.

Enfin voilà, content que tout fonctionne bien ! 😊

LeMorse · le 2 juin 2020

J'ai l’impression que mon sous-réseau Docker ne fonctionne plus lorsque je lance mon VPN...

Est-ce normal ?

.Shad. · le 3 juin 2020

Serveur VPN ou client VPN sur le NAS ?
Si c'est un client VPN il se peut tout simplement que ce soit ton NAS qui soit plus accessible de l'extérieur par l'IP publique fournie par le FAI.

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 0 membre, 0 anonyme, 129 invités (Afficher la liste complète)

Contributeurs populaires

Annonces

Information importante