Bonjour,
Je suis vraiment largué coté bash :(
j'ai réussi à faire un petit truc basico basique:
#lecture du fichier de logs squid pour transofrmation en fichier separe par des virgules
awk '{ print $1","$2","$3","$4","$5","$6","$7","$8","$9","10 }' /var/log/squid/access.log > /tmp/access.csv
azcopy cp /tmp/access.csv "trucmachinchoseazure"
rm /tmp/access.csv
J'ai mis une crontab en full * pour un envoi en temps réel
Et maintenant j'ai besoin de séparer les envois.
il faudrait que je n'envois que la différence entre 2 envois
14h00 j'envoi les csv1
14h05 j'envoi le csv contenant les 5mn de log
Mais là, je suis perdu dans ce que je peux faire…
Si vous avez une idée, je suis preneur ^
merci
# 2 choses
Posté par NeoX . Évalué à 4.
toutes les 5 minutes en cron :
sh
*/5 * * * * user /chemin/vers/lescript
ensuite dans ton script
au lieu de faire le rm du fichier cdv
copie le en .precedent
et utilise
diff access.csv access.precedent
avec quelques options à diff, tu trouveras un format qui te permet de n'avoir que ce qui a changé entre les 2 fichiers
ton script deviendrait alors
[^] # Re: 2 choses
Posté par cg . Évalué à 2.
Au lieu de :
mv /tmp/access.current /tmp/access.csv
tu voulais dire :
mv /tmp/access.current /tmp/access.precedent
je crois
Sinon, s'il s'agit du fichier qui est tourné quand il fait 5Go, faire un diff est pas super efficace.
De mémoire, il y a un outil qui permet de faire un tail mais en partant de la position précédente, je retrouve pas le nom (pflogsumm fait ça mais c'est pour postfix).
Je ferais un truc un peu différent, par exemple tourner les logs toutes les n minutes avec logrotate, et utiliser la fonction @script@ de logrotate pour envoyer le log sur Azure.
Ou encore :
Aussi, tu peux demander à Squid d'envoyer ses logs par syslog, et si tu utilises rsyslog, tu peux faire des noms de fichiers de log dynamiques.
Par exemple cette conf rsyslog produit un fichier par jour, rangé dans un répertoire à la date du jour (je dois garder un an de logs, donc j'ai 365 fichiers de logs par équipement réseau) :
Si tu change le template pour découper par minute, tu peux ensuite dans ton cron ne traiter que les fichiers les plus récents (conversion + envoi azure + suppression).
Tu peux même demander à rsyslog de faire en plus un gros fichier (qui sera découpé par logrotate quand il devient trop gros) si tu as besoin de garder les logs sous la main en local, et des petits fichiers par minutes, qui seront supprimés par ton processus d'envoi sur Azure.
(je sais pas si je suis hyper clair là en fait)
Aussi, si les logs vont vers le journal de systemd (en direct ou via syslog), tu peux faire des extractions par date et par unit avec journalctl, ce qui semble assez pratique en l’occurrence.
Voilà pour mes 2 cents, bon amusement ;)
[^] # Re: 2 choses
Posté par totof2000 . Évalué à 2.
L'avantage de rsyslog c'est que tu peux aussi faire la transformation au format qui convient immédiatement avant envoi … Pas besoin de transformtion avec un script externe …
[^] # Re: 2 choses
Posté par kbvz . Évalué à 1.
Tout marche,et je t'en remercie ;)
si je devais envoyer les 2 fichiers en meme temps, penses tu que rajouter une ligne cp avec le ficher (precedent) marcherait?
Thks
# logrotate
Posté par MicP . Évalué à 4. Dernière modification le 08 juillet 2021 à 00:26.
Bonjour
Est-ce qu'il ne vaudrait pas mieux lancer une commande
logrotate
avec son option--force
pour repartir sur un nouveau fichier log qui pourra ensuite être utilisé pour le prochain envoi.Ça éviterai d'avoir à faire un
diff
[^] # Re: logrotate
Posté par totof2000 . Évalué à 2.
Perso dans ce cas de figure, j'utiliserais un outil de gestion de logs (rsyslog ou syslog-ng) pour formatter les logs, et les envoyer vers une queue de message qui s'assurerait de l'envoi en temps réel.
Je pense que Azure devrait permettre d'utiliser ce genre de service. Et ezn configurant l'outil de gestion de logs pour qu'il fasse tampon en cas de perte de connectivité avec azure, c'est tout benef.
Rsyslog, dans sa version libre, permet de monitorer un dossier, et d'envoyer les logs générés dans ce dossier vers le réseau. Cette technique est plus fiable que l'utilisation directe nginx=>syslog=>réseau, car si le daemon syslog tombe, il est capable à la repise de savoir ou il en était dans l'envoi de logs et de ne reprtendre que les logs qu'il n'a pas traité.
Je ne sasis pas si rsyslog mplémente cette fonctionnalité.
[^] # Re: logrotate
Posté par BAud (site web personnel) . Évalué à 3. Dernière modification le 09 juillet 2021 à 19:53.
ou journalctl :-) cf. https://blog.selectel.com/managing-logging-systemd/
et sinon ya http://squidanalyzer.darold.net/ qui est peut-être disponible dans ta distro et fait peut-être ce que tu cherches à faire (c'est quoi le besoin d'ailleurs ?)
même si le access.log semble la méthode préférée d'après https://wiki.squid-cache.org/SquidFaq/SquidLogs …
# pas de rotation, juste un envoi d'informations vers azure
Posté par kbvz . Évalué à 1. Dernière modification le 08 juillet 2021 à 12:49.
Bonjour,
merci de vos retours.
non non ce n'est pas pour faire tourner les logs, la je recupere les logs d'accès de squid (access.log) que je découpe avec awk (je pourrais le faire en tif avec squid mais j'ai besoin qu'un autre programme lise des logs sous un autre format), je les envoi vers un csv qui est lui meme envoyé à un blob azure.
Un collaborteur récupère ces logs et les mets dans un powerBI pour en fait des jolis graphiques qui plaisent ;)
J'ai vu plusieuirs piste ici a creuser ;)
je vais donc prendre ma pelle et fouiller ca ;)
Thks a lot
# Commentaire supprimé
Posté par sendbig . Évalué à -1. Dernière modification le 16 juillet 2021 à 15:06.
Ce commentaire a été supprimé par l’équipe de modération.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.