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

oracle7 · le 3 octobre 2022

@.Shad.

Bonjour,

Finalement pour ma question :

J'ai trouvé le problème : l'option "com.docker.network.bridge.name" ne supporte pas un nom de réseau > 15 caractères sinon on récupère le message d'erreur.

A toi de voir, mais il serait peut-être judicieux d'insérer dans ton TUTO cette précision pour éviter des déconvenues, non ?

Cordialement

oracle7😉

.Shad. · le 3 octobre 2022

@oracle7 Ah oui en effet j'ajouterai la précision, mon nom de réseau était bien plus court, je n'aurais pas imaginé.
Et les messages d'erreur sont flous au possible.

MilesTEG1 · le 3 octobre 2022

il y a une heure, oracle7 a dit :

@.Shad.

Bonjour,

Finalement pour ma question :

J'ai trouvé le problème : l'option "com.docker.network.bridge.name" ne supporte pas un nom de réseau > 15 caractères sinon on récupère le message d'erreur.

A toi de voir, mais il serait peut-être judicieux d'insérer dans ton TUTO cette précision pour éviter des déconvenues, non ?

Cordialement

oracle7😉

Tu mets cette option où dans ton docker-compose ?
Car moi je nomme mes réseau avec une autre option, name: nom_du_reseau
Par exemple avec le docker-compose de NextCloud que je vais installer prochainement :

networks:
  nextcloud_network:
    ipam:
      driver: default
      config:
        - subnet: 172.31.0.0/16
          gateway: 172.31.0.1
    name: nextcloud_network

Le nom le plus long que j'ai est : another_bridge_network

La longueur dépasse les 15 caractères...

oracle7 · le 3 octobre 2022

@MilesTEG1

Bonjour,

Désolé mais je crains que tu ne mélanges les choses. Pas grave ! 🤪 Ce n'est pas dans le docker-compose qu'il y a problème mais lorsque tu crées la première fois ton réseau bridge personnalisé :

Soit tu passes par l'interface de docker dans DSM et là pas soucis.
Soit tu utilises sous SSH en CLI la commande et là risque de soucis :

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

Le problème que j'ai souligné se passe au niveau de l'option "com.docker.network.bridge.name" de cette dernière.

Par exemple ici "br_monitoring" ne pose pas de problème car < 15 caractères. Par contre si dans l'option tu saisis par exemple : "br_nextcloud_network" tu auras l'erreur et pas de création du réseau.

Pour l'intant, je n'ai pas recontré d'anomalies avec des noms "longs" pour les réseaux. Par exemple ici "monitoring". Donc dans ton cas "nextcloud_network", bien que faisant lui plus de 15 caractères, doit passer aussi. C'est donc juste le nom donné pour l'option de la commande CLI qui est limité à 15 car. Cela dit à mon humble avis une bonne pratique serait de ne pas dépasser 15 car dans tous les cas. Maintenant ce que j'en dit ...

Est-ce plus clair comme cela ?

Cordialement

oracle7😉

MilesTEG1 · le 3 octobre 2022

il y a 28 minutes, oracle7 a dit :
Bonjour,

Désolé mais je crains que tu ne mélanges les choses. Pas grave ! 🤪 Ce n'est pas dans le docker-compose qu'il y a problème mais lorsque tu crées la première fois ton réseau bridge personnalisé :

Soit tu passes par l'interface de docker dans DSM et là pas soucis.

Soit tu utilises sous SSH en CLI la commande et là risque de soucis :
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
Le problème que j'ai souligné se passe au niveau de l'option "com.docker.network.bridge.name" de cette dernière.

Hello @oracle7

Ha ok tu passes par la création du réseau avant de faire ton docker-compose up -d.

Est-ce vraiment utile ?
Moi c'est Portainer qui se charge de créer le réseau avec le bout de code que je t'ai mis en exemple.

Alors je vois juste une faille dans ma manière de procéder, c'est que mes réseaux sont en /16 et pas /24... donc je ne peux pas créer un 172.18.5.0/24 ça me fait une erreur, il faut avoir créer le 172.18.0.0/16 avant, et dans le yml je peux ensuite joindre le réseau 172.18.5.0/24, enfin je crois...

