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

[.Shad.]

Tu as vu mon edit ?

[MilesTEG1]

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

Tu as vu mon edit ?

Ha non... je vais voir 😇

[MilesTEG1]

Bon j'ai mis à 30s d'intervalle.

Sur les graphiques, l'intervalle entre deux mesures est bien de 30s.

Sinon, je suis en train de regarder comment tu as déterminé la mémoire utilisé sur le NAS :

Et le truc c'est que le NAS ne me dit pas la même chose :

Les seuls possibilités de valeurs de mémoire sont : 

Du coup, je ne sais pas comment faire pour faire afficher les 9% d'utilisation indiqué par le NAS...

 

Dernière chose : est-ce qu'il est possible de ne pas afficher les Storage Pool dans les données sur la raidTable ?
 

[MilesTEG1]

J'ai trouvé dans des messages du sujet comment faire pour l'UPS 😄

Maintenant je voudrais réussir à faire ce genre de chose pour les températures :

 

Et comment on peut arriver à faire 3 jauges en un seul élément de dashboard ??

[.Shad.]

Pour cumuler les graphs sur un même panel :

Pour la mémoire, j'ai quelque chose de sensiblement proche de ce que je constate dans le moniteur de ressources de DSM.
Après concrètement, je ne m'en sers pas pour avoir un suivi précis des stats de mes périphériques.
Mais si le NAS plante, et que le moniteur de ressources le fait aussi, je peux quand même avoir une vue de ce qu'il s'est passé : variation de CPU, mémoire, etc...

D'ici quelques temps je rédigerai un nouveau chapitre lié à la consultation des logs, mais c'est autrement plus compliqué.
Plein de zones d'ombre sur lesquelles je ne me suis pas encore attardé.

[Nasme]

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

@Nasme : en plus de ce que dit @MilesTEG1, tu n'es pas dans la bonne section, c'est inputs.docker et pas inputs.docker_log

 

Bonjour,

J'ai bien remarqué la différence mais je n'ai pas de inputs.dcker dans le ficher ! J'ai seulement inputs.docker_log ?

 

Je vais recommencer mon fichier du début. Il manque du texte que je viens de trouver.

Modifié le 1 septembre 2020 par Nasme

[Nasme]

Bonjour,

J'ai réparé mon fichier. Est-ce que quelqu'un pourrait me donner un exemple de ce que cette partie du fichier doit être pour afficher les containers ?

# # 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 = true
#
#   ## 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 = []
#   # 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

Je ne suis pas certain de mon coup car je suis vraiment novice dans ce domaine.

Merci beaucoup

[MilesTEG1]

@Nasme

C'est écrit dans le tuto, §VI :

Toutes les lignes où il manque le # du début sont celles à décommenter et donc où il faut enlever le # du début.
Tu peux faire un copier/coller de la partie du tuto (j'ai mis une capture d'écran là hein).

 

@.Shad.Ok, je vais voir si j'arrive à reproduire les jauges pour les températures.

[MilesTEG1]

Voilà 😄

. 

Bon, par contre, je suis pas sur de laisser ainsi XD
 

 

Sinon pour les graphiques des débits/CPU/RAM, je viens de me rendre compte que j'ai des points de mesures où il manque carrément la valeur de ce qui est mesuré... C'est pour ça je pense que mes graphiques sont pas terrible...
Quelqu'un a des idées sur le pourquoi ?

[Nasme]

Merci,

J'y arrive doucement 🙂 

