La Fibre
Télécom => Logiciels et systèmes d'exploitation => 
Linux (usage serveur) => Discussion démarrée par: oijkn le 26 mai 2020 à 09:10:39
-
Bonjour à tous,
Etant à la recherche d'une alternative à notre bon vieux Smokeping et ne trouvant aucune solution qui puisse satisfaire mes besoins, entre autre de pouvoir superviser des milliers d'équipements (hé oui je bosse dans un NOC). Je me suis dit : "pourquoi pas coder ton propre outil"
Donc je me suis lancé dans ce projet nommé Infpyng (https://github.com/oijkn/infpyng) codé en Python 3 et couplé avec InfluxDB/Grafana
Quoi de mieux que la bonne commande “ping” pour découvrir si des hôtes répondent présents ou non dans un réseau. C'est un outil rustique mais très facile à utiliser.
En fait, la fonctionnalité qui manque principalement à "ping", c’est la possibilité d’enregistrer ses mesures dans une base de données et de tester plusieurs hôtes en même temps.
C’est là que Infpyng (https://github.com/oijkn/infpyng) apporte ses petits plus :
- Possibilité de tester 5 000 hôtes en moins de 2 minutes
- Ajout des hôtes dynamiquement sans redémarrer le script
- Configuration de l'intervalle de Polling
- Faible consommation de ressources
N'hésitez pas à me donner vos avis et retours.
Bonne journée.
-
Hello,
Interessant, ca fonctionnerait sous pfSense ?
Comment on l'installe ?
Sinon sous Windows ?
Merci.
-
Merci oijkn pour ton projet.
Je vais aller le tester.
-
Hello,
Interessant, ca fonctionnerait sous pfSense ?
Comment on l'installe ?
Sinon sous Windows ?
Merci.
Si tu configures bien tes règles dans pfSense je ne vois pas pourquoi cela ne fonctionnerait pas :)
Cela fonctionne que sous Linux car le fping sous Windows n'est plus maintenu et inexploitable.
Tu peux te monter un environnement Linux sous Windows (VM)
Pour l'installation tu as le modop sur github.
Merci oijkn pour ton projet.
Je vais aller le tester.
Merci à toi et tiens moi au courant :)
-
En cours de test, tout à l'air bon mais je découvre grafana. ;D
Peut-on avoir un exemple de requêtes ?
-
En cours de test, tout à l'air bon mais je découvre grafana. ;D
Peut-on avoir un exemple de requêtes ?
As-tu importé la dashboard que j'ai fourni comme exemple depuis github ?
-
Nope, je n'avais pas vu. ::)
-
Ça fonctionne très bien sur ma VM de test.
Une bonne solutions pour remplacer smokeping 8)
Bon travail.
-
Super merci ! Je suis encore en train de corriger un petit soucis avec le poller car au bout d'un certains temps, le timer déborde...
-
Il faudra aussi indiquer que ce plugin (https://github.com/CorpGlory/grafana-multibar-graph-pane) est à installer manuellement.
-
Il faudra aussi indiquer que ce plugin (https://github.com/CorpGlory/grafana-multibar-graph-pane) est à installer manuellement.
Ah oui bien vu merci :)
Plugin grafana-multibar-graph-panel (https://github.com/CorpGlory/grafana-multibar-graph-panel)
-
merci pour cette contribution.
Je recommanderais d'ajouter des tags git (https://git-scm.com/book/fr/v2/Les-bases-de-Git-%C3%89tiquetage) et de faire des "releases (https://help.github.com/en/github/administering-a-repository/managing-releases-in-a-repository)" dans github avec.
Il y a plusieurs avantages à faire cela:
- permettre aux utilisateurs de s'abonner pour recevoir des notifications quand y'a une nouvelle release (et donc de mettre a jour ou pas leur installation):
(https://i.imgur.com/zY0bJMx.png?1)
- permettre d'éviter d'installer le produit sans utiliser "git clone..." mais en téléchargeant un tar ou un zip propre de la release (typiquement avec un curl ou wget). Beaucoup de serveurs de prod n'ont pas 'git' d'installer par défaut. Le tar/zip permet aussi de ne distribuer que ce qui est nécessaire et pas forcement tout le contenu du repo.
- permettre d'utiliser un tag spécifique pour tester une version antérieure par exemple (avec 'git clone --branch <tag_name> ...' ou le tar/zip spécifique)
- permettre d'automatiser certaines choses avec des Github Actions (https://github.com/marketplace?type=actions) par exemple ou des outils de CI/CD (notamment Docker Hub si tu fais un Dockerfile un jour).
- pour finir la section 'releases' du projet constitue un changelog historisé automatiquement (si on prend soin de documenter les changements propre a chaque release).
Bref plein d'avantages des qu'un projet commence à avoir des utilisateurs (et même un mono utilisateur/projet privé cela a des avantages).
Je recommanderais aussi d'ajouter un Dockerfile/docker-compose pour faciliter le déploiement (notamment avec Windows par exemple ou pour les Raspberry Pi).
-
Bonjour kgersen,
Merci pour ton retour, j'en prend bien note.
Infpyng est encore en phase de test d'où l'absence de release, dès que j'obtiendrais une version satisfaisante je ferais une release :)
N'étant pas forcément à l'aise avec toutes les mécaniques de Git, j'essaie de m'en sortir comme je peux ^^ à l'occasion pourrais-je te solliciter si besoin, stp ?
Il faut que je me renseigne comment faire un binaire du projet pour le rendre portable et facilement installable.
-
oui n’hésite pas a nous solliciter.
-
Suite aux indications de kgersen, quel(s) conseil(s) me donneriez-vous afin de rendre se projet "portable" ?
C'est à dire de pouvoir le déployer facilement et le rendre compatible avec les différents OS Linux (désolé pas de Windows à cause du fping).
Merci pour votre aide.
-
Faire un binaire de la partie Python a peu d’intérêt en pratique. Python est pre-installé ou facilement dispo sur quasi tous les OS et systemes, etc. En plus les "packagers" Python ne pas trop portables en général.
Le problème est plus du coté des 'requirements' et composants dépendants:
**Requirements**
- Python 3.6.x or newer
- fping 4.x
- Grafana 6.7.x
- Influxdb 1.8.x
fping n'est dispo qu'en code source ou en package pour distro Linux (avec version arm & mips pour certains).
Grafana & InfluxDB sont des services plus ou moins complexes, donc pour les gens qui connaissent déja ces produits ce n'est pas un souci. Pour les autres c'est plus délicat d'autant que le projet peux se déployer sur plusieurs machines (une machine pour Grafana, une pour InfluDB, une pour le script + fping, voir avoir plusieurs instances du script+fping).
Comme toujours il faut mieux adapter son effort en fonction de la "cible". Celle-ci a 2 volets: l’environnent (OS et cpu) et le public qui va installer/utiliser le produit.
Si tu vises 'mr tout le monde' sous Windows ce n'est pas la meme chose que cibler 'les barbus' sous Linux. Pour ces derniers ton script Python suffit il se débrouillerons pour le reste.
Pour "mr tout le monde" c'est plus délicat. Déja je ne suis pas certain qu'un PC sous Windows soit une bonne cible pour un produit censé tourné 24/7 (sinon va y avoir des 'trous' dans les graphes).
Du coup cibler un PC Windows ne vaut peut-être pas l'effort que cela va demander. Ca va peut-être amuser quelques personnes a essayer cela sur leur PC mais peu l'utiliseront sérieusement comme cela. Donc beaucoup de temps & d'effort pour a l'arriver peu d'utilisation.
Donc c'est a toi de voir jusqu’où tu veux aller. Tu peux commencer par fournir un 'script' d'installation qui va installer & configurer tous les composants sur la machine par exemple (y compris InfluxDB & Grafana).
Une autre approche c'est d'utiliser Docker (du moins les containers en général , pas forcement "Docker" ca peut être podman ou lxc ou autre). L'avantage est qu'un utilisateur non expérimenté peut déployer cela très facilement, même sur Windows (Docker for Windows permet de faire tourner des containers Linux sous Windows).
L'inconvénient est que cela exclus certains OS comme les variantes de BSD (FreeBSD, etc).
Perso je commencerais par un script d'installation type "shell script" pour installer fping+le code python associé a un tuto rapide pour installer InfluxDB & Grafana.
Egalement j'utiliserai YAML que TOML. Ce dernier n'apporte rien de plus dans le cas présent pour un syntaxe plus lourde pour l'utilisateur.
Et peu de gens le connaissent. YAML est quand le 'standard' pour ce genre de chose.
ps: j'était en train d'écrire quand t'as posté ton message du coup pour la partie Windows on oublie.
-
+ 1 pour docker.
Tu peux même proposer un docker compose qui permettrait de tout déployer de façon très simplifié.
Par exemple: https://github.com/code4pi/HueTemperatureSensor/blob/master/docker-compose.yml
Bon c'est un truc que j'ai jamais réellement terminé, mais il suffit de modifier le fichier de conf et de faire un docker-compose up -d pour lancer Grafana, Influxdb ...
J'ai utilisé des images latest (ce n'est pas une bonne pratique), mais tu peux choisir des versions spécifiques, les mettre à jour très facilement. Tu limites aussi les effet de bords et les soucis, car tu peux supprimer tous tes déploiements avec une autre commande (et repartir de zéro si besoin).
-
Hello,
Aujourd'hui j'ai bien avancé et je pense pouvoir bientôt livrer un docker avec uniquement l'outil Infpyng. Les tests sont concluants 😊
-
Bonjour,
Juste pour vous informer que le docker est prêt, j'aimerais bien avoir vos retours pour ceux qui vont le tester, merci.
Bonne journée.
-
Bonjour,
Juste pour vous informer que le docker est prêt, j'aimerais bien avoir vos retours pour ceux qui vont le tester, merci.
Bonne journée.
l'output de log par défaut sur /var/log/infpyng.log n'est pas pratique pour les conteneurs. cela oblige a mapper ce ficher en dehors du conteneur ou de faire un "docker cp nomducontainer:/var/log/infpyng.log -' pour voir ce qui se passe.
Généralement on prefere stdout/stdin car la commande "docker logs .." permet d'afficher directement stdin/stdout.
En plus on peut spécifier un 'driver' (voir https://docs.docker.com/config/containers/logging/configure/ ). par exemple je lance mes containers avec cet option:
(c'est un exemple avec Caddy)
docker run -d \
--name caddy\
--restart unless-stopped\
--mount /www/Caddyfile:/etc/Caddyfile \
--mount /www/www:/www \
--mount /www/caddy-logs:/logs \
-p 80:80 -p 443:443 \
--log-driver=journald \
--log-opt tag="{{.Name}}" \
abiosoft/caddy -agree -conf /etc/Caddyfile
les options --log-driver=journald et -log-opt tag permettent de rediriger le 'docker logs' sur le journal systemd de l'hote (donc journalctl) ce qui est pratique et centralise les logs de plusieurs containers.
Pour ce faire ton app devrait donc utiliser stdout (ou stderr) par défaut plutôt qu'un fichier de log (ou regarde le Dockerfile de nginx, par exemple, https://github.com/nginxinc/docker-nginx/blob/master/stable/alpine/Dockerfile#L104 ligne 104 ils font un ln -s mais je ne trouve pas cela clean si on le choix)
nb: on parle de logs systeme (erreur de config par exemple) pas des traces applicatives (style log apache) qui peuvent générer beaucoup de lignes et sont mieux dans leur propre fichier de log. Dans ton cas, si le serveur Influxdb ne répond ca va dans /var/log/infpyng.log ce qui n'est pas bon dans un environnent Docker, ni meme en bare métal d'ailleurs cette erreur devrait aller le stderr de l'application.
Apres un bon container doit être "jetable" donc rien garder dedans. ni input (config, parametres) ni output (logs, etc) importants. On peut laisser une config par défaut si on veut mais si l'application nécessite que l'utilisateur spécifie toujours une config autant mettre ca en dehors du conteneur et générer une erreur si on ne précise pas la config. Le fichier hosts par exemple n'a pas lieu d'être dans le container.
Il faut voir un container comme un executable c'est plus simple a aborder comme ca.
Pour un usage propre, il faut donc 'monter' les 2 fichiers de config (ou le dossier 'config') et par défaut avoir les logs sur stdout/stderr et le traces applicatives dans un autre fichier.
Pour éviter des montages complexe, je conseillerais aussi de mettre des chemins courts dans le containers ou des volumes nommés. la les 2 fichiers de conf sont "/app/infpyng/config/config.toml" et "/app/infpyng/config/config.toml" ce qui est long pour rien.
utilise plutot /app/config.toml et /app/hosts.toml. bref met tout dans /app.
comme ca on peut lancer le conteneur ainsi:
docker run -d\
--name infpyng\
--restart unless-stopped\
--mount /chemin/hote/infpyng/config/config.toml:/app/config.toml\
--mount /chemin/hote/infpyng/config/hosts.toml:/app/hosts.toml\
--mount /chemin/hote/infpyng/infpyng.log:/var/log/infpyng.log \
--log-driver=journald \
--log-opt tag="{{.Name}}" \
oijkn/infpyng
en pratique /chemin/hote est un serveur nfs par exemple ou un chemin local backupé et protégé. (c'est l'endroit de persistence, tout le reste étant jetable et pouvant changer de machine).
Apres vu ton app n'est pas autonome et dépend d'InfluxDB, il serait peut-etre mieux de mettre la config InfluxDB non pas dans config.toml mais en paramètre ou variable d'environnement. ca permet de passer cela lors du "docker run ..." ou dans un compose file.
Je vais faire un compose file pour tester ton container car je n'utilise pas influxdb sur mes serveurs. je le posterais ici.
edit: quelques typos
-
j'ai fait la stack de test dans https://github.com/kgersen/infpyng-stack
c'est pour donc ceux qui n'ont pas influxdb & grafana et veulent tester Infpyng.
instruction:
-installer Docker
-installer docker-compose ( https://docs.docker.com/compose/install/ )
puis:
git clone https://github.com/oijkn/infpyng.git
cd infpyng
git clone https://github.com/kgersen/infpyng-stack.git
cd infpyng-stack
sh run.sh
ensuite accéder a grafana via http://localhost:3001 (ou l'ip si sur une machine distante)
le login/mdp par défaut est admin/foobar (définit dans le fichier grafana/config.monitoring)
J'ai préconfiguré la source dans Grafana mais pas le plugin et le dashboard, n'étant pas familier avec ce plugin je laisse le soin a oijkn de rajouter cela. Il suffit d'utiliser le dossier grafana/provisioning
-
Pour ce faire ton app devrait donc utiliser stdout (ou stderr) par défaut plutôt qu'un fichier de log (ou regarde le Dockerfile de nginx, par exemple, https://github.com/nginxinc/docker-nginx/blob/master/stable/alpine/Dockerfile#L104 ligne 104 ils font un ln -s mais je ne trouve pas cela clean si on le choix)
nb: on parle de logs systeme (erreur de config par exemple) pas des traces applicatives (style log apache) qui peuvent générer beaucoup de lignes et sont mieux dans leur propre fichier de log. Dans ton cas, si le serveur Influxdb ne répond ca va dans /var/log/infpyng.log ce qui n'est pas bon dans un environnent Docker, ni meme en bare métal d'ailleurs cette erreur devrait aller le stderr de l'application.
Suite à tes explications et conseils, j'ai donc également redirigé les erreurs vers la sortie STDERR. Ce qui permet effectivement de les voir passer dans le journal du systemd.
Pour un usage propre, il faut donc 'monter' les 2 fichiers de config (ou le dossier 'config') et par défaut avoir les logs sur stdout/stderr et le traces applicatives dans un autre fichier.
Pour éviter des montages complexe, je conseillerais aussi de mettre des chemins courts dans le containers ou des volumes nommés. la les 2 fichiers de conf sont "/app/infpyng/config/config.toml" et "/app/infpyng/config/config.toml" ce qui est long pour rien.
utilise plutot /app/config.toml et /app/hosts.toml. bref met tout dans /app.
Très bon conseil, merci ! J'ai donc adapté le build de l'image pour raccourcir les chemins et j'en ai profité pour ajouter tzdata pour la timezone (c'est galère de debug avec un décalage d'heure entre le container et le host)
docker run -d \
--name infpyng \
--hostname docker-infpyng \
--restart unless-stopped \
--mount src=/etc/infpyng/config,target=/infpyng/config,type=bind \
--mount src=/var/log/infpyng.log,target=/var/log/infpyng.log,type=bind \
--log-driver=journald \
--log-opt tag="{{.Name}}" \
--env TZ=Europe/Paris \
oijkn/infpyng
Apres vu ton app n'est pas autonome et dépend d'InfluxDB, il serait peut-etre mieux de mettre la config InfluxDB non pas dans config.toml mais en paramètre ou variable d'environnement. ca permet de passer cela lors du "docker run ..." ou dans un compose file.
Dans le but de garder une compatibilité entre le mode docker et standalone (git) je préfère tout mettre dans un fichier de config.
j'ai fait la stack de test dans https://github.com/kgersen/infpyng-stack
c'est pour donc ceux qui n'ont pas influxdb & grafana et veulent tester Infpyng.
instruction:
-installer Docker
-installer docker-compose ( https://docs.docker.com/compose/install/ )
puis:
git clone https://github.com/oijkn/infpyng.git
cd infpyng
git clone https://github.com/kgersen/infpyng-stack.git
cd infpyng-stack
sh run.sh
ensuite accéder a grafana via http://localhost:3001 (ou l'ip si sur une machine distante)
le login/mdp par défaut est admin/foobar (définit dans le fichier grafana/config.monitoring)
J'ai préconfiguré la source dans Grafana mais pas le plugin et le dashboard, n'étant pas familier avec ce plugin je laisse le soin a oijkn de rajouter cela. Il suffit d'utiliser le dossier grafana/provisioning
Super !! Merci pour ton aide et implication :) je regarde ça demain et je fini de le configurer.
Si tu as d'autres idées ou améliorations à proposer n'hésite surtout pas.
Bonne fin de soirée.
-
j'ai fait la stack de test dans https://github.com/kgersen/infpyng-stack
J'ai voulu tester ton stack et je rencontre des difficultés pour le faire fonctionner.
En premier lieux j'ai modifié le fichier "stack-compose.yml" car j'ai mis à jour mon docker suite à tes recommandations :
infpyng:
build:
context: .
dockerfile: ../Dockerfile
image: oijkn/infpyng:latest
container_name: infpyng_infpyng
depends_on:
- influxdb
volumes:
- ./data/infpyng/:/infpyng/config/
- ./data/infpyng.log:/infpyng/infpyng.log
restart: unless-stopped
Là ou je rencontre un problème c'est lors du build en exécutant la commande "sh run.sh", dans le processus de construction il ne parvient pas à copier le fichier "requirements.txt" qui se trouve un répertoire au dessus. J'ai tenté de le copier dans le dossier courant, c'est à dire au même niveau où se trouve le fichier "stack-compose.yml". De cette façon le build s'effectue correctement par contre dans le container de Infpyng, je ne retrouve plus l'app...
# docker logs d08edc58d4d4
python: can't open file 'infpyng.py': [Errno 2] No such file or directory
python: can't open file 'infpyng.py': [Errno 2] No such file or directory
python: can't open file 'infpyng.py': [Errno 2] No such file or directory
python: can't open file 'infpyng.py': [Errno 2] No such file or directory
python: can't open file 'infpyng.py': [Errno 2] No such file or directory
python: can't open file 'infpyng.py': [Errno 2] No such file or directory
python: can't open file 'infpyng.py': [Errno 2] No such file or directory
python: can't open file 'infpyng.py': [Errno 2] No such file or directory
# docker run --rm -it oijkn/infpyng sh
/infpyng # ls -sal
total 24
0 drwxr-xr-x 5 root root 158 May 29 08:43 .
0 drwxr-xr-x 1 root root 18 May 29 08:44 ..
0 drwxr-xr-x 8 root root 163 May 29 07:45 .git
4 -rw-r--r-- 1 root root 5 May 29 07:45 .gitignore
4 -rw-r--r-- 1 root root 433 May 29 07:45 README.md
0 drwxr-xr-x 5 root root 71 May 29 08:34 data
0 drwxr-xr-x 3 root root 51 May 29 07:45 grafana
4 -rw-r--r-- 1 root root 46 May 29 08:19 requirements.txt
4 -rw-r--r-- 1 root root 141 May 29 07:45 run.sh
4 -rw-r--r-- 1 root root 869 May 29 08:37 stack-compose.yml
4 -rw-r--r-- 1 root root 65 May 29 07:45 stop.sh
J'en est profité pour restructurer un peu le volume data en y mettant tout dedans ;)
Serais-tu m'aider stp ? Merci par avance :)
Edit : Juste après avoir posté mon message j'ai trouvé la solution (après 2h de recherche...)
infpyng:
build:
context: $PWD/..
dockerfile: $PWD/../Dockerfile
image: oijkn/infpyng:latest
container_name: infpyng_infpyng
depends_on:
- influxdb
volumes:
- ./data/infpyng/:/infpyng/config/
- ./data/infpyng.log:/infpyng/infpyng.log
restart: unless-stopped
-
en prod on ne met pas le build et le dockfile dans le compose file, on référence juste l'image qui est téléchargée depuis un registre (hub.docker.com par exemple).
la c'est un compose file de développement qui permet de (re)build a la demande l'image oijkn/infpyng car elle n'est pas dispo dans un registre public sur Internet.
il suffit d'enlever la section 'build:' pour simplifier la chose mais ca imposera de faire le "docker build ..." a la main avant ou que oijkn/infpyng soit dispo dans un registre.
Idéalement tu devrais créer un compte sur hub.docker.com pour mettre ton image ( oijkn/infpyng ) comme ca tout le monde peut la récupérer sans besoin de récupérer tes sources.
Tu peux même lier ton compte github a ton compte Docker et automatiser le docker build chez Docker: a chaque changement de ton Dockerfile sur github le "docker build ..." sera automatiquement fait par les serveurs de hub.docker.com (d'ou l'importance des tags de version aussi).
Tu peux aussi utiliser un registre perso (serveur perso par exemple) ou un registre public autre que celui de Docker (github, gitlab, quay.io, Google (gcp), Amazon (aws), Nexus, etc) dans cas il faut préciser l'url en plus du nom de l'image.
L'important est de comprendre que faire un 'docker run grafana/grafana' ca va revient à faire un "docker run docker.io/library/grafana" si l'image n'est pas dispo localement.
Donc si tu veux que les autres profitent de ton image il faut la publier dans un registre sinon ils doivent la build localement avant.
-
Hello,
Oui je suis tout à fait d'accord avec toi et je ne comprend pas trop ce qui se passe car j'ai déjà un compte sur hub.docker :
Docker Infpyng (https://hub.docker.com/r/oijkn/infpyng)
Donc n'importe qui peut le pull :)
Actuellement je suis en train de batailler avec Grafana qui n'arrive pas à se connecté à InfluxDB...
Voilà la conf du docker-compose:
version: '3.8'
services:
influxdb:
image: influxdb:latest
container_name: infpyng_influxdb
ports:
- '8086:8086'
volumes:
- ./data/influxdb:/var/lib/influxdb
env_file:
- .env
chronograf:
image: chronograf:latest
container_name: infpyng_chronograf
ports:
- '127.0.0.1:8888:8888'
volumes:
- ./data/chronograf:/var/lib/chronograf
depends_on:
- influxdb
environment:
- INFLUXDB_URL=http://influxdb:8086
grafana:
image: grafana/grafana:6.7.3
container_name: infpyng_grafana
ports:
- '3000:3000'
volumes:
- ./data/grafana:/var/lib/grafana
- ./grafana-provisioning/:/etc/grafana/provisioning
depends_on:
- influxdb
env_file:
- .env
infpyng:
build:
context: ${PWD}/..
dockerfile: ${PWD}/../Dockerfile
image: oijkn/infpyng:latest
container_name: infpyng_infpyng
depends_on:
- influxdb
volumes:
- ../config/:/infpyng/config/
- ./data/infpyng.log:/infpyng/infpyng.log
network_mode: host
restart: unless-stopped
Lorsque je clique sur le bouton "Save & test" dans le menu "Data sources" de Grafana, un message d'erreur pop : "Network Error: Bad Gateway(502)"
Pourtant tout semble bien fonctionner et configurer car depuis mon PC (Windows) j'arrive à atteindre InfluxDB :
C:\Users\Oijkn>curl -i -XPOST http://127.0.0.1:8086/query --data-urlencode "q=SHOW DATABASES"
HTTP/1.1 200 OK
Content-Type: application/json
Request-Id: 0eb80091-a1b2-11ea-806b-0242c0a83002
X-Influxdb-Build: OSS
X-Influxdb-Version: 1.8.0
X-Request-Id: 0eb80091-a1b2-11ea-806b-0242c0a83002
Date: Fri, 29 May 2020 13:41:11 GMT
Transfer-Encoding: chunked
{"results":[{"statement_id":0,"series":[{"name":"databases","columns":["name"],"values":[["infpyng"],["_internal"]]}]}]}
-
ok pour docker hub, je n'avais pas vu que tu avais déjà mis ton image dessus.
Dans un même compose file , les services sont joignables entre eux par leur noms via un dns local.
Il y a un résolution dns automatique 'nom du service' -> adresse IP interne du conteneur.
du coup depuis le conteneur infpyng_grafana le containeur infpyng_influxdb est accessible via le nom 'influxdb' (car c'est le nom du service = la ligne 'influxdb:')
pour voir les IP des containers d'une stack (ici le réseau de la stack s’appelle infpyng_default) :
docker network inspect -f '{{range .Containers}}{{.Name}} = {{.IPv4Address}}{{println}}{{end}}' infpyng_default
("docker network ls" affiche les réseaux configurés)
Tu peux vérifier la réso dns entre containers fonctionne avec:
docker exec -it infpyng_grafana ping influxdb(tu aura une erreur de ping a cause des droits mais la réso dns devrait marcher, cela doit afficher l'ip du container infpyng_influxdb)
si l'ip ne s'affiche pas y'a un problème.
si elle s'affiche alors la source ' http://influxdb:8086 ' devrait fonctionner dans le container grafana. Tu peux tester en l'ajoutant a la main. Mais elle pré-configurée dans le fichier 'grafana/provisioning/datasources/influxdb.yaml' (il faut donc que l'url dans ce fichier soit toujours cohérente avec le nom du service influxdb dans le ficher compose).
tu peux aussi testé en mettant directement l'ip telle qu'affichée avec (docker network inspect ...) mais juste pour tester si le réseau fonctionne entre containers.
-
Bonjour à tous,
kgersen merci pour tes indications, d'après ce que j'ai pu lire sur internet effectivement je devrais pouvoir connecter Grafana avec InfluxDB via le nom DNS du container... la seule solution à mon problème a était d'utiliser le "network_mode: host" (peut être un soucis sur ma VM CentOS).
Bon quoiqu'il en soit grâce à ton aide et exemple, j'ai pu créer un docker-compose avec le stack Infpyng + Grafana + InfluxDB + Chronograf.
Tout ceci est dispo sur le Github (https://github.com/oijkn/infpyng/tree/master/infpyng-stack).
Merci pour vos retours et enjoy it :)
-
"network_mode: host " ca viole un peu le principe des containers, ca les expose directement sur le réseau local pour rien.
-
"network_mode: host " ca viole un peu le principe des containers, ca les expose directement sur le réseau local pour rien.
Oui je sais bien mais sur ma VM ça ne fonctionne pas normalement.
Tu peux essayer de ton côté sans le mode "host" et voir si Grafana communique avec InfluxDB via son nom DNS, stp ? Merci
-
Oui je sais bien mais sur ma VM ça ne fonctionne pas normalement.
Tu peux essayer de ton côté sans le mode "host" et voir si Grafana communique avec InfluxDB via son nom DNS, stp ? Merci
oui ca marche si on corrige les références (influxdb au lieu de 127.0.0.1) et:
- il manque le .env pour définir le base influxdb (pourquoi un .env ?!)
- la datasource dans provisionning n'est pas correctement configuré dans échoue dans grafana quand on 'save & test' . il faut mettre 'proxy' comme access et pas 'access'
apiVersion: 1
datasources:
- name: InfluxDB
type: influxdb
access: proxy
database: infpyng
url: http://influxdb:8086
isDefault: true
editable: true
jsonData:
httpMode: GET
timeInterval: 5m
pour finir 3 détails:
- enleve le dossier 'data' du git (via gitignore) ou idéalement positionne le en dehors de l'arborescence du git
- clear-all.sh est super dangereux et ne devrait pas être dans le git publié sur Internet. Des gens risquent de supprimer leur containers par mégarde. c'est l’équivalent de faire un script qui 'rm -rf /' ... tu peux faire un clean propre avec docker-compose que pour les containers concernant ta stack. il ne faut pas toucher aux autres containers qu'il pourrait y avoir. cf la doc de docker-compose
- par habitude on expose pas les ports dehors si on en a pas l'usage. Influxdb par exemple n'a pas besoin d'être exposé dehors (sauf en phase de test éventuellement).
-
dernier point, tu peux ajouter un "hostname" a ton container pour éviter dans influxdb/grafana de voir un nom aléatoire et différent a chaque fois que le container infpyng_infpyng est recrée.
pour voir le nom actuel
docker exec infpyng_infpyng hostname
Ligne a rajouter dans le compose, section infpyng:
infpyng:
image: oijkn/infpyng:latest
container_name: infpyng_infpyng
hostname: infpyng
depends_on:
Apres si y'a le hostname dans la base influxdb c'est peut-être ton code qui fait cela (je n'ai pas été voir).
En mode bare metal c'est peut-etre ok mais pas forcement non plus (si on déplace la sonde par exemple).
Du coup ajoute peut-etre un paramètre "hostname" (dans la config.toml par exemple) et utilise hostname que si le paramètre n'est pas présent.
-
J'ai beau essayer dans tous les sens grafana ne trouve pas influxdb... Après ma VM à une configuration un peu spéciale car elle par la pfs de mon taf et donc naté. Elation je remonte une VM propre pour refaire les tests et j'appliquerai tes recommandations 😊 merci
-
Tu peux vérifier la réso dns entre containers fonctionne avec:
docker exec -it infpyng_grafana ping influxdb(tu aura une erreur de ping a cause des droits mais la réso dns devrait marcher, cela doit afficher l'ip du container infpyng_influxdb)
Franchement je ne comprends pas ce qu'il se passe sur ma VM toute fraîche, tout fonctionne bien sauf la joignabilité entre Grafana et InfluxDB.
D'après les tests que j'ai pu effectuer, il semblerait que les containers se voient bien pourtant :
[root@PC-213 infpyng-stack]# docker exec -it $(docker ps -a | grep grafana | awk '{print $1}') nslookup influxdb
nslookup: can't resolve '(null)': Name does not resolve
Name: influxdb
Address 1: 172.28.0.2 infpyng_influxdb.infpyng_default
[root@PC-213 infpyng-stack]# docker exec -it $(docker ps -a | grep grafana | awk '{print $1}') ping influxdb
PING influxdb (172.28.0.2): 56 data bytes
ping: permission denied (are you root?)
Config du network Infpyng_default :
[
{
"Name": "infpyng_default",
"Id": "e0d764c05e6c35847dae3a0ed9727e2ad997f8ff0b403ff522a3b95bbe254fda",
"Created": "2020-06-01T16:42:50.836242415+02:00",
"Scope": "local",
"Driver": "bridge",
"EnableIPv6": false,
"IPAM": {
"Driver": "default",
"Options": null,
"Config": [
{
"Subnet": "172.28.0.0/16",
"Gateway": "172.28.0.1"
}
]
},
"Internal": false,
"Attachable": true,
"Ingress": false,
"ConfigFrom": {
"Network": ""
},
"ConfigOnly": false,
"Containers": {
"332d5106915fb45c8c2b1064c69fec286e24402143d9ccd4894be9c865dce2e8": {
"Name": "infpyng_grafana",
"EndpointID": "6487bc78307d127275df29b3308a745d00284d39309dc6a771f3ddd3a91fc9fe",
"MacAddress": "02:42:ac:1c:00:04",
"IPv4Address": "172.28.0.4/16",
"IPv6Address": ""
},
"735e5d759e844aad945f5b714ac1c594baa882fe0a27b71d3f0380a198803899": {
"Name": "infpyng_influxdb",
"EndpointID": "5b49dd507fcb1f67daba7beab4ff986e90512da29384b46e09238e9bde95b375",
"MacAddress": "02:42:ac:1c:00:02",
"IPv4Address": "172.28.0.2/16",
"IPv6Address": ""
},
"8e1689dd3df1efc55bfd605a589b3e7eeedaa060e39a06351c5ea765fb3a2ef1": {
"Name": "infpyng_chronograf",
"EndpointID": "bbbef889424498ea96f467feb31dec13c0805c554092628a6587e795cb119ca5",
"MacAddress": "02:42:ac:1c:00:03",
"IPv4Address": "172.28.0.3/16",
"IPv6Address": ""
}
},
"Options": {},
"Labels": {
"com.docker.compose.network": "default",
"com.docker.compose.project": "infpyng",
"com.docker.compose.version": "1.25.5"
}
}
]
J'ai beau essayer toutes les méthodes possible, je ne parviens pas à atteindre influx via l'url : http://influxdb:8086 (que j'expose ou pas le port en local)
- il manque le .env pour définir le base influxdb (pourquoi un .env ?!)
oui désolé, un erreur de ma part -> j'ai remis le fichier "config.monitoring"
- la datasource dans provisionning n'est pas correctement configuré dans échoue dans grafana quand on 'save & test' . il faut mettre 'proxy' comme access et pas 'access'
apiVersion: 1
datasources:
- name: InfluxDB
type: influxdb
access: proxy
database: infpyng
url: http://influxdb:8086
isDefault: true
editable: true
jsonData:
httpMode: GET
timeInterval: 5m
encore un oubli de ma part suite à tous les tests... c'est corrigé :)
pour finir 3 détails:
- enleve le dossier 'data' du git (via gitignore) ou idéalement positionne le en dehors de l'arborescence du git
- clear-all.sh est super dangereux et ne devrait pas être dans le git publié sur Internet. Des gens risquent de supprimer leur containers par mégarde. c'est l’équivalent de faire un script qui 'rm -rf /' ... tu peux faire un clean propre avec docker-compose que pour les containers concernant ta stack. il ne faut pas toucher aux autres containers qu'il pourrait y avoir. cf la doc de docker-compose
- par habitude on expose pas les ports dehors si on en a pas l'usage. Influxdb par exemple n'a pas besoin d'être exposé dehors (sauf en phase de test éventuellement).
Le répertoire data n'est pas poussé dans le git donc aucune inquiétude à ce sujet, le script clear a été adapté pour uniquement supprimer les images/containers créés par Infpyng.
Autre chose que je remarque, depuis le container Grafana je ne peux pas installer de plugin, comme si internet n'était pas présent alors que le fichier /etc/resolv.conf est bien configuré sur le host. Avec l'option dns dans le fichier docker-compose ça ne fonctionne pas mieux.
Donc temporairement (le temps de trouver la solution) le plugin est embarqué dans le répertoire de provisioning.
[root@PC-213 infpyng-stack]# docker logs 8af5c60a2a1e
installing multibar-graph-panel @
from: https://github.com/CorpGlory/grafana-multibar-graph-panel/archive/0.2.5.zip
into: /var/lib/grafana/plugins
Error: ✗ failed to download plugin archive: Failed to send request: Get https://github.com/CorpGlory/grafana-multibar-graph-panel/archive/0.2.5.zip: dial tcp: lookup github.com on 127.0.0.11:53: read udp 127.0.0.1:53587->127.0.0.11:53: i/o timeout
-
si ping ou nslookup affiche bien l'ip c'est que le probleme est plus haut.
tout fonctionne bien sauf la joignabilité entre Grafana et InfluxDB.
comme tu test / détecte cela ?
essai avec wget ( le container grafana n'inclut pas curl mais il inclut wget qui permet a peu pres la meme chose)
docker exec -it infpyng_grafana wget -q -O - --post-data "q=SHOW DATABASES" http://influxdb:8086/querycela fonctionne chez moi.
cela fonctionne aussi:
docker exec -it infpyng_grafana wget -O /dev/null https://github.com/CorpGlory/grafana-multibar-graph-panel/archive/0.2.5.zip
Connecting to github.com (140.82.118.3:443)
Connecting to codeload.github.com (140.82.113.9:443)
null 100% |*****************************************************************************************************| 293k 0:00:00 ETA
j'ai bien la meme config de Infpyng_default que toi.
depuis le container Grafana je ne peux pas installer de plugin
tu utilises quel manip pour cela ?
ps: je vois que tu utilises les id des containers pour faire tes manips, c'est plus simple d'utiliser les noms des containers d'autant que tu peux installer la complétion shell ( https://docs.docker.com/compose/completion/ pour docker-compose et pour docker tout court ca devrait être auto suivant ta distrib Linux).
ps: docker ps -a affiche aussi les containers arrêtés, t'as pas des doublons ou autre ?
-
comme tu test / détecte cela ?
Depuis l'interface de Grafana, dans le menu Configuration->Data Sources->InfluxDB et bouton "Save & Test" (voir capture)
essai avec wget ( le container grafana n'inclut pas curl mais il inclut wget qui permet a peu pres la meme chose)
[root@PC-213 infpyng-stack]# docker exec -it infpyng_grafana wget -q -O - --post-data "q=SHOW DATABASES" http://influxdb:8086/query
wget: can't connect to remote host (172.31.0.2): Host is unreachable
[root@PC-213 infpyng-stack]# docker exec -it infpyng_grafana wget -O /dev/null https://github.com/CorpGlory/grafana-multibar-graph-panel/archive/0.2.5.zip
wget: bad address 'github.com'
Chez moi ça ne fonctionne pas...
ps: je vois que tu utilises les id des containers pour faire tes manips, c'est plus simple d'utiliser les noms des containers
ps: docker ps -a affiche aussi les containers arrêtés, t'as pas des doublons ou autre ?
merci pour cet indications, je viens de mettre à jour le script clear avec les noms des images. Et non aucun doublon car j'essaie de bosser sur des images/container "propre" :)
Je ne sais pas pourquoi ça fonctionne bien chez toi et pas ici...
Ci-dessous la conf du host (ma VM est en mode bridge avec VMware Workstation) :
[root@PC-213 infpyng-stack]# cat /etc/resolv.conf
nameserver 8.8.8.8
-
wget: can't connect to remote host (172.31.0.2): Host is unreachable
curieux.
c'est que depuis grafana ? influxdb fonctionne correctement ? chronograf est accessible ?
c'est quoi comme distrib linux dans ta vm ? comment docker est installé ? quelle version de docker ('docker version' ou 'docker system info')?
qu'affiche "docker ps" quand les 4 containers tournent ?
-
wget: can't connect to remote host (172.31.0.2): Host is unreachable
curieux.
c'est que depuis grafana ? influxdb fonctionne correctement ? chronograf est accessible ?
c'est quoi comme distrib linux dans ta vm ? comment docker est installé ? quelle version de docker ('docker version' ou 'docker system info')?
qu'affiche "docker ps" quand les 4 containers tournent ?
Oui c'est très curieux et énervant car je bataille depuis plusieurs jours et je ne trouve pas d'où cela provient :\
Influx fonctionne correctement car Infpyng arrive à le joindre et écrire dans la BDD (par contre Infpyng est en "network_mode:host")
Et les traces du docker logs indiquent bien que le script Python communique bien avec InfluxDB.
Quand à Chronograf il est accessible lorsque je le bascule sur le réseau 0.0.0.0 par contre il ne parvient pas à joindre l'url http://influxdb:8086 comme pour Grafana...
L'OS actuel est CentOS 8 et docker a été installé via ce tuto (https://www.linuxtechi.com/install-docker-ce-centos-8-rhel-8/):
[root@PC-213 infpyng-stack]# uname -a
Linux PC-213.home 4.18.0-147.el8.x86_64 #1 SMP Wed Dec 4 21:51:45 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
[root@PC-213 infpyng-stack]# docker version
Client: Docker Engine - Community
Version: 19.03.10
API version: 1.39
Go version: go1.13.10
Git commit: 9424aeaee9
Built: Thu May 28 22:18:06 2020
OS/Arch: linux/amd64
Experimental: false
Server: Docker Engine - Community
Engine:
Version: 18.09.1
API version: 1.39 (minimum version 1.12)
Go version: go1.10.6
Git commit: 4c52b90
Built: Wed Jan 9 19:06:30 2019
OS/Arch: linux/amd64
Experimental: false
[root@PC-213 infpyng-stack]# docker system info
Client:
Debug Mode: false
Server:
Containers: 4
Running: 4
Paused: 0
Stopped: 0
Images: 4
Server Version: 18.09.1
Storage Driver: overlay2
Backing Filesystem: xfs
Supports d_type: true
Native Overlay Diff: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
Volume: local
Network: bridge host macvlan null overlay
Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: c4446665cb9c30056f4998ed953e6d4ff22c7c39
runc version: 4fc53a81fb7c994640722ac585fa9ca548971871
init version: fec3683
Security Options:
seccomp
Profile: default
Kernel Version: 4.18.0-147.el8.x86_64
Operating System: CentOS Linux 8 (Core)
OSType: linux
Architecture: x86_64
CPUs: 1
Total Memory: 1.764GiB
Name: PC-213.home
ID: ELOS:FHCS:FDPX:UKAV:ZDC3:25V7:BBNC:ONWA:QEUU:UIWF:FAJ7:3GF7
Docker Root Dir: /var/lib/docker
Debug Mode: false
Registry: https://index.docker.io/v1/
Labels:
Experimental: false
Insecure Registries:
127.0.0.0/8
Live Restore Enabled: false
Product License: Community Engine
[root@PC-213 infpyng-stack]# docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
b9385fd178ea chronograf:latest "/entrypoint.sh chro…" 16 minutes ago Up 15 minutes 127.0.0.1:8888->8888/tcp infpyng_chronograf
54908593294a grafana/grafana:6.7.3 "/run.sh" 16 minutes ago Up 16 minutes 0.0.0.0:3000->3000/tcp infpyng_grafana
c4a420c9b7b6 oijkn/infpyng:latest "python infpyng.py" 16 minutes ago Up 15 minutes infpyng_infpyng
e9e1334e2d04 influxdb:latest "/entrypoint.sh infl…" 16 minutes ago Up 16 minutes 0.0.0.0:8086->8086/tcp infpyng_influxdb
Edit :
Tu m'as mit la puce à l'oreille ! Je viens de configurer le firewalld pour Docker et maintenant ça passe :)
[root@PC-213 infpyng-stack]# firewall-cmd --zone=public --add-masquerade --permanent
success
[root@PC-213 infpyng-stack]# firewall-cmd --reload
success
[root@PC-213 infpyng-stack]# docker exec -it infpyng_grafana wget -q -O - --post-data "q=SHOW DATABASES" http://influxdb:8086/query
{"results":[{"statement_id":0,"series":[{"name":"databases","columns":["name"],"values":[["infpyng"],["_internal"]]}]}]}
-
ah good. j'utilise rarement un firewall local.
-
ah good. j'utilise rarement un firewall local.
Moi non plus mais sur ma VM de dev je laisse celui d'origine, en tout cas merci beaucoup pour ton aide :)
Je vais pouvoir me concentrer sur le reste maintenant, si tu as d'autres suggestions bah je suis à l'écoute ^^
-
Salut, ca a l'air vraiment top, je vais voir pour tester ton outil ^^
-
ah good. j'utilise rarement un firewall local.
Avec Ubuntu, pas de Firewall local activé par défaut. Mais avec CentOS, oui, qui bloque tout, et à chaque fois c'est vrai que c'est un peu pénible d'avoir à le configurer pour ouvrir tous les ports de chaque application que l'on installe.
En tout cas, projet intéressant pour remplacer smokeping !
-
si tu as d'autres suggestions bah je suis à l'écoute ^^
- pouvoir ping tout les hosts d'une meme cible (fqdn ou dn)
- pouvoir choisir de ping en ipv4 ou ipv6 ou les deux pour une meme cible (fqdn ou dn).
par exemple, si le fqdn est 'google.dns' ou "one.one.one.one":
$ host dns.google
dns.google has address 8.8.4.4
dns.google has address 8.8.8.8
dns.google has IPv6 address 2001:4860:4860::8844
dns.google has IPv6 address 2001:4860:4860::8888
$ host one.one.one.one
one.one.one.one has address 1.0.0.1
one.one.one.one has address 1.1.1.1
one.one.one.one has IPv6 address 2606:4700:4700::1111
one.one.one.one has IPv6 address 2606:4700:4700::1001
Dans ces 2 exemples, le meme fqdn correspond donc a 4 cibles distinctes (2 en IPv4 et 2 en IPv6).
Dans la conf 'hosts.toml', pouvoir indiquer si on veut les ping tous ou un seul (= le premier retourné par une résolution dns de l'OS fait avant chaque ping) ou/et que IPv4 ou que IPv6 (suivant la dispo du systeme local) (il y a donc 4 possibilités: tous (IPv6 et IPv4, un seul, tous que IPv4, un seul que IPv6)).
et rajouté des tags automatiques en conséquence (du style protocol = "ipv4" ou "ipv6" et éventuellement un tag pour indiqué si c'est le premier d'une réso dns ou exhaustif).
ps: IPv6 et Docker ce n'est pas forcement simple. donc déja sans Docker ;)
-
et à chaque fois c'est vrai que c'est un peu pénible d'avoir à le configurer pour ouvrir tous les ports de chaque application que l'on installe.
si on utilise Docker on peut peut-etre whitelister son interface, un truc du genre:
firewall-cmd --permanent --zone=trusted --change-interface=docker0
c'est peut-etre mieux que le 'add-masquerade' qu'il a fait car cela evite du NAT (enfin il faudrait tester avec des iperf3 entre containers par exemple et entre un container et l'hote pour voir l'impact performance/cpu).
Enfin j'en sais rien je n'utilise jamais firewalld. Et en général de firewall avec sur l’hôte avec Docker car celui-ci manipule aussi iptables...
-
@kgersen j'ai bien pris note de tes remarques, merci. Actuellement j'occupe un nouveau poste dans ma vie professionnelle donc le dev sera un peu moins actif 😉