Pour le moment je ne suis pas limité par ma manière de faire...
Mais il se peut qu'un jour je doive faire comme toi, créer en amont chaque réseau. Ce qui serait effectivement plus propre ^^

PS : je viens de checker un de mes réseaux qui a le plus grand nom :

root@Syno-DS920Plus:~# docker network inspect another_bridge_network
[
    {
        "Name": "another_bridge_network",
        "Id": "4a8ca8c60c6070d1ca170322d53415e30633bd919d757ae114dfe9b264696ca6",
        "Created": "2022-09-27T14:29:25.885019615+02:00",
        "Scope": "local",
        "Driver": "bridge",
        "EnableIPv6": false,
        "IPAM": {
            "Driver": "default",
            "Options": null,
            "Config": [
                {
                    "Subnet": "172.25.0.0/16",
                    "Gateway": "172.25.0.1"
                }
            ]
        },
        "Internal": false,
        "Attachable": false,
        "Ingress": false,
        "ConfigFrom": {
            "Network": ""
        },
        "ConfigOnly": false,
        "Containers": {
            "04ee26bd5e6c9af971185845b04b6a6589849dda196916555d21e39d9dba1e52": {
                "Name": "uptime-kuma",
                "EndpointID": "a3f0e42c3cf4d24e16523bab80b954d0eda2dfefac4d78275f090d8f9ffc8d2f",
                "MacAddress": "02:42:ac:19:00:02",
                "IPv4Address": "172.25.0.2/16",
                "IPv6Address": ""
            }
        },
        "Options": {},
        "Labels": {
            "com.docker.compose.network": "another_bridge_network",
            "com.docker.compose.project": "uptime_kuma",
            "com.docker.compose.version": "2.5.1"
        }
    }
]

En fait, via le docker-compose.yml, ça ne met pas de nom, mais un label !!
C'est bien ça ?

Est-ce vraiment gênant ? Les noms apparaissent pourtant bien :

root@Syno-DS920Plus:~# docker network ls
NETWORK ID     NAME                     DRIVER    SCOPE
5ed7dd5c7e9c   acme_network             bridge    local
4a8ca8c60c60   another_bridge_network   bridge    local
334450caab79   bridge                   bridge    local
e83521a723b7   calibre-web_default      bridge    local
bf0ac7a99d3d   crowdsec_network         bridge    local
e2dccb0c6a4a   dashy_default            bridge    local
b30ea1417684   gitea_network            bridge    local
eaafac945a80   host                     host      local
adb21693ea83   macvlan-network          macvlan   local
9811a31122a1   monitoring_nas           bridge    local
ffc1a99be78a   none                     null      local
50eb4078411a   plex_tautulli            bridge    local
177958463c88   vaultwarden_network      bridge    local

MilesTEG1 · le 3 octobre 2022

Je viens de tester la création d'un réseau avec cette commande :

docker network create -d bridge \
--subnet=172.33.0.0/24 \
--gateway=172.33.0.1 \
br_monitoring_blablalbaeazazazazazdadazdazd

Le nom est bien présent :

root@Syno-DS920Plus:~# docker network ls
NETWORK ID     NAME                                          DRIVER    SCOPE
5ed7dd5c7e9c   acme_network                                  bridge    local
4a8ca8c60c60   another_bridge_network                        bridge    local
b23276c4eabc   br_monitoring_blablalbaeazazazazazdadazdazd   bridge    local

root@Syno-DS920Plus:~# docker network inspect br_monitoring_blablalbaeazazazazazdadazdazd
[
    {
        "Name": "br_monitoring_blablalbaeazazazazazdadazdazd",
        "Id": "b23276c4eabcb59217ce72f145e94d1f4873f04ca2f15c7dee515cde665d0d59",
        "Created": "2022-10-03T18:08:32.084529277+02:00",
        "Scope": "local",
        "Driver": "bridge",
        "EnableIPv6": false,
        "IPAM": {
            "Driver": "default",
            "Options": {},
            "Config": [
                {
                    "Subnet": "172.33.0.0/24",
                    "Gateway": "172.33.0.1"
                }
            ]
        },
        "Internal": false,
        "Attachable": false,
        "Ingress": false,
        "ConfigFrom": {
            "Network": ""
        },
        "ConfigOnly": false,
        "Containers": {},
        "Options": {},
        "Labels": {}
    }
]

