Aller au contenu

bruno78

Membres
  • Compteur de contenus

    706
  • Inscription

  • Dernière visite

  • Jours gagnés

    14

Tout ce qui a été posté par bruno78

  1. Je ne comprends pas pourquoi il veut être en swarm mode absolument ????!!!. Je fais le test sur mon Pi3 aujourd'hui.
  2. @Einsteinium, je viens de faire une serie de tests sur DSM7 avec cette dernière version acme.sh:latest. création du certificat : OK puis après export x509 : importation manuelle dans DSM : OK (puis suppression manuelle) déploiement automatique (--deploy-hook synology_dsm) avec création d'un nouveau certificat (SAVED_SYNO_Create=1) : OK, mais le certificat créé et déployé est positionné comme étant celui "par defaut" ! affectation de services WEB sur ce certificat: OK 2nd déploiement automatique, toujours avec SAVED_SYNO_Create=1, mais le certificat étant donc déjà existant : OK, mais le certificat déployé est de nouveau positionné comme étant celui "par defaut" ! Affectation des services WEB pré-existants OK. Voilà, donc fonctionnellement, à par cette histoire de positionnement par default, je n'ai pas vu de problème. Effectivement, dans mon cas où j'ai plusieurs certificats, il faudra peut-être que je fasse attention à l'ordonnancement des différents dockers et tâches de déploiements. Par contre, au niveau des taches planifiées (point 2C), est-ce vraiment nécessaire de le faire quotidiennement ? Même si cette tache est disons hebdomadaire, le cron interne du docker va quotidiennement lancer la tache de renouvellement du certificat, jusqu'à arriver aux 2 mois à partir desquels le renouvellement se fera . Je ne sais pas. Maintenant, je vais voir à mettre en musique les 2 autres dockers acme.sh, et observer quelques jours. Bruno78
  3. @Jeff777 heu ..... je suis perdu. Comment adresses-tu (dans le fichoer telegraf.conf) influxdb (sur ton NAS, c'est ca ?) depuis le RPi ? @Lestat69, nos messages se sont croisés avec MilesTEG1. Donc c'est ok ca fonctionne. A priori en fait les solutions sont les mêmes. Le "monitoring" que tu as entre "networks" et "external" est un alias, ce n'est pas la même chose que le name: monitoring. Donc tu as mis comme alias "monitoring", là où moi j'ai comme alias "default". Au final c'est bon !
  4. OK @MilesTEG1, donc pas besoin de "default" si chez toi c'est OK. @Lestat69, peux-tu alors faire en ssh pour avoir le nom exact du réseau : docker network ls puis sur le réseau monitoring : docker network inspect <nom_du_reseau> Merci à @MilesTEG1
  5. @Lestat69, je n'ai pas essayé, mais dans les exemples trouvés, il est précisé en plus "default", càd Dans le service : networks: default: - monitoring Et la déclaration : networks: default: external: name: monitoring Je n'ai pas d'exemple perso sous la main.
  6. @Jeff777 donc j'en déduis que tes credentials influx sont bons, ... mais comme la liste des measurements est vide, ça veut dire que telegraf n'arrive pas, pour une raison nous encore élucidée, à envoyer et écrire vers influxdb. Laisse moi le temps de remonter le fil pour voir les configs ....
  7. OK. J'ai paramétré 3 dockers, un pour chaque domaine que je gère, les certificats ont bien été générés. (3 domaines, 3 dockers indépendants, 3 répertoires distincts) Il me reste la phase de déploiement des certificats à faire, .... je vais y aller prudemment, la dernière fois j'avais fait un erreur mais ça m'a planté 48h ! donc là je vais y aller petit à petit .... J'ai vu dans la doc github du deploy hook qu'il y a la possibilité de positionner SYNO_Create=1 pour créer le (nouveau) certificat si il n'existe pas encore dans DSM au moment du déployement. Est-ce pertinent à positionner/utiliser ?
  8. Petite question subsidiaire : j'ai peut-être mal cherché, mais je n'ai pas trouvé la description du delta entre la version dev et cette dernière latest ?
  9. Merci pour l'info @Einsteinium. Je vais mettre en place dans la journée.
  10. @Jeff777 reviens nous avec un œil de lynx . Bon rétablissement. Bruno78
  11. Une fois qu'on sera certain que les données de telegraf sont bien receptionnées par influxdb, on aura fait un grand pas en avant
  12. @Jeff777, a priori la ligne de log que tu montres correspond à l'interrogation depuis grafana (c'est un "query"). Essaie de te connecter sur influxdb avec le user/pwd que tu as défini (pour vérifier les droits), puis si OK alors avec un "show databases" tu dois voir la database que tu as configurée pour recevoir les données du RPi. Si ok, alors bascule sur cette database ("use raspi_telegraf" [d'après ton log]) et regarde si tu as des données ("show measurements"). Voilà rapidement ce que cela doit donner : avec influxdb en docker sur une VPS d'OVH, collectant les données de mon RPi sur le réseau mon local (telegraf installé sur le RPi3 en tant que service à part entière, et non pas en docker, mais ca ne doit pas changer grand chose). root@vps-xxxx:/home/xxxx# root@vps-xxxx:/home/xxxx# docker exec -it influxdb /bin/bash root@influxdb:/# influx -username pi_telegraf -password 'xxxxxx' Connected to http://localhost:8086 version 1.8.3 InfluxDB shell version: 1.8.3 > show databases name: databases name ---- pi_telegraf > use pi_telegraf Using database pi_telegraf > show measurements name: measurements name ---- cpu disk diskio kernel mem net processes rpi3B_temp swap system > exit root@influxdb:/# exit exit root@vps-xxxx:/home/xxxx#
  13. @MilesTEG1 oui c'est fastidieux, mais bon au bout de quelques jours, la liste se stabilise rapidement. Là j'en ai 7 "en stock" et ça semble stable. Donc ça se gère.
  14. @oracle7 je fais simplement des mapping id <=> value dans grafana
  15. @.Shad. en capture speedtest je peux te proposer celui-ci ? (le dernier, synchro Fbox, ne vient pas de speedtest bien sur).
  16. @oracle7, j'ai inclus le fichier xml contenant la liste des serveurs de tests juste pour info. Je n'ai pas eu le temps de voir si on pouvait l’intégrer "automatiquement" dans le code du dashboard. Je mets à jour à la main dans grafana le mapping serveur_id => sponsor lorsqu'un nouveau serveur est utilisé. En quelques jours, mon speedtest a utilisé 7 serveurs différents. Le contenu est sous la forme suivante : <server url="http://lafibre.info/pingtest/speedtest/upload.php" lat="45.7597" lon="4.8422" name="Lyon" country="France" countrycode="FR" sponsor="LaFibre.info" sponsorurl="http://lafibre.info/" id="2023" gid="0" url2="http://lafibre.info/pingtest/speedtest/upload.php" bigsamples="1" /> Le docker speedtest de son côté remonte les champs suivants : [{ 'measurement': 'speed_test_results', 'fields': { 'download': 829307849.259161, 'upload': 474337693.37657595, 'ping': 6.907, 'server': '24215', 'server_name': 'Paris' }, 'tags': { 'server': '24215', 'server_name': 'Paris', 'server_country': 'France' } }] Remarque : sur le net, on trouve plusieurs fichiers censés lister ces serveurs, .... aucun n'est exhaustif .... il faudra donc faire son marché si on souhaite récupérer des champs supplémentaires. Au lieu du "sponsor", on peut aussi vouloir récupérer l'url du serveur ...
  17. @.Shad. oui mais là je ne suis absolument pas à l'aise ... mais tu as raison sur le fonds
  18. @oracle7, Aie ... j'en déduis que tu ne l'avais pas fait avant ? Sinon la procédure (de mémoire) : influxdb -username 'admin' -password 'admin' create database speedtest use speedtest create user speedtest with password 'speedtest' grant all on speedtest to speedtest
  19. Attention, on ne modifie pas les paramètres de Wordpress à la légère, et en particulier aller directement dans la base MySQL n'est pas une bonne idée a priori car le risque de créer des incohérences est grand. Par exemple, lorsque l'on veut changer de domaine, on passe par des plugin d'export / import / migration. Ce n'est peut-être pas là ton problème, mais prudence ! je n'ai pas vu si tu avais indiqué être ou ne pas être derrière une LiveBox 4 ... ?
  20. @oracle7, oui la mise à jour watchtower ne fonctionnera pas ici. Mais comme j'ai dit à Jeff777, ce n'est pas comme si elle était mise à jour toutes les semaines. Et effectivement, si mise à jour de l'image de base, alors il faut juste refaire le docker build .... => mais cela suppose que les modifications faites dans l'image de base ne ruinent pas ma modif .... Je dirai donc qu'en cas de modification de l'image de base, il ne faudra pas trop se précipiter ....
  21. Mode d'emploi pour utiliser speedtest sans usr/pwd admin d'influxdb Prérequis : une database dédiée configurée sous influxdb, avec son user/pwd dédié. Télécharger le fichier speedtest2.tar (à la fin du message). Il contient : Dockerfile : fichier de commande pour générer la nouvelle image InfluxdbSpeedtest.py : fichier de lancement du test, très légèrement modifié (on fait un simple 'ping' de la base influxdb) SpeedTest_Net_Server_List.xml : en prime la liste des serveurs utilisés, avec leurs identifiants. Pour amélioration du dashboard grafana (source github) Etat avant modification : image root@ds918blam:/volume1/docker/speedtest# docker image ls REPOSITORY TAG IMAGE ID CREATED SIZE ... atribe/speedtest-for-influxdb-and-grafana latest 99c2c10d1e41 16 months ago 111MB ... container root@ds918blam:/volume1/docker/speedtest# docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES ... bc4340b44afd atribe/speedtest-for-influxdb-and-grafana:latest "python -u /src/infl…" 3 days ago Up 43 hours speedtest ... On arrete le container speedtest en cours root@ds918blam:/volume1/docker/speedtest# docker stop speedtest speedtest On construit la nouvelle image /!\ ne pas oublier le "." (point) à la fin de la commande /!\ root@ds918blam:/volume1/docker/speedtest# docker build -f Dockerfile --rm --tag speedtest2 . Sending build context to Docker daemon 959kB Step 1/2 : FROM atribe/speedtest-for-influxdb-and-grafana:latest ---> 99c2c10d1e41 Step 2/2 : COPY ./InfluxdbSpeedtest.py /src/influxspeedtest/ ---> 08847e4b7b5e Successfully built 08847e4b7b5e Successfully tagged speedtest2:latest on vérifie que l'image speedtest2 a bien été créée (on a toujours l'ancienne) root@ds918blam:/volume1/docker/speedtest# docker image ls REPOSITORY TAG IMAGE ID CREATED SIZE speedtest2 latest 08847e4b7b5e 15 seconds ago 111MB ... atribe/speedtest-for-influxdb-and-grafana latest 99c2c10d1e41 16 months ago 111MB ... on met à jour le docker-compose.yaml pour prendre en compte cette nouvelle image root@ds918blam:/volume1/docker/speedtest# cat docker-compose.yaml version: "2.1" services: speedtest2: image: speedtest2:latest container_name: speedtest2 volumes: - ./config.ini:/src/config.ini restart: unless-stopped mem_limit: 256M network_mode: bridge on met à jour le fichier config.ini pour modifier le user/pwd à utiliser root@ds918blam:/volume1/docker/speedtest# cat config.ini [GENERAL] # Duree en secondes entre deux mesures # Delay = 3600 Delay = 10800 [INFLUXDB] Address = xxx.xxx.xxx.xxx Port = 8086 Database = nas_speedtest #Username = admin #Password = admin Username = speedtestuser Password = speedtestpwd Verify_SSL = True [SPEEDTEST] # Leave blank to auto pick server Server = [LOGGING] # Valid Options: critical, error, warning, info, debug Level = debug On peut enfin lancer le nouveau container avec la nouvelle image : root@ds918blam:/volume1/docker/speedtest# docker-compose up -d Creating speedtest2 ... done on attend une petite minute et on vérifie que tout est en place : root@ds918blam:/volume1/docker/speedtest# docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 498d69abfe03 speedtest2:latest "python -u /src/infl…" About a minute ago Up About a minute speedtest2 ... root@ds918blam:/volume1/docker/speedtest# docker logs speedtest2 Loading Configuration File config.ini Configuration Successfully Loaded 2021-01-07 13:22:38,148 - DEBUG: Testing connection to InfluxDb using provided credentials 2021-01-07 13:22:38,341 - DEBUG: Successful connection to InfluxDb 2021-01-07 13:22:38,341 - INFO: Starting Speed Test For Server None 2021-01-07 13:22:38,357 - DEBUG: Setting up SpeedTest.net client 2021-01-07 13:22:38,586 - DEBUG: Picking the closest server 2021-01-07 13:23:08,886 - INFO: Selected Server 16676 in Paris 2021-01-07 13:23:08,887 - INFO: Starting download test 2021-01-07 13:23:13,306 - INFO: Starting upload test 2021-01-07 13:23:16,028 - DEBUG: [{'measurement': 'speed_test_results', 'fields': {'download': 741713644.1996006, 'upload': 549366763.0788989, 'ping': 5.709, 'server': '16676', 'server_name': 'Paris'}, 'tags': {'server': '16676', 'server_name': 'Paris', 'server_country': 'France'}}] 2021-01-07 13:23:16,242 - DEBUG: Data written to InfluxDB 2021-01-07 13:23:16,242 - INFO: Download: 741.71Mbps - Upload: 549.37Mbps - Latency: 5.709ms 2021-01-07 13:23:16,242 - INFO: Waiting 10800 seconds until next test et je retrouve ce test dans mon dashboard (je n'ai pas mis à jour le fuseaux horaire ...) : Le fichier tar à télécharger :speedtest2.tar Remarque : effectué sous DSM7 Beta. Pas de raison que ce soit différent sous DSM6 Si il y a une coquille quelque part, merci de me la signaler. Bruno78
  22. @Jeff777 oui c'est exact, mais ce n'est pas comme si cette image était mise à jour toutes les semaines ....
  23. Je vérifie et revérifie pour être certain que c'est propre et qu'il n'y a pas de coquille ... Il s'agira d'une mise à jour (très simple) de l'image docker d'origine. Il faudra donc mettre à jour le user/pwd dans le fichier config.ini, et mettre le nom de la nouvelle image (locale) que l'on va créer dans le docker-compose. C'est tout 🙂
  24. Bonjour, les sujets se croisent. A propos de Speedtest : Si quelqu'un est intéressé, je pense pouvoir donner la manip (simple) pour ne plus utiliser le compte influxdb admin/admin (quel qu'il soit) mais bien uniquement un user/pwd dédié à la base utilisée pour stocker les mesures speedtest. Cela implique évidemment que cette base soit créée à l'avance et configurée avec un utilisateur dédié. Peut-être pas avant ce weekend néanmoins, pas mal d'occupations ....
×
×
  • Créer...

Information importante

Nous avons placé des cookies sur votre appareil pour aider à améliorer ce site. Vous pouvez choisir d’ajuster vos paramètres de cookie, sinon nous supposerons que vous êtes d’accord pour continuer.