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

[MilesTEG1]

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

Pour l'unité, tu as loupé quelques échanges, il faut supprimer le 0.954, c'est en fait le coefficient de conversion de kibibytes à kilobytes, voir mon explication il y a quelques pages.

Ha mince, j'ai raté un bout de la discussion... ou bien j'ai oublié de l'appliquer... 😅

Je viens de voir que j'avais fait les modifications pour la RAM du routeur mais pas pour le NAS, et donc à fortiori pour l'autre NAS que j'ai ajouté.

[oracle7]

@.Shad.

Bonjour,

Dans le docker-compose du conteneur telegraf on monte le volume suivant :

"/usr/share/snmp/mibs:/usr/share/snmp/mibs:ro"

pour utiliser les MIBs SNMP de DSM.

OK très bien, pas de soucis, j'avais copié dans le répertoire "/usr/share/snmp/mibs" un fichier MIB spécifique de mes caméras HIKVision. Cela marchait bien jusqu'à présent, sauf qu'avec une récente 'en fait la dernière) mise à jour de DSM, le répertoire sus-cité a été réinitialisé et j'ai perdu mon fichier MIB HIKvision. Du coup plus aucune collecte d'infos via SNMP pour mes caméras.

J'ai résolu le problème finalement en :

1. copiant toutes les MIBs du répertoire "/usr/share/snmp/mibs" dans un répertoire sur "/volume1/docker/mibs/" (y compris la MIB HIK).
2. remplaçant dans le docker-compose le montage précédent par celui-ci :

- "/volume1/docker/mibs/:/usr/share/snmp/mibs:ro"

Cela résiste maintenant aux mises à jours de DSM.

Aussi, je te propose si tu le veux bien, d'ajouter un couplet dans le présent TUTO pour signaler la chose et donc éviter des désagréments à ceux qui comme moi rajouteraient des MIBs à celles fournies en standard avec DSM par Synology.

je te laisser jugé de la pertinence de cet ajout.

Cordialement

oracle7😉

[.Shad.]

Je préciserai le risque de reset si on y ajoute sa tambouille, bien que dans mon tutoriel je ne dis jamais d'y ajouter des fichiers.

Et en soit faire ce que tu proposes est une rustine, car si les MIB évoluent, tu garderas les versions antérieures des MIB. Et l'évolution des MIB ce n'est pas la première ligne des patch notes. 😄

Et je crois que tu avais testé d'ajouter un sous-dossier, que ça ne marchait pas, ce qui m'interroge encore. Car normalement SNMP balaie le dossier configuré et ses enfants dans son démon, SNMPD.

[oracle7]

@.Shad.

Bonjour,

Je suis désolé que tu prennes mal ma proposition, je ne t'en ferais donc plus.

Pour moi ce n'est pas une "bidouille" c'était juste une adaptation pour prendre en compte des MIBs supplémentaires sans risquer de les perdre avec une mise à jour DSM et cela me paraissait intéressant de le signaler. De toutes façons on est pas près d'avoir des évolutions sur les MIBs Synology comme tu le dis, donc cela ne pose pas de problème et ma solution est parfaitement efficiente.

Cordialement

oracle7😉

 

[.Shad.]

Je n'ai pas mal pris ta proposition, je t'ai juste dit qu'on est tributaire des évolutions de MiB, et elles ne sont pas si rares que ça, il y a encore eu une màj en 2020. J'appelle ça une rustine, car ça donne un workaround à un problème qui doit être résolu de manière plus globale. De plus, dans mon tutoriel à aucun moment je ne personnalise le dossier des MIB, parce que je n'en ai pas besoin dans ce que je développe, donc ça tomberait un peu des nues.

Je sais que c'est une solution que je t'avais proposée, mais c'était complètement temporaire, ça n'a pas sa place dans un tutoriel à mon humble avis.

En reparcourant cette discussion, je vois que tu avais mis dans le fichier snmp.conf :

mibdirs +/volume1/docker/MIBs
mibs +HIK-DEVICE-MIB

Ca ne peut pas marcher car tu es dans le conteneur et tu donnes un chemin relatif à DSM.