Du coup, pourquoi s'embêter à mettre l'option pour le nom quand tu crées en ligne de commande ?

Moi je dois faire ça avec le docker-compose.yml via portainer, sinon ce dernier me nomme le réseau en ajoutant le nom du conteneur derrière...

oracle7 · le 3 octobre 2022

@MilesTEG1

Bonjour,

il y a 6 minutes, MilesTEG1 a dit :

Du coup, pourquoi s'embêter à mettre l'option pour le nom quand tu crées en ligne de commande ?

Je vais laisser notre gourou @.Shad. te répondre sur ce point précis qu'il maitrise mieux que moi 😜.

Pour ma part je procède ainsi :

Création du réseau via la commande adhoc.
Dans chaque conteneur je désigne le réseau à utiliser networks:RéseauX:external: true.
Pour chaque conteneur, j'affecte une @IPv4 et une @MAC pour pouvoir le cas échéant atteindre directement le conteneur (même si ce n'est pas toujours utile je te l'accorde).
Idem quand plusieurs conteneurs sont sur un même réseau, mais alors je laisse la résolution DNS par nom faire son boulot pour qu'ils communiquent entre eux.

Bon tout cela est mal dit mais c'est le principe.

Cordialement

oracle7😉

.Shad. · le 4 octobre 2022

@MilesTEG1 L'option de nommage du bridge, c'est le nom de l'interface adhoc créée sur le NAS (172.x.0.1), pas le nom du réseau. Ca évite de se taper un nom d'interface généré aléatoirement.

@oracle7 Tu es sûr de ta limite de 15 caractères ? Ca me semble peu, et @MilesTEG1 a visiblement des noms de réseau beaucoup plus longs que 15 caractères.

oracle7 · le 4 octobre 2022

@.Shad.

Bonjour,

Il y a 5 heures, .Shad. a dit :

Tu es sûr de ta limite de 15 caractères ? Ca me semble peu, et @MilesTEG1 a visiblement des noms de réseau beaucoup plus longs que 15 caractères.

Comme tu le dis c'est le nom de l'interface créée et pas le nom du réseau. Donc manisfestement les noms de réseaux, eux, supportent sans problème plus de 15 car.

Dans tous les cas voici ma source : https://gist.github.com/brthor/b035052bad98e0a2d7c0e925d2d86a2a

Cordialement

oracle7😉

MilesTEG1 · le 4 octobre 2022

@oracle7 du coup il n’y a aucun intérêt à nommer l’interface, ce nom n’est jamais utilisé dans le docker-compose, non ?

Quand je liste mes réseaux, que ce soit via portainer ou via la commande terminal , j’ai bien les noms que je mets dans mon docker-compose.

ps : sinon Vu que j’ai migré mon paquet docker et ses conteneurs sur le ssd (mvne, oui je sais c’est bricoler 😆) j’ai recrée tous mes conteneur en spécifiant pour chacun une adresse iP définie que je note dans un fichier .md (je peux fournir le prototype 😉) .

ca me permet de vérifier quels sont les conteneurs que j’isole des autres.

pour le moment, chaque conteneur (ou groupe qui vont ensemble comme Plex et tautulli , ou bien la stack monitoring) ont un réseau à eux.

jz n’arrive pas à me décider pour portainer et watchtower vu qu’ils ont besoin tous les deux du docker.sock : est-ce que je les laisse ensemble dans le bridge système (celui par défaut) ? Ou bien je crée un réseau dédié à chacun ?

en tout ça la création du conteneur va plus vite sur le nvme 😆

oracle7 · le 4 octobre 2022

@MilesTEG1

Bonjour,

Il y a 2 heures, MilesTEG1 a dit :

du coup il n’y a aucun intérêt à nommer l’interface, ce nom n’est jamais utilisé dans le docker-compose, non ?

Effectivement pour ma part j'ai fait que suivre la préconisation de @.Shad. dans son TUTO, ni plus ni moins.

EDIT : Pour info, le nom de l'interface réseau "br_xxxxxx" que l'on donne à la création du réseau bridge personalisé, apparaît (entre autre) dans le moniteur de ressources de DSM dans l'onglet Réseau.

Sinon, de mon coté j'ai regroupé :

Acme et Portainer dans un réseau unique synology-network
Gotify et Watchtower dans un réseau gotify-network puisque ces derniers communiquent ensembles (enfin surtout watchtower vers gotify !).

Maintenant, sauf erreur de ma part, ce n'est pas parce que des conteneurs utilisent le docker.sock qu'ils doivent partager le même réseau, cela ne me parait pas utile voire pas nécessaire ou impératif mais je peux me tromper.

Cordialement

oracle7😉

Modifié le 4 octobre 2022 par oracle7

oracle7 · le 7 octobre 2022

@.Shad.

Bonjour,

Pourrais-tu STP essayer de m'expliquer ce comportement (en espérant que je vais être clair dans sa description et que tu auras une réponse !) :
Sous SSH, le répertoire /run/docker a les droits 0755 et le répertoire /run/docker/netns a les droits 0700 sachant que tous les deux sont root:root. J'accède sans problème au contenu de /run/docker/netfs.

Dans le docker-compose de telegraf, je monte le volume " - /:/hostfs:ro " conformément à la doc de https://registry.hub.docker.com/_/telegraf pour monitorer le docker engine host.

Maintenant, lorsque que je rentre dans le conteneur telegraf (docker exec -it telegraf bash), il m'est impossible d'accèder au répertoire /hostfs/run/docker/netns.

Par ailleurs lors de l'exécution du conteneur telegraf, je récolte ce type d'erreur dans le log de telegraf, ce qui semble confirmer le point précédant et être l'origine de l'erreur :

2022-10-07T14:41:15+02:00 D! [outputs.influxdb_v2] Wrote batch of 119 metrics in 30.460364ms
2022-10-07T14:41:15+02:00 D! [outputs.influxdb_v2] Buffer fullness: 0 / 10000 metrics
2022-10-07T14:41:20+02:00 D! [inputs.disk] [SystemPS] => unable to get disk usage ("/hostfs/run/docker/netns/5fdd4d03d1d4"): permission denied
2022-10-07T14:41:20+02:00 D! [inputs.disk] [SystemPS] => unable to get disk usage ("/hostfs/run/docker/netns/a23d3dd3c162"): permission denied
2022-10-07T14:41:20+02:00 D! [inputs.disk] [SystemPS] => unable to get disk usage ("/hostfs/run/docker/netns/597f58313571"): permission denied
2022-10-07T14:41:20+02:00 D! [inputs.disk] [SystemPS] => unable to get disk usage ("/hostfs/run/docker/netns/cbb43ff4dc01"): permission denied
2022-10-07T14:41:20+02:00 D! [inputs.disk] [SystemPS] => unable to get disk usage ("/hostfs/run/docker/netns/5eeb93e81603"): permission denied
2022-10-07T14:41:20+02:00 D! [inputs.disk] [SystemPS] => unable to get disk usage ("/hostfs/run/docker/netns/c2c97a718e7d"): permission denied
2022-10-07T14:41:20+02:00 D! [inputs.disk] [SystemPS] => unable to get disk usage ("/hostfs/run/docker/netns/0984314f543e"): permission denied
2022-10-07T14:41:20+02:00 D! [inputs.disk] [SystemPS] => unable to get disk usage ("/hostfs/run/docker/netns/b06ebc0f4f59"): permission denied

Pour me sortir, de ce type d'erreur, je suis obligé d'activer la commande : mount_points = ["/"] dans [[inputs.disk]] dans le fichier telegraf.conf :

#----------------------------------------------------------
  ## Read metrics about disk usage by mount point
[[inputs.disk]]
  ## Set mount_points will restrict the stats to only the specified mount points.
  mount_points = ["/"]
  ## Ignore mount points by filesystem type.
  ignore_fs = ["tmpfs", "devtmpfs", "devfs", "iso9660", "overlay", "aufs", "squashfs"]

Selon toi est-ce normal ? en SNMPV2c, il n'y avait pas besoin de cela. Pour mémoire je suis en SNMPv3. Je ne vois pas le lien et du coup je ne comprends pas et donc, saurais-tu STP éclairer ma lanterne ? D'avance Merci.

Cordialement

oracle7😉

.Shad. · le 7 octobre 2022

