-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Parser les logs du serveur FTP et catégoriser les fichiers #22
Comments
By default vsftpd has a very chatty log: (tiré d'internet, à vérifier) Pour les lignes contenant OK DOWNLOAD, lire le path/file entre les 2 premières virgules. |
OK pour les règles. Il me semble qu'il y a un problème à résoudre au niveau du fonctionnement concret du parsing. En effet, on ne peut pas vraiment parser "la dernière ligne" du fichier de log, ni "les dernières lignes depuis la dernière fois". Cela implique que notre poller va devoir parser l'intégralité du fichier de logs à chaque fois, et que cela va prendre de plus en plus de temps. Ce temps sera peut-être négligeable, je ne suis pas en mesure de me prononcer. De même, est-ce que ce temps entraînera des erreurs (parce que le fichier sera modifié pendant la lecture par le poller) ou pas, je n'en sais rien. Une solution de contournement, qui externalise une partie de la logique mais permet de contourner tout un tas de problèmes est d'imposer au serveur FTP utilisé de ne mettre que des fichiers "terminés" dans le répertoire qui sera surveillé par le poller. Typiquement, le serveur télécharge chaque fichier sous un nom du genre mon-fichier.csv.incomplete et, une fois que c'est terminé, le déplace (opération qui est virtuellement instantanée sur les systèmes de fichiers). On pourrait aussi imaginer de surveiller toute l'arborescence des fichiers uploadés et, quand on en détecte un nouveau, de lancer un nouveau processus de surveillance sur celui-là en particulier, attendre qu'il ne soit plus modifié pendant X secondes, et en déduire que l'upload est terminé. Mais c'est une déduction faillible, et ça ne garantit pas que l'upload a été complété correctement. Il y a peut-être d'autres solutions à envisager, comme d'utiliser un serveur FTP avec des hooks (comme tu l'avais évoqué initialement). |
Je pensais à une solution où le fichier log serait reçu comme un stream de caractères, permettant de lire ligne par ligne. Je ne sais pas si c'est possible. Sinon, il me semble possible d'utiliser une notification de modification du fichier log (comme fs.watch ? - https://thisdavej.com/how-to-watch-for-files-changes-in-node-js/ ) et peut-être stocker la position ( où on en était dans le fichier ? - When you use the fs.read function, there is a parameter called position, that works as the seek position - https://stackoverflow.com/questions/17855186/seek-equivalent-in-javascript-node-js) Ensuite, pour éviter les gros fichiers log, je propose que tous les 4 jours, le parser de log archive le log en cours et clear (il y a un petit risque de conflit à gérer si vsftpd reçoit en même tps, je propose de juste archiver le fichier, l'effacer et s'il y a un retour en erreur d'accès lors de l'effacement, de relire et traiter le log, puis retenter d'archiver /effacer) |
À compléter
The text was updated successfully, but these errors were encountered: