• # logrotate ?

    Posté par  . Évalué à 3.

    Salut,

    Tout est dans le titre ;)

    Matricule 23415

    • [^] # Re: logrotate ?

      Posté par  . Évalué à 1. Dernière modification le 16 octobre 2020 à 12:05.

      Bonjour, et merci pour cette réponse.

      Je ne connaissait pas cet outils.
      Je vais approfondir son utilisation, mais d'après mon premier survol, je ne suis pas sur que cela réponde parfaitement à mon besoin : logrotate semble générer plusieurs fichiers or j'ai besoin de conserver 1 seul fichier avec le même nom.

      A la base je recherchais plutôt une solution du type cat file combiné à un awk pour filtrer les lignes.

      Je vais approfondir tout ça.

      Merci pour m'avoir fait découvrir cet outils.

      • [^] # Re: logrotate ?

        Posté par  (site web personnel) . Évalué à 3.

        Possible avec awk oui : https://stackoverflow.com/questions/52378894/how-to-delete-lines-in-log-file-older-than-14-days/52378976

        • [^] # Re: logrotate ?

          Posté par  . Évalué à 1.

          Super c'est exactement le principe que je recherche

          Merci beaucoup.

      • [^] # Re: logrotate ?

        Posté par  . Évalué à 4.

        justement c'est fait pour ca

        tu lui dis tout les combien tu veux faire la rotation (tout les mois, semaine, jour)
        et combien tu veux garder de fichier.

        en combinant les 2 tu peux donc n'avoir que le dernier mois de log par exemple.

        parametrable évidemment en fonction des fichiers de logs.

      • [^] # Re: logrotate ?

        Posté par  . Évalué à 2.

        A la base je recherchais plutôt une solution du type cat file combiné à un awk pour filtrer les lignes.

        Si c'est acceptable de perdre les lignes qui seraient ajoutées pendant que tu est en train de traiter le fichier, ou que tu as un moyen d'empêcher l'ajout de logs pendant le traitement, tu peux effectivement partir sur une solution bourrin comme ça.
        Si ces logs sont important, ne fait pas de bricolage et utilise des outils fait pour ça.

  • # Voici ma ligne de commande :

    Posté par  . Évalué à 1. Dernière modification le 16 octobre 2020 à 13:29. 

    cat log.txt | awk -v d="$(date -d "2 months ago" "+%F")" '$1 > d' > log.txt

    Merci à tous.

    • [^] # Re: Voici ma ligne de commande :

      Posté par  . Évalué à 2.

      Salut,

      Et il se passe quoi si le fichier est ouvert en écriture pendant que tu le traite ?

      Je ne veux pas te décourager, hein…

      Matricule 23415

      • [^] # Re: Voici ma ligne de commande :

        Posté par  . Évalué à 1.

        Bien vu : c'est mon problème de débutant.
        Je vais gratter pour y remédier.
        Merci.

        • [^] # Re: Voici ma ligne de commande :

          Posté par  . Évalué à 2.

          Salut,

          c'est mon problème de débutant.

          Être débutant n'est jamais un problème (j'insiste : jamais).

          On ne nait pas avec la science infuse ;)

          Donc voilà, ce n'est pas grave, tu as travaillé des morceaux intéressants, ça te permet d'être moins débutant, et petit à petit ça sera là. ;)

          Je n'ai pas regardé l'historique de logrotate, mais je suis presque prêt à parier un billet qu'ils se sont confrontés au même problème.

          Bon courage ;)

          Matricule 23415

    • [^] # Re: Voici ma ligne de commande :

      Posté par  . Évalué à 2. Dernière modification le 16 octobre 2020 à 14:23.

      Re-salut,

      Je vais tenter d'être moins cryptique.

      1. tu cat ton fichier,
      2. les données sont transférées à awk via le pipe,
      3. le soft a envie d'écrire, donc il rajoute une ligne (mais le cat étant fait, aucun moyen d'y revenir),
      4. awk fait son traitement, comme demandé,
      5. et on écrase tout ça.

      Ta petite ligne de log, qui aurait pu te servir, elle est dans /dev/null ;)

      Matricule 23415

      • [^] # Re: Voici ma ligne de commande :

        Posté par  . Évalué à 1.

        Donc en gros durant le traitement de mon fichier log je perds les éventuelles nouvelles entrées.
        Quel est ou sont les mécanismes afin d'éviter ce soucis ?

      • [^] # Re: Voici ma ligne de commande :

        Posté par  . Évalué à 1.

        Dois-je dupliquer mon fichier originel pour faire mon traitement et comparer les 2 fichier pour analyser les # ?
        Peux t-on temporiser les entrées durant le traitement ?

        • [^] # Re: Voici ma ligne de commande :

          Posté par  . Évalué à 2.

          Salut,

          Le problème va rester identique :)

          Il se passe quoi si ton log est modifié pendant la comparaison ?

          Et il y a certainement plein d'autres choses aux quelles je n'ai pas pensé.

          Le code de logrotate est disponible, mais honnêtement, c'est pas mon envie de creuser dedans.

          Matricule 23415

          • [^] # Re: Voici ma ligne de commande :

            Posté par  . Évalué à 1. Dernière modification le 16 octobre 2020 à 16:05.

            Donc si je comprend bien, j'ai mis le doigt sur une des limites du système

            Le code de logrotate est disponible, mais honnêtement, c'est pas mon envie de creuser dedans.

            Et moi probablement pas les compétences

            Pour conclure : je peux faire ma manipe, mais je dois avoir en tête qu'il est probable que je perde quelques infos durant l'opération et en faire mon deuil.

            • [^] # Commentaire supprimé

              Posté par  . Évalué à 2.

              Ce commentaire a été supprimé par l’équipe de modération.

              • [^] # Re: Voici ma ligne de commande :

                Posté par  . Évalué à 1.

                oui je vais approfondir cette solution en combinant les 2
                Merci

              • [^] # Re: Voici ma ligne de commande :

                Posté par  . Évalué à 1.

                Pas sur que logrotate soit la solution à mon besoin :
                Si j'effectue une l'opération quotidiennement avec un rotate de 30 (pour 1 mois), j'obtiendrai 31 fichiers indicé de chacun 1 jour de log (le fichier sans indice étant celui du jour).
                Or ce dont j'ai besoin c'est d'un seul fichier contenant 1 mois glissant. donc si je concatène mes 31 fichiers (aujourd'hui compris) pour atteindre mon objectif, je retrouve le même problème durant l'écriture.

                Si par contre j'effectue l'opération une fois par mois, je n'aurais jamais le contenu d'un mois glissant, mais un fichier allant de la date de rotation à aujourd'hui.

                Ou alors je ne comprend pas correctement le fonctionnement le logrotate

                • [^] # Commentaire supprimé

                  Posté par  . Évalué à 2. Dernière modification le 16 octobre 2020 à 18:27.

                  Ce commentaire a été supprimé par l’équipe de modération.

                  • [^] # Re: Voici ma ligne de commande :

                    Posté par  . Évalué à 1.

                    Parfait, même si ce n'est pas aussi simple que ne le pensais au début, cela me parait être la meilleur solution.

                    Merci.

                • [^] # Re: Voici ma ligne de commande :

                  Posté par  . Évalué à 4. Dernière modification le 16 octobre 2020 à 20:14.

                  Or ce dont j'ai besoin c'est d'un seul fichier contenant 1 mois glissant.

                  Je ne comprend pas ce besoin.
                  Que fais-tu avec ce fichier de log qui exige que tout reste dans un seul fichier?
                  Pourquoi est-ce que ça ne fonctionnerait pas si les données sont réparties dans plusieurs fichiers aux noms prévisibles?
                  J'ai l'impression qu'on est dans un cas de Problème XY

                  • [^] # Re: Voici ma ligne de commande :

                    Posté par  . Évalué à 1.

                    tout simplement parce qu'en aval, des outils (dont je n'ai pas la maitrise) de consultation avec des filtres variables utilisent ce fichier. Je ne peux donc pas modifier le nom de la source d'information.

                    • [^] # Re: Voici ma ligne de commande :

                      Posté par  . Évalué à 3.

                      Et ces outils ont besoin de l'information en temps réel, c'est un problème s'ils ne voient pas tout de suite les lignes des dernières minutes?
                      Ça me donne plutôt l'impression que ces données devraient être stockées dans une base de données (pas forcément relationnelle), plutôt que dans un simple fichier de log.

                      • [^] # Re: Voici ma ligne de commande :

                        Posté par  . Évalué à 1. Dernière modification le 17 octobre 2020 à 00:06.

                        Et ces outils ont besoin de l'information en temps réel, c'est un problème s'ils ne voient pas tout de suite les lignes des dernières minutes?

                        Cette problématique traite de vidéo surveillance, donc plus le laps de temps est court, mieux c'est.
                        Quelques secondes n'auront que peu de conséquences, mais des minutes seront critiques.

                        Par contre l'utilisation d'une base de données qui simplifierait grandement les choses est à l'étude.

                        • [^] # Re: Voici ma ligne de commande :

                          Posté par  . Évalué à 3.

                          Salut,

                          Cette problématique traite de vidéo surveillance, donc plus le laps de temps est court, mieux c'est.

                          Donc on est bien dans un problème XY comme indiqué plus haut.

                          Plus tu vas bidouiller avec tes solutions bricolées, moins ça va répondre au besoin (parce que tu n'aura pas les années d'expérience nécessaires, vu les erreurs que ça implique… bref).

                          Tu devrais étudier le code de logrotate, c'est pas une simple ligne shell. Je ne crois pas que les personnes qui l'ont développé se soient un instant dit : fastoche en deux ou trois commandes.

                          Ils se sont posé des questions, que tu n'a même pas l'air de te poser.

                          Je reprend :

                          plus le laps de temps est court

                          Mais avec logrotate, il n'y a pas de laps de temps !

                          Ce que tu cherche à faire, c'est une roue carrée :)

                          Matricule 23415

                    • [^] # Re: Voici ma ligne de commande :

                      Posté par  . Évalué à 3.

                      tout simplement parce qu'en aval, des outils (dont je n'ai pas la maitrise) de consultation avec des filtres variables utilisent ce fichier.

                      Mauvais outils, changer d’outils…

                      Si logrotate fonctionne comme il fonctionne, c’est bien parce que c’est la solution qui pose le moins de problèmes (systemd gère lui‐même ses logs avec un format non texte, eh bien devine quoi ! il utilise aussi plusieurs fichiers).

                      Personnellement (faute de pouvoir changer d’outils), je ferais un logrotate quotidien et je lancerai le filtre sur les fichiers logrotate des 30 derniers jours pour produire le fichier expurgé. Les utilitaires en ligne de commande supportent souvent plusieurs fichiers en entrée et au minimum un tuyau. Et tu verses tes fichiers dedans avec une commande du style cat log.30 log.29 … log.1 log | filtre > log_expurge (là, c’est 30 jours plus le jour en cours).

                      « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone

                      • [^] # Re: Voici ma ligne de commande :

                        Posté par  . Évalué à 1. Dernière modification le 17 octobre 2020 à 12:38.

                        Mauvais outils, changer d’outils…

                        En effet j'en ai bien conscience, c'est la raison pour laquelle l'utilisation d'une base de données est à l'étude.

                        Je vous remercie tous pour vos approches expérimentées qui me permettent d'avoir une meilleur vision de ce type de problématique et qui me permettrons une meilleur anticipation à l'avenir.

                        • [^] # Re: Voici ma ligne de commande :

                          Posté par  . Évalué à 2.

                          Si tu peux faire une approximation du style deux mois = 60 jours + le jour courant, avec un logrotate paramétré avec daily et rotate 60, la ligne de commande que tu as indiquée peut être remplacée par un simple cat, du style :

                          cat log.60 log.59 log.58 log.57 log.56 log.55 log.54 log.53 log.52 log.51 log.50 log.49 log.48 log.47 log.46 log.45 log.44 log.43 log.42 log.41 log.40 log.39 log.38 log.37 log.36 log.35 log.34 log.33 log.32 log.31 log.30 log.29 log.28 log.27 log.26 log.25 log.24 log.23 log.22 log.21 log.20 log.19 log.18 log.17 log.16 log.15 log.14 log.13 log.12 log.11 log.10 log.9 log.8 log.7 log.6 log.5 log.4 log.3 log.2 log.1 log > log_assemble.txt

                          J’ai généré cette ligne avec :

                          perl -e 'print "cat ", map("log.$_ ", reverse(1 .. 60)), "log > log_assemble.txt\n"'

                          « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone

                          • [^] # Re: Voici ma ligne de commande :

                            Posté par  . Évalué à 3. Dernière modification le 17 octobre 2020 à 15:10.

                            Juste pour info (puisque ça ne répond pas à son besoin, vu qu'il veut du quasi temps réel), avec bash (et probablement d'autres shells), ça peut s'écrire plus simplement:

                            cat log.{60..1..-1} log > log_assemble.txt

      • [^] # Re: Voici ma ligne de commande :

        Posté par  (site web personnel) . Évalué à 3.

        C'est pire que ça.

        Dès le branchement des redirections, le fichier de log est tronqué et ouvert en écriture, et tout son contenu est perdu.

        Deux possibilités pour éviter cela :

        • commencer par dupliquer le fichier, et travailler sur une copie, en générant le fichier allégé directement.
        • travailler sur le fichier original, générer un nouveau fichier allégé sous un autre nom, puis remplacer le fichier original.

        Dans les deux cas, cela ne résout pas le souci que tu mentionnais (les éventuelles lignes de log perdues en cours de route). Mais cela évite de tout perdre.

        Debian Consultant @ DEBAMAX

        • [^] # Re: Voici ma ligne de commande :

          Posté par  . Évalué à 1.

          Dès le branchement des redirections, le fichier de log est tronqué et ouvert en écriture, et tout son contenu est perdu.

          Ok je pensais que l'on travaillait sur un tampon le temps de faire la réécriture.
          => ok pour le fichier dupliqué.

          Merci

        • [^] # Re: Voici ma ligne de commande :

          Posté par  . Évalué à 2.

          Salut,

          C'est pire que ça.

          Je n'ai pas dis le contraire, juste pris dans mon truc qui me sert à base de neurones le premier exemple de what could go wrong?

          S'il y a tout un programme pour ça, c'est que ce n'est pas si simple ;)

          Matricule 23415

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.