Tu as mis les variables d'environnement qui vont de paire avec le montage de volume ?

Mon compose pour Telegraf sur mon VPS si ça peut t'aider, et pas eu besoin de décommenter le "/" dans [inputs.disk] :

telegraf:
      image: telegraf
      container_name: telegraf
      networks:
         - net-monitoring
      # non-root user needed since 1.20.3
      user: 1001:998
      environment:
         - HOST_MOUNT_PREFIX=/hostfs
         - HOST_PROC=/hostfs/proc
         - HOST_ETC=/hostfs/etc
         - HOST_SYS=/hostfs/sys
         - HOST_VAR=/hostfs/var
         - HOST_RUN=/hostfs/run
      volumes:
         # config
         - /opt/monitoring/telegraf/telegraf.conf:/etc/telegraf/telegraf.conf:ro
         # disks input
         - /etc:/hostfs/etc:ro
         - /proc:/hostfs/proc:ro
         - /sys:/hostfs/sys:ro
         - /var:/hostfs/var:ro
         - /run:/hostfs/run:ro
         - /:/hostfs:ro
         # docker socket mounting
         - /var/run/docker.sock:/var/run/docker.sock:ro
         # additionnal MIBs
         - /var/lib/snmp/mibs:/usr/share/snmp/mibs:ro
         - /var/lib/snmp/mibs/ietf:/usr/share/snmp/mibs/ietf:ro
         - /var/lib/snmp/mibs/iana:/usr/share/snmp/mibs/iana:ro
         # system mounting
         - /run/udev:/run/udev:ro
      labels:
         - "com.centurylinklabs.watchtower.enable=true"
      depends_on:
         - influxdb
      restart: unless-stopped

oracle7 · le 7 octobre 2022

@.Shad.

Bonjour,

Oui, j'avais déjà bien mis les variables d'environnement pour les disk inputs.

Au détail près du montage du volume /run/udev et des volumes de montages des MIBs, mon docker-compose est très proche du tien. D'ailleurs quelle est l'utilité de ce /run/udev ?

Au passage, pour réinitialiser InfluxDB2 proprement, à part supprimer l'image et vider le contenu du dossier d'installation /volume1/docker/monitoring/influxdb2-data, y-a-t-il autre chose à nettoyer ailleurs ? J'ai perdu le dashbord fourni en standard avec influxDB2 et j'aimerai le retrouver. Je n'ai rien trouvé de vraiment semblable sur https://github.com/influxdata/community-templates .

Cordialement

oracle7😉

.Shad. · le 8 octobre 2022

/run/udev c'est pour pouvoir classer les disques par tag dans Grafana.

Pour InfluxDBv2 aucune idée, je ne l'utilise pas. Repars d'une installation clean.

Dimebag Darrell · le 31 mars 2023

Bonjour tout le monde,

Je reviens vers vous car j'ai remarqué ce type d'erreur dans mes logs sur telegraf. (container)

