Pouvoir envoyer des requêtes directes à InfluxDB via un fichier

[Augustin82]

• lire un fichier "quelque part" (à spécifier par @pf26)
• récupérer son contenu (en théorie une requête InfluxDB) et l'exécuter

Voir ici par exemple, pour une ébauche d'interaction avec InfluxDB :
https://docs.influxdata.com/influxdb/v2.0/write-data/delete-data/#delete-data-using-the-api

[pf26]

fichier "cmd.txt" à placer dans n'importe quel répertoire - par exemple sous 0001...
Plutôt que l'API, je pensais envoyer le texte en CLI,
Par exemple le texte:
influx delete --bucket example-bucket
--start 2020-03-01T00:00:00Z
--stop 2020-11-14T00:00:00Z
https://docs.influxdata.com/influxdb/v2.0/write-data/delete-data/

[pf26]

Une possibilité pour effectuer une action à l'arrivée d'un fichier sur le serveur FTP (vsFTP est utilisé pour l'Herbier)
https://stackoverflow.com/questions/10956668/run-a-shell-command-when-a-file-is-added

[Augustin82]

Merci ! C'est ce dont je te parlais hier : utiliser un script de polling, soit pour faire de la surveillance du système de fichier, via inotify ou autre, soit pour surveiller le fichier de logs du serveur FTP.
Pour des raisons de robustesse et de reproductibilité, je pense qu'il faudrait mettre en place un vrai système intégré de surveillance des fichiers. Là on a déjà un cron qui tourne et qu'il faut repenser à relancer, si on rajoute un ou plusieurs scripts "à faire tourner", on va se retrouver bientôt dans un environnement qui sera trop complexe pour penser à tout.

[pf26]

Je lis en effet que seul pure-ftpd semble avoir une uploadscriptT option...
Peut-être est-ce plus simple de changer de serveur FTP ? de notre coté, ça nous arrangerait, car on l'a toujours utilisé et on sait que ça marche bien avec nos systèmes (qui peuvent être tatillons sur les timings quand ça arrive par GPRS/3G)
Mais peut-être y a-t-il d'autres raisons pour le choix vsFTP

[Augustin82]

Si tu veux qu'on regarde comment faire évoluer l'image pour utiliser un autre serveur FTP, on peut.
Je ne veux pas parler à la place de @tglatt mais je pense que le choix de vsFTP a été celui de la simplicité avant tout.

Par contre, je pense que c'est une mauvaise idée d'ajouter un point d'entrée par ce biais là. Toute la démarche entreprise vise à "industrialiser" ce logiciel et les fonctionnalités que tu demandes, en les rendant reproductibles et portables. Multiplier les outils qui vont interagir avec le code va à l'encontre de ces principes, à mon avis.

[pf26]

Je suis d'accord sur l'intérêt d'éviter de multiplier les outils. Cpt, actuellement le parsing est lancé par Cron, on n'a donc pas d'autre choix que d'avoir un autre outil pour gérer en "tps réel" l'arrivée de fichiers FTP. Au final, il me semble mieux que tout (=parsing et envoi de cmd à InfluDB) soit géré par un seul script de polling. J'aimerais juste qu'on assure de garder une taille raisonnable de fichier log, et faire qu'en cas de pb d'accès à ce fichier log, le script de polling se relance tout seul (on a déjà eu ce genre de soucis je crois).

[Augustin82]

Le cron est, à mon sens, une solution temporaire.

C'est ce dont je te parlais l'autre jour : selon moi, "à terme" (c'est-à-dire plus ou mons vite selon tes besoins et priorités), il faudrait lancer un processus continu (un daemon, en gros) en Node qui pourrait lancer régulièrement du polling pour différentes actions (update de table device_name, récupération de commandes influx, parsing de csv, etc.), chacune avec un intervalle spécifique.

Un cron, c'est facile à faire et pas cher, donc c'est rentable de faire ça plutôt que de développer ce système. Mais quand vont arriver les autres besoins, je pense pas qu'il faille faire l'économie.

[Augustin82]

J'ai mergé dans master un commit qui apporte la fonctionnalité suivante : pouvoir (par le lancement d'un script) exécuter une requête InfluxDB contenue dans un fichier. Ça ouvre la voie à l'automatisation via le FTP, mais cette question-là soulève certains problèmes (j'en parlerai dans le ticket concerné).