Mais j'ai cette erreur dans telegraf: 
2020-09-01T20:10:12Z E! [telegraf] Error running agent: Error loading config file /etc/telegraf/telegraf.conf: Error parsing system, line 2841: field corresponding to `endpoint' is not defined in system.SystemStats,
2020-09-01T20:21:30Z E! [inputs.docker] Error in plugin: Error response from daemon: This node is not a swarm manager. Use "docker swarm init" or "docker swarm join" to connect this node to swarm and try again.

[MilesTEG1]

@Nasme

Envoie le fichier telegraf.conf, il doit y avoir un soucis dans la ligne 2841.

Je suis preneur des requêtes et formatage de tes graphiques, surtout ceux de la ram, du cpu et du réseau 😄

 

[MilesTEG1]

Je suis en train de voir aussi que les valeurs dans grafana ne sont pas tout à fait celles que j'ai dans le NAS :

   

Le requête :     

Dans les unités, il y a ça de possible :   

J'ai essayé diverses unités byteo ou bits (en metric ou en IEC), sans réussir à obtenir les mêmes valeurs que celles du NAS.
Savez-vous où se trouve l'erreur ?

[MilesTEG1]

Pour la capacité, j'ai trouvé 😄

Dans les fichiers MIB, il est écrit que les données sont en byte.
Et dans Grafana, il faut choisir bytes(IEC) (je pensais l'avoir essayé...)

Et du coup, j'ai les bonnes valeurs, même si l'unité est devenue TiB au lieu de TB du NAS 🤪
Faut que j'aille voir pour la RAM, je suis sur que les différences viennent de là aussi...

[Nasme]

J'ai corrigé mon problème, il manquait une dièse pour ce qui est de "swarm"

[oracle7]

 @.Shad.

Je viens de créer mon premier conteneur (influxdb1) et voilà mes premières questions ...

1. Lors de la création de ce conteneur influxdb pour les paramètres de port on laisse bien les valeurs proposées par défaut, à savoir ( Auto 8086 TCP) ? On ne redirige pas les ports comme indiqué dans le TUTO 1  (8080 -> 80 et 8443 -> 443) ce n'était valable que pour heimdall, c'est çà ?
    

2. Le 31/05/2019 à 22:02, .Shad. a dit :

   3/ Création du conteneur InfluxDB

   On commence par InfluxDB, car sans lui Telegraf ne saura pas exporter ses métriques, et Grafana n'aura pas de source de métrique.
   On crée d'abord un dossier data dans le dossier du conteneur.

   Donc j'ai créé manuellement le dossier "/volume1/docker/influxdb" pour monter "/config" lors de la création du conteneur. J'ai ensuite modifié son GUI/PUI (root/root) par (users/monUserAdmin) comme expliquer dans le TUTO1 vis à vis des droits de L/E dans les volumes. Mais dois-je aussi faire cela pour le répertoire "data" que l'on ajoute ensuite ? ou bien je laisse le GUI/PUI à (root/root) ? (PS je fais cela dans une session WinSCP sous root).

3. Ensuite, ce n'est pas clair pour moi, le fichier 'docker-compose.yml" il va dans quel répertoire du conteneur donc "influxdb" ou "influxdb/data" ?

Cordialement

oracle7😉

Modifié le 6 septembre 2020 par oracle7

[.Shad.]

Il y a 12 heures, oracle7 a dit :

Lors de la création de ce conteneur influxdb pour les paramètres de port on laisse bien les valeurs proposées par défaut, à savoir ( Auto 8086 TCP) ? On ne redirige pas les ports comme indiqué dans le TUTO 1  (8080 -> 80 et 8443 -> 443) ce n'était valable que pour heimdall, c'est çà ?

C'est un NAT qu'on fait entre la machine hôte et le conteneur, de manière à très similaire à ce qu'on fait dans un réseau local entre un pare-feu/routeur/box et un périphérique du réseau.
Dans notre cas, InfluxDB écoute ce que lui envoie Telegraf (et éventuellement d'autres software capable de dialoguer avec InfluxDB, collectd par exemple) sur ce port.
Comme précisé dans les remarques concernant la mise en route du conteneur InfluxDB, à partir du moment où Telegraf et InfluxDB se trouvent dans le même réseau bridge personnalisé, il n'y aurait théoriquement même pas besoin d'exposer le port 8086 sur le NAS, car Telegraf et InfluxDB savent directement se causer, sans passer par l'hôte (le NAS).
Mais si par hasard, tu décidais d'exploiter InfluxDB pour d'autres périphériques de ton réseau, il faut qu'InfluxDB soit accessible, et seul le NAT entre hôte et conteneur permet de rendre les conteneurs accessibles au reste du réseau (cf analogie routeur et LAN).

A noter qu'on peut passer par un proxy inversé pour exposer InfluxDB, et utiliser le port 443. Très utile si on supervise aussi des machines distantes. 😉 

Et pour répondre plus précisément à la question, oui bien sûr les ports donnés dans le tutoriel sont purement adaptés à l'application prise en exemple.

Citation

Donc j'ai créé manuellement le dossier "/volume1/docker/influxdb" pour monter "/config" lors de la création du conteneur. J'ai ensuite modifié son GUI/PUI (root/root) par (users/monUserAdmin) comme expliquer dans le TUTO1 vis à vis des droits de L/E dans les volumes. Mais dois-je aussi faire cela pour le répertoire "data" que l'on ajoute ensuite ? ou bien je laisse le GUI/PUI à (root/root) ? (PS je fais cela dans une session WinSCP sous root).

Le dossier data va être généré par le lancement du conteneur.
De souvenir, car je n'utilise plus InfluxDB depuis longtemps sur mon NAS, il sera créé en root/root, car vu qu'on ne précise pas l'utilisateur et le groupe dans le docker-compose, il le fera par défaut en root/root.
Normalement ça ne posera aucun problème de fonctionnement.
Sur mon VPS, j'ai ajouté le paramètre :

user: "1001:1001"

dans le fichier docker-compose, même indentation que volumes, environment, etc...
Cela permet sans passer par les variables PUID/PGID, qui ne sont pas implémentés sur ces images (dommage car très adaptées aux NAS), de spécifier l'utilisateur exécutant les actions lors de la création du conteneur, et typiquement aussi les propriétaires des fichiers créés.
Sur mon VPS 1001:1001 est l'UID/GID de mon utilisateur, à remplacer par ce que tu souhaites utiliser sur ton NAS.
Je mets toutefois en garde car sur DSM ce n'est jamais évident de jouer avec ces paramètres, je ne vois pas de problème majeur à laisser root/root en tant que propriétaire des fichiers créés dans ton dossier influxdb.

Citation

Ensuite, ce n'est pas clair pour moi, le fichier 'docker-compose.yml" il va dans quel répertoire du conteneur donc "influxdb" ou "influxdb/data" ?

Le fichier docker-compose.yml se trouve dans le dossier du conteneur, donc tu as créé un dossier influxdb, et dedans tu crées un fichier docker-compose.yml, c'est tout ce que tu as avant de démarrer la création.

Modifié le 7 septembre 2020 par .Shad.

[oracle7]

@.Shad.

Bonjour,

Merci pour ces explications.

Le 31/05/2019 à 22:02, .Shad. a dit :

3/ Création du conteneur InfluxDB

On commence par InfluxDB, car sans lui Telegraf ne saura pas exporter ses métriques, et Grafana n'aura pas de source de métrique.
On crée d'abord un dossier data dans le dossier du conteneur.

Je ne comprend plus car dans ta précédente réponse :

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

Le dossier data va être généré par le lancement du conteneur.

Donc on crée manuellement ou pas ce dossier "data" ?

Encore une suggestion de précision pour les boulets comme moi : ajouter un couplet en fin de procédure de création (§ 3/, 4/ et 5/) pour chaque conteneur pour dire de le créer via la commande "compose-docker" car cela ne paraît pas évident à la lecture, on pourrait être tenter de le créer via l'interface Docker. Je me doute bien que c'est évident pour toi mais quand on découvre la chose ...

Cordialement

oracle7😉

[.Shad.]

Il faut créer en amont tous les dossiers qu'on monte, c'est-à-dire ceux qu'on retrouve dans le fichier docker-compose.yml

Donc mea culpa il faut bien le créer en amont.

Sinon concernant la commande c'est docker-compose et pas compose-docker, et elle est reprise dans les informations préliminaires concernant l'utilisation de docker-compose.

L'intérêt c'est justement qu'on peut utiliser la méthode qu'on veut, bien que je favorise grandement docker-compose pour sa flexibilité.

😉

Modifié le 7 septembre 2020 par .Shad.

[MilesTEG1]

En fait je pense qu'il veut parler de ceci :

Je t'avoue que j'ai été un peu perdu au début, je ne savais pas trop quand créer le conteneur avec la commande docker-compose.
J'ai finalement opté pour la création à la fin de chaque §, mais effectivement, le tuto mériterait d'avoir de clairement indiqué : lancer la commande ...

😇

[.Shad.]

Ok pas de souci je l'ajouterai 😉

2 retours c'est déjà plus significatif !

[oracle7]

@MilesTEG1

Bonjour et Merci d'avoir préciser ma pensée 😉 C'est exactement ce que j'ai voulu dire dans ma bafouille ... Et cela me rassure de voir que je n'ai pas été le seul à être perturbé.

Cordialement

oracle7😉

[MilesTEG1]

Je débutais moi aussi sous Docker ^^

(j'avais juste avant mis en place NextCloud avec Docker , donc rien de très complexe ^^ cela-dit, j'avais quand même un peu galéré, et surtout je n'étais pas passé par le fichier docker-compose... )

[oracle7]

@.Shad.

Bonjour,

Toujours pour bien comprendre la finalité des choses et donc ce que je configure.

Selon le TUTO tu préconises de créer un réseau bridge externe nommé "data_export" pour que tous les conteneurs qui lui sont adjoints, puissent communiquer par leur nom, au lieu d'utiliser des @IP.

Maintenant, je souhaiterais que le réseau auquel seront connectés/adjoints les conteneurs, soit spécifique et que chaque conteneur ait sa propre @IP fixe sur ce réseau afin de parfaitement "cloisonné" les choses. La configuration de ce réseau spécifique donnerait quelque chose du genre (à l'instar de ce qu'a fait de son coté @bruno78) :

Citation

networks:
    default:
        monitoring:
            driver: bridge
            ipam:
                driver: default
                config:

                 # Reseau .0; Passerelle .1; @IP conteneurs de .2 à .14; Diffusion .15
                  - subnet: 172.20.0.0/28
                    gateway: 172.20.0.1
                    ip_range: 172.20.0.0/28

Questions :

• Selon toi, finalement les réseaux "data_export" et "monitoring", puisque créés de façon externe, peut-on dire qu'ils sont équivalents ? Si Non, quelles différences présentent-ils, car là je ne saisi pas.
• Autrement dit : dans le cas du réseau "monitoring", les conteneurs qui lui seront affectés/adjoints, pourront-ils tous communiquer entre eux et échanger leurs données respectives comme dans le réseau "data_export" ?

Cordialement

oracle7😉

[.Shad.]

La seule différence entre réseau externe et réseau interne (défini dans un fichier docker-compose) c'est que lorsque tu feras un docker-compose down pour le 2ème cas, le réseau sera également effacé.
La 2ème option est totalement adaptée quand tu définis tous les services qui vont utiliser ce réseau dans un même fichier docker-compose.yml, à l'époque je ne m'intéressais à Docker que depuis 1 mois ou 2, si je devais refaire le tutoriel maintenant ce serait beaucoup plus "propre", mais ça permet à ceux qui s'intéressent à Docker de se confronter à autre chose que juste faire tourner une application. 😉 
Dans notre cas, il est clairement intéressant de regrouper les services au sein d'un même fichier.

Personnellement je préfère définir des réseaux externes pour les applications qui je le sais d'avance sont destinées à tourner en permanence.
Et j'utilise la génération interne pour ce que je teste.
C'est vraiment une question de goût.

Outre ces détails (importants), ça fonctionne exactement pareil.
@bruno78 a ajouté des paramètres permettant de définir exactement ce qu'on veut, c'est tout à fait faisable avec un réseau externe aussi.

Modifié le 7 septembre 2020 par .Shad.

[oracle7]

 @.Shad.

Bonjour,

Le 31/05/2019 à 22:02, .Shad. a dit :

Telegraf va dorénavant envoyer périodiquement les métriques à InfluxDB, ce qu'on peut constater dans les logs de ce dernier

Sauf erreur de ma part, à aucun moment tu ne parles dans le TUTO de durée de rétention des informations engrangées. J'imagine que par exemple après un mois de collecte la base influxdb ne soit déjà conséquente et que sans intervention elle continue de gonfler démesurément.

Aussi, en fouillant la toile, j'ai trouvé un gars qui lorsqu'il créait la base influxdb il ajoutait cette commande de rétention (ici sur une semaine) :

Citation

CREATE RETENTION POLICY one_week ON myinfluxdb DURATION 168h REPLICATION 1 DEFAULT;

Ton avis, puisque dans notre cas la base est créée de façon automatique, comment gère-t-on cette rétention pour limiter son volume donc accessoirement l'occupation sur disque ?

Cordialement

oracle7😉