2023-03-31T11:56:03Z E! [outputs.influxdb] 
When writing to [http://localhost:8086]: 
failed doing req: Post "http://localhost:8086/write?db=telegraf": 
dial tcp 127.0.0.1:8086: connect: connection refused

Après avoir checker les droits users dans influxdb
Je vois ceci :

user admin

---- -----

admin true

user_telegraf false

Mais malgré tout, mon monitoring fonctionne, et les données ont l'air d'être bien poussées (car dispo dans grafana)

Une idée ?

Modifié le 31 mars 2023 par Dimebag Darrell

.Shad. · le 31 mars 2023

Il y a 5 heures, Dimebag Darrell a dit :

Mais malgré tout, mon monitoring fonctionne, et les données ont l'air d'être bien poussées (car dispo dans grafana)

Tu es sûr que ce sont des données récentes que tu vois ? On peut se faire avoir avec les tables, en revanche sur les graphiques c'est plus évident.

Pour moi y a une erreur dans ton paramétrage, sauf si Telegraf et InfluxDB sont en mode host.
Si pas le cas, c'est normal que la connexion soit refusée, il n'y a rien sur le port 8086 du conteneur Telegraf.
Ton instance Telegraf devrait pousser les données vers http://influxdb:8086, où influxdb est le nom du conteneur InfluxDB et où les deux conteneurs Telegraf et InfluxDB sont dans le même réseau bridge.

Dimebag Darrell · le 31 mars 2023

telegraph, correspond aux info venant des traps snmp du syno.

par exemple CPU load sur mon syno, sachant que j'ai détecté le problème hier soir...

néanmoins, comment je peux corriger cette erreur ?

J'ai essayé en faisant un GRANT ALL on.... TO... sur le user de la db, mais je n'ai pas vu les droits changer

.Shad. · le 1 avril 2023

Je ne vois pas le rapport entre ta réponse et ma réponse. 😕
Il faut que tu commences par éclaircir les points que j'ai soulignés dans ma réponse.
A moins tu aies créé un nouvel utilisateur, ou une nouvelle db Telegraf, il n'y a aucune raison d'aller changer les permissions des utilisateurs d'InfluxDB sur leur base de donnée.

Dimebag Darrell · le 1 avril 2023

@.Shad.

Dans ma réponse, je montre que les données arrivent toujours bien vers influxdb --> grafana.
les données sont à jours.

Par contre, lorsque je regarde les droits des user dans influxDB, je vois ceci

ser admin

---- -----

admin true

user_telegraf false

J'ai essayé de faire un GRANT ALL ON monitoring_telegraf (nom de la db) TO user_telegraf.
Le user reste tjs en false... ! (donc aucun droit admin)

.Shad. · le 1 avril 2023

C'est normal qu'il ne soit pas admin.
L'utilisateur est sensé avoir tous les droits sur la base de donnée qui lui est associée, c'est ce que tu fais avec GRANT ALL TO ... ON ...

Pas avoir tous les droits sur toutes les bases de données.
Par défaut, le seul utilisateur admin est celui spécifié dans ton fichier compose lors de la création initiale du conteneur.
Le problème est là où je l'ai signalé, si c'était un problème de droit tu n'aurais pas eu un "connection refused" mais un "permission denied" ou équivalent.

Modifié le 1 avril 2023 par .Shad.

Dimebag Darrell · le 1 avril 2023

@.Shad.

user admin

---- -----

admin true

user_telegraf false

J'essaie de reconstituer l'idée, que signifie alors "false" pour user_telegraf ?
D'où viendrait le problème alors ?

la solution, repartir de 0 et refaire complètement le container et ses DBs ?

.Shad. · le 1 avril 2023

Ca veut juste dire qu'admin est admin, et que user_telegraf n'est pas admin.
Rien de plus normal.

Pourquoi tout recommencer, je t'ai posé des questions (sans point d'interrogation je reconnais) dans ma première intervention :

Il y a 22 heures, .Shad. a dit :

Pour moi y a une erreur dans ton paramétrage, sauf si Telegraf et InfluxDB sont en mode host.
Si pas le cas, c'est normal que la connexion soit refusée, il n'y a rien sur le port 8086 du conteneur Telegraf.
Ton instance Telegraf devrait pousser les données vers http://influxdb:8086, où influxdb est le nom du conteneur InfluxDB et où les deux conteneurs Telegraf et InfluxDB sont dans le même réseau bridge.

Donc en reformulant :

Est-ce qu'InfluxDB et Telegraf sont en mode bridge ?
Si oui, est-ce que les deux conteneurs dans le même réseau bridge ?

Dimebag Darrell · le 2 avril 2023

Il y a 17 heures, .Shad. a dit :

Ca veut juste dire qu'admin est admin, et que user_telegraf n'est pas admin.
Rien de plus normal.

Pourquoi tout recommencer, je t'ai posé des questions (sans point d'interrogation je reconnais) dans ma première intervention :

Donc en reformulant :

Est-ce qu'InfluxDB et Telegraf sont en mode bridge ?

Si oui, est-ce que les deux conteneurs dans le même réseau bridge ?

Donc en reformulant :

Est-ce qu'InfluxDB et Telegraf sont en mode bridge ?
oui
Si oui, est-ce que les deux conteneurs dans le même réseau bridge

.Shad. · le 2 avril 2023

Tu peux copier-coller ici le contenu de [[outputs.influxdb]] de ton fichier de configuration telegraf.conf ?

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

Contributeurs populaires

Annonces

Information importante