Pour moi, une solution possible serait de créer un fichier snmp.conf sur ton NAS dans le dossier telegraf avec :

mibdirs +/usr/share/snmp/mibs/hik
mibs +HIK-DEVICE-MIB

Et mettre le MIB là où tu veux sur ton NAS, par exemple /volume1/docker/telegraf/mibs/ :

volumes:
 - /volume1/docker/telegraf/mibs/HIK-DEVICE-MIB:/usr/share/snmp/mibs/hik/HIK-DEVICE-MIB:ro

Quand Telegraf va poll un périphérique, il va chercher dans le dossier par défaut (/usr/share/snmp/mibs/) + le mibdirs ajouté plus haut, dans lequel il trouvera le HIK-DEVICE-MIB.

Bref, il ne faut pas prendre la mouche parce que cette solution ne me convient pas, que je sache j'ai souvent tenu compte de ton avis quand je le trouve pertinent.

[oracle7]

@.Shad.

Bonjour,

Je viens de tester ta proposition précédente (en supprimant juste l'étage HIK-DEVICE-MIB dans le chemin) mais il y a un hic.

Je récupère de type d'erreur :

# docker logs -f telegraf
2021-03-11T14:47:11Z I! Starting Telegraf 1.17.3
2021-03-11T14:47:11Z I! Using config file: /etc/telegraf/telegraf.conf
2021-03-11T14:47:11Z I! Loaded inputs: cpu disk diskio docker kernel mem processes snmp (2x) swap system
2021-03-11T14:47:11Z I! Loaded aggregators:
2021-03-11T14:47:11Z I! Loaded processors: converter strings
2021-03-11T14:47:11Z I! Loaded outputs: influxdb
2021-03-11T14:47:11Z I! Tags enabled: host=telegraf
2021-03-11T14:47:11Z I! [agent] Config: Interval:30s, Quiet:false, Hostname:"telegraf", Flush Interval:10s
2021-03-11T14:48:00Z E! [inputs.snmp] Error in plugin: initializing field manufacturer: translating: MIB search path: /root/.snmp/mibs:/usr/share/snmp/mibs:/usr/share/snmp/mibs/iana:/usr/share/snmp/mibs/ietf:/usr/share/mibs/site:/usr/share/snmp/mibs:/usr/share/mibs/iana:/usr/share/mibs/ietf:/usr/share/mibs/netsnmp
Cannot find module (HIK-DEVICE-MIB): At line 1 in (none)
HIK-DEVICE-MIB::manufacturer.0: Unknown Object Identifier: exit status 2
2021-03-11T14:49:00Z E! [inputs.snmp] Error in plugin: initializing field manufacturer: translating: MIB search path: /root/.snmp/mibs:/usr/share/snmp/mibs:/usr/share/snmp/mibs/iana:/usr/share/snmp/mibs/ietf:/usr/share/mibs/site:/usr/share/snmp/mibs:/usr/share/mibs/iana:/usr/share/mibs/ietf:/usr/share/mibs/netsnmp
Cannot find module (HIK-DEVICE-MIB): At line 1 in (none)

J'ai du raté un truc ...

j'ai vérifié, la MIB HIK est bien montée dans le répertoire /usr/share/snmp/mibs/hik du conteneur telegraf.

Alors que si je copie toutes les MIBs dans "/volume1/docker/mibs/" (y compris la MIB HIK).

et que dans le docker-compose je met ce montage :

- "/volume1/docker/mibs/:/usr/share/snmp/mibs:ro"

Il n'y a plus d'erreur dans le log de telegraf. Du coup je ne comprends pas trop ce qui ce passe.

Une idée peut-être ?

Cordialement

oracle7😉

[.Shad.]

Ben je te dirais d'utiliser un des dossiers dans lesquels il cherche alors :

/root/.snmp/mibs
/usr/share/snmp/mibs
/usr/share/snmp/mibs/iana
/usr/share/snmp/mibs/ietf
/usr/share/mibs/site
/usr/share/snmp/mibs
/usr/share/mibs/iana
/usr/share/mibs/ietf
/usr/share/mibs/netsnmp

 

[oracle7]

@.Shad.

Bonjour,

C'est bien parce que j'utilise déjà un ce ces dossiers

/usr/share/snmp/mibs

que je ne comprends pas !

Cordialement

oracle7😉

[bruno78]

@oracle7 bonjour,

puis-je faire une suggestion ? As-tu essayer de lancer un "snmpwalk" depuis une console ssh vers un élément de la MIB ? Cela peut permettre de voir des messages d'erreur que l'on ne voit pas sinon. D'abord depuis une console ssh du NAS, puis depuis une console ssh dans le docker lui-même.

[oracle7]

@bruno78

Bonjour,

Merci pour la suggestion, je ferais un test pour voir, tu as raison, on voit ainsi des choses qui sont masquées habituellement.

Mais, pourtant aucun message d'erreur dans le log telegraf avec la manip que j'ai décrite précédemment avec

ce montage :

- "/volume1/docker/mibs/:/usr/share/snmp/mibs:ro"

Cordialement

oracle7😉

[oracle7]

@bruno78

Bonjour,

Je viens de tester selon tes suggestions, mais non aucun problème, pas de message d'erreur, je récupère parfaitement toutes les informations de la MIB avec le snmpwalk.

Cordialement

oracle7😉

[bruno78]

@oracle7

d'un côté c'est plutôt bon signe, .... mais du coup ça n'explique pas où est ton problème ....

[oracle7]

@bruno78Bonjour,

Ah là on est bien d'accord, j'ai l'impression qu'en montant dans autre chose que les répertoires standards, par ex dans :

/usr/share/snmp/mibs/hik

 cela ne marche pas, d'où ma "rustine" comme dit @.Shad. 😛

Maintenant, comme cela marche comme cela, je ne vais pas insister et perdre mon temps. Je reste avec cette rustine quite à mettre à jour (s'il y en a) les MIBs lors d'une mise à jour de DSM. Comme c'est tous les 36 du mois ....

Cordialement

oracle7😉

[MilesTEG1]

Dites, @oracle7 @.Shad. @bruno78,

 je viens de constater que mes relevés ne se font plus que toutes les 9-10 minutes pour le 920+ et le routeur.
Je pense que c'est depuis que j'ai éteint le 214play.
Les 3 périphériques sont dans le même fichier de configuration de l'instance telegraf.
Est-ce  normal ?
Faut-il que je fasse une instance de telegraf dédiée au 214 play ? (et donc une base de donnée dédiée pour lui aussi) ?

Modifié le 12 mars 2021 par MilesTEG1

[oracle7]

@MilesTEG1

Bonjour,

A tout hasard, retires l'@IP de ton 214play de l'agent de imputs.snmp dans le fichier telegraf.conf. Et regardes si cela a un impact ...

PS : as-tu vu mon MP ?

Cordialement

oracle7😉

Modifié le 12 mars 2021 par oracle7

[MilesTEG1]

@oracle7

J'ai rallumé le 214play, et bam, les mesures tombent bien toutes les 30s pour tous les périphériques...

Si je retire l'IP du 214play du fichier de configuration telegraf.conf, je vais retrouver les mesures toutes les 30s pour seulement le routeur et le 920+.
Du coup, faut que je crée une instance dédiée au 214play ?

Et sinon, je viens juste de le voir, je vais aller le lire 😉 

[oracle7]

@MilesTEG1

Bonjour,

Bah si tu souhaites ne mettre en service ton 214 play qu'épisodiquement alors c'est peut-être la (bonne je ne sais) solution (nouvelle instance) mais c'est quand même bizarre qu'un périphérique arrêté perturbe tant que cela la chaîne d'acquisition de données de l'ensemble.

Peut-être que @.Shad. aura une bonne explication à cela ...

Cordialement

oracle7😉

[MilesTEG1]

@oracle7

Je m'en vais créer un docker-compose.yml pour une instance telegraf dédiée au 214play.
En attendant les potentielles réponses de notre expert @.Shad. 😇

Modifié le 12 mars 2021 par MilesTEG1

[.Shad.]

Il y a 4 heures, oracle7 a dit :

C'est bien parce que j'utilise déjà un ce ces dossiers

L'idée c'est d'utiliser le dossier /usr/share/snmp/mibs pour les mobs Synology, et par exemple /root/.snmp/mibs pour les mibs de Hik.

Tes logs disent que ces dossiers là sont parcourus, contrairement au dossier hik dans les mibs.

Visiblement les mibs search paths ne valent que pour le dossier cible, et pas automatiquement tous les enfants.

[MilesTEG1]

En fait je me dis que je vais ajouter une section à mon fichier tout en un 😉

  monitoring_telegraf_214play:
    image: "telegraf:latest"
    container_name: monitoring_telegraf_214play
    hostname: monitoring_telegraf_214play
    depends_on:
      - monitoring_influxdb
    networks:
      - monitoring_nas
    environment:
      - TZ=Europe/Paris
      - PUID=1000
      - PGID=100    
    labels:
      - "com.centurylinklabs.watchtower.enable=true"
    volumes:
      - /volume1/docker/monitoring/telegraf_214play/telegraf.conf:/etc/telegraf/telegraf.conf:ro
      - /usr/share/snmp/mibs:/usr/share/snmp/mibs:ro
    ports:
      - "8126:8125/udp"
      - "8093:8092/udp"
      - "8095:8094"
    restart: unless-stopped

Je pense que les ports doivent être modifiés, mais je ne suis pas sur que ce soit utile d'en mettre...

j'ai créé une base de donnée dans influxdb, et en lui affectant l'utilisateur nas_monitoring 😉 Et j'ai ajouté cette base de donnée dans Grafana.

Tout fonctionne bien maintenant 😉
Par contre, est-ce possible de combiner dans ce panel les infos des deux bases de données ?
Car à un moment donné, le 214play va bien disparaitre de ce tableau. Et j'aimerais bien ne pas faire un nouveau panel dédié ^^

[oracle7]

@MilesTEG1

Bonjour,

Je crains de ne te décevoir mais pour un panel donné tu ne peux avoir qu'une et une seule source de données ce qui somme toute est logique.

Donc tu n'as pas le choix que de créer un nouveau panel Pour ton 214 play (en dupliquant le panel existant et en lui affectant ta nouvelle source de données correspondante de ta nouvelle base de données).

Cordialement

oracle7😉

[.Shad.]

Non tu peux créer une variable de type Datasource. Et avoir plusieurs NAS dans le même tableau de bord.

Avec l'incendie d'OVH je peux pas montrer d'impression d'écran, mais une rapide recherche Google devrait suffire.

[oracle7]

@.Shad.

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

Non tu peux créer une variable de type Datasource

OK pourquoi pas mais alors pour juste bien comprendre, comment tu l'utilises cette variable "Datasource". a priori et sauf erreur de ma part, on ne peut pas la mettre/utiliser dans la requête elle même (l'éditeur ne le permet pas tout comme le language InfluxQL).

Pour une requête donnée dans un même panel, le popup de choix de la source ne permet que de choisir qu'une et une seule source de donnée et implicitement toutes les requêtes SELECT ... FROM measurement se font sur la source de données désignée par ce popup.

Merci de BV STP éclairer ma lanterne sur ce point. Je serais heureux de connaitre la solution car cela pourrait me faciliter la vie sur certains points que j'avais écartés jusqu'à présent.

Cordialement

oracle7😉

[MilesTEG1]

@.Shad.

Je rejoins @oracle7 dans la demande d'explications. Car je me souviens que tu as déjà parlé ici de ces variables, mais je n'ai jamais réussi à m'en servir.

Et là je cherche où on les crée dans Grafana sans trouver...

Ton VPS était dans le datacenter qui a brulé ?

[oracle7]

@MilesTEG1

Bonjour,

Tu vas dans le Dashbord Setting (roue dentée) et ensuite dans le menu à droite dans le nouvel écran tu as l'item "Variables"

Après, c'est simple ... tu affecte une requête à ta variable par ex :

Cordialement

oracle7😉