Vous avez 4 heures

Déjà 38 avis pertinents dans Vous avez 4 heures

• Maitrepylos

  22 mars 2019 à 18 h 17 min

  La date est importante ? Cela s’arrête à minuit ?
• Cascador

  22 mars 2019 à 18 h 27 min

  Salute,

  Le fichier de logs correspond à celui du 22/01 (monpetitserveur-2019-01-22.log), le fichier de logs s’arrête à minuit puisque ce sont les logs du jour.

  Tcho !

• AP41

  22 mars 2019 à 18 h 34 min

  Ma solution n’utilise pas ansible mais GNU parallel pour traiter un max de serveurs en simultané. « parallel », c’est le bien.

  On admet que…
  1. On peut se connecter par ssh sans mot de passe sur tous les serveurs,
  2. On dispose de la liste des serveurs dans un fichier « listeserveurs »,
  3. Que l’outil GNU parallel est installé localement,
  4. Que l’outil grep est installé sur les serveurs distants *ET* qu’il est suffisamment récent pour gérer des expressions régulières

  Soit le script bash suivant, qui va créer des fichiers « log_ ».

  #!/bin/bash

  logserveur() {
  serveur=$1

  # Sur le serveur, on greppe les logs du 22 janvier
  # - à 11h quarante ou cinquante quelque chose
  # - de 12 à 19h quelque chose
  # - de 20 à 23h quelque chose

  # Le grep est lancé sur le serveur distant pour minimiser ce qu'on fait transiter par le réseau.
  # Le "-C" de ssh s'assure qu'on réduit autant que possible l'utilisation du réseau en compressant.
  # L'utilisateur est omis, pour la lisibilité du truc. On aura paramétré son ~/.ssh/config pour choisir le bon. :)

  if ssh -C $serveur 'grep -E " \[22/Jan/2019:(11:[45]|1[2-9]:|2[0-3]:)" /var/log/logsquinousinteressent' > "logs_$serveur"
then
echo "OK $serveur"
else
echo "SOUCI $serveur"
fi
}

  # Rend la fonction logserveur() visible à GNU parallel
  export -f logserveur

  # Interrogation en parallèle des serveurs dans la le fichier « listeserveurs »,
  # avec un maximum de 16 machines sondées simultanément. On peut ajuster le paramètre
  # ou le virer pour laisser parallel lancer autant de process qu’il le peut…

  parallel --jobs 16 logserveur :::: listeserveurs
echo "Fini..."

• Grinn

  22 mars 2019 à 18 h 44 min

  Je crois que je ferais un bête grep avec un petite regex :
  egrep '\[22/Jan/2019:(11:[45][0-9]|1[2-9]|2[0-3]):' fichier.de.log
• Maxime

  22 mars 2019 à 18 h 54 min

  Un simple grep :
  grep -vE "22/Jan/2019:(0|10|11:[0-3])" file.log
• Cascador

  22 mars 2019 à 18 h 58 min

  @all,

  Je pense que j’ai mal exposé le problème. Les logs que j’ai donné sont un exemple « type », sur les autres serveurs il y a des logs à toutes les heures (par exemple à 14h, 15h, 16h etc.). Il faut récupérer tous les logs à partir de 11h40 jusqu’à minuit.

  Tcho !

• AP41

  22 mars 2019 à 19 h 01 min

  Rhaa mon indentation et mes guillemets ont été mangés. Après la question est de savoir si j’étais hors sujet en allant au delà du simple grep pour détailler le mode opératoire de récupération rapide couplant parallel et ssh. J’ai interprété le « récupérer » de l’énoncé en « extraire sélectivement ET rapatrier ».
• Cascador

  22 mars 2019 à 19 h 01 min

  Salute @Maxime,

  Je crois que tu as la solution la plus sexy à mes yeux pour l’instant.

  Tcho !

• Cascador

  22 mars 2019 à 19 h 04 min

  Salute @AP41,

  Ta réponse me semble très bien, merci d’avoir participé !

  Tcho !

• Cascador

  22 mars 2019 à 19 h 06 min

  Yo @Grinn,

  Ta réponse me semble correcte, merci de ta participation

  Par rapport à la réponse de @AP41, le [0-9] dans 11:[45][0-9] apporte quelque chose ?

  Tcho !

• patrick

  22 mars 2019 à 19 h 22 min

  petite version bash (a modifier cat *.log…)

  mini=${1-'22-Jan-2019 08:38'}
dmini=$(date -d "$mini" "+%s")
echo "Date mini: $mini == $dmini"
declare -a line=()
while IFS='[]' read -ra line ; do
d="${line[1]}"
d="${d//[\/]/-}"
d="${d/[:]/ }"
if [[ $(date -d "$d" "+%s") > "$dmini" ]]; then
echo "$d"
else
echo "$d < $mini" # pour test
fi
done < <(cat *.log )

• SImon

  22 mars 2019 à 19 h 32 min

  cat logs | while read line; do echo "$line" | php -r '$line = file_get_contents("php://stdin"); $date = new DateTime(explode("]", explode("[", $line)[1])[0]); if ($date->getTimestamp() >= 1548153600) echo $line;'; done

  monpetitserveur.net 42.248.86.23 - - [22/Jan/2019:11:40:57 +0100] "GET
monpetitserveur.net 2a00:1450:1:815:124::1 - - [22/Jan/2019:11:40:57 +0100] "POST
monpetitserveur.net 104.48.123.201 - - [22/Jan/2019:12:16:45 +0100] "GET
monpetitserveur.net 84.12.145.4 - - [22/Jan/2019:12:49:41 +0100] "GET
monpetitserveur.net 84.12.154.4 - - [22/Jan/2019:12:49:43 +0100] "GET
monpetitserveur.net 2a00:1450:1:815:124::1 - - [22/Jan/2019:12:49:44 +0100] "POST
monpetitserveur.net 42.248.86.23 - - [22/Jan/2019:12:50:02 +0100] "GET
monpetitserveur.net 45.85.135.74 - - [22/Jan/2019:13:15:27 +0100] "GET
monpetitserveur.net 45.85.135.74 - - [22/Jan/2019:13:15:27 +0100] "GET
monpetitserveur.net 42.248.86.23 - - [22/Jan/2019:13:46:11 +0100] "GET
monpetitserveur.net 53.56.8.95 - - [22/Jan/2019:13:48:09 +0100] "POST
monpetitserveur.net 2a00:1450:1:815:124::1 - - [22/Jan/2019:13:48:09 +0100] "POST
monpetitserveur.net 190.18.127.56 - - [22/Jan/2019:20:06:48 +0100] "POST
monpetitserveur.net 2a00:1450:1:815:124::1 - - [22/Jan/2019:20:06:50 +0100] "POST

• patrick

  22 mars 2019 à 19 h 42 min

  en bash (mais les commentaires suivants n’existaient pas et pas compris que la limite était minuit mais il est simple de rajouter un MAX)

  mini=${1-'22-Jan-2019 08:38'}
dmini=$(date -d "$mini" "+%s")
echo "Date mini: $mini == $dmini"
declare -a line=()
while IFS='[]' read -ra line ; do
d="${line[1]}"
d="${d//[\/]/-}"
d="${d/[:]/ }"
if [[ $(date -d "$d" "+%s") > "$dmini" ]]; then
echo "$d"
else
echo "$d < $mini" # pour test
fi
done < <(cat *.log )

  ps: premier post non passé ?

• Cascador

  22 mars 2019 à 19 h 53 min

  Yo @SImon,

  Correct, perso j’évite le cat logs et j’ajoute à la fin < logs (cependant il faut un saut de ligne à la fin sinon il bouffe la dernière ligne).

  Tcho !

• Cascador

  22 mars 2019 à 19 h 56 min

  Salut @patrick,

  On valide manuellement les commentaires ici. Ta proposition gère à partir de 11h40, j’en vois aucune trace ?

  Tcho !

• patrick

  22 mars 2019 à 20 h 12 min

  ? moi ça marche, juste entrer $1

  ./log.sh "22-Jan-2019 11:40"
Date mini: 22-Jan-2019 11:40 == 1548153600
22-Jan-2019 00:54:21 +0100 < 22-Jan-2019 11:40
...
22-Jan-2019 11:22:17 +0100 < 22-Jan-2019 11:40
22-Jan-2019 11:40:57 +0100
...
22-Jan-2019 20:06:48 +0100
22-Jan-2019 20:06:50 +0100

• Fabien

  22 mars 2019 à 20 h 13 min

  Ma contribution

  #!/bin/bash

  heuredebut="11"
  heurefin="23"
  date='22/Jan/2019'

  for (( i=$heuredebut; i> /home/fabien/test/ctete/logextract
done

  C’est pas top mais ca semble marcher

• Fabien ABC

  22 mars 2019 à 20 h 21 min

  Petite modif

  #!/bin/bash

  heuredebut="11"
  heurefin="23"
  date='22/Jan/2019'

  for (( i=$heuredebut; i> /home/fabien/test/ctete/logextract
fi
echo $i
cat /home/fabien/test/ctete/log | grep $date":"$i >> /home/fabien/test/ctete/logextract
done

• Cascador

  22 mars 2019 à 20 h 30 min

  Yo @Fabien,

  Mais là tu prends tous les logs entre 11h00 et 11h39 avec ? Not good.

  Tcho !

• Cascador

  22 mars 2019 à 20 h 31 min

  @patrick,

  Mais du coup c’est quoi mini=${1-’22-Jan-2019 08:38′} ? Le 08:38 surtout.

  Tcho !

• patrick

  22 mars 2019 à 20 h 51 min

  cette ligne c’est juste une valeur par défaut si pas de $1 – c’est plus une documentation 08:38 c’est l’heure
  correctif avec min et max (+ pour logs multi-jours ou plage de quelques heures)

  #usage ./log.sh "22-Jan-2019 11:40" "22-Jan-2019 13:00"
mini=${1-'22-Jan-2019 08:38'} # valeur par défaut si $1 non entré
dmini=$(date -d "$mini" "+%s")
max=${2} # ici maxi c'est date/heure courante
dmax=$(date -d "$max" "+%s")
echo "Date mini: $mini == $dmini"
echo "Date maxi: $max == $dmax"
declare -a line=()
while IFS='[]' read -ra line ; do
d="${line[1]}"
d="${d//[\/]/-}"
d="$(date -d "${d/[:]/ }" "+%s")"
[[ "$d" -ge "$dmini" ]] && [[ "$d" < "$dmax" ]] && printf "%s[%s]%s\n" "${line[0]}" "${line[1]}" "${line[2]}"
done < <(cat *.log )

• unixmipfr

  22 mars 2019 à 21 h 14 min

  awk -F'/' 'substr($3,6,2)substr($3,9,2)>=1140 {print}' log_file

  monpetitserveur.net 42.248.86.23 - - [22/Jan/2019:11:40:57 +0100] "GET
monpetitserveur.net 2a00:1450:1:815:124::1 - - [22/Jan/2019:11:40:57 +0100] "POST
monpetitserveur.net 104.48.123.201 - - [22/Jan/2019:12:16:45 +0100] "GET
monpetitserveur.net 84.12.145.4 - - [22/Jan/2019:12:49:41 +0100] "GET
monpetitserveur.net 84.12.154.4 - - [22/Jan/2019:12:49:43 +0100] "GET
monpetitserveur.net 2a00:1450:1:815:124::1 - - [22/Jan/2019:12:49:44 +0100] "POST
monpetitserveur.net 42.248.86.23 - - [22/Jan/2019:12:50:02 +0100] "GET
monpetitserveur.net 45.85.135.74 - - [22/Jan/2019:13:15:27 +0100] "GET
monpetitserveur.net 45.85.135.74 - - [22/Jan/2019:13:15:27 +0100] "GET
monpetitserveur.net 42.248.86.23 - - [22/Jan/2019:13:46:11 +0100] "GET
monpetitserveur.net 53.56.8.95 - - [22/Jan/2019:13:48:09 +0100] "POST
monpetitserveur.net 2a00:1450:1:815:124::1 - - [22/Jan/2019:13:48:09 +0100] "POST
monpetitserveur.net 190.18.127.56 - - [22/Jan/2019:20:06:48 +0100] "POST
monpetitserveur.net 2a00:1450:1:815:124::1 - - [22/Jan/2019:20:06:50 +0100] "POST

• Cascador

  22 mars 2019 à 21 h 52 min

  @patrick,

  Je comprends mieux, c’est chouette en bash même si par rapport à d’autres solutions proposées (notamment grep), ça parait bien lourd.

  Tcho !

• Cascador

  22 mars 2019 à 22 h 04 min

  Yo @unixmipfr,

  Très sympa, merci ! J’aime beaucoup awk, j’apprécie d’autant plus.

  Tcho !

• PoluX

  22 mars 2019 à 22 h 43 min

  journalctl --since "2019-03-22 11:40:00"
• systemd

  22 mars 2019 à 23 h 53 min

  vive systemd!

  journalctl --since="2019-01-22 22:40:00" --until="2019-01-23 00:00:00"

• Cascador

  23 mars 2019 à 6 h 49 min

  Yo @PoluX et @systemd,

  Je considère cette proposition comme erronée :
  – Par défaut le journal systemd est circulaire, une fois la taille maximum du journal atteinte il vient écraser les entrées les plus anciennes. On peut donc se retrouver avec « seulement » deux heures de logs sur un serveur mal configuré et il y a de très fortes chances qu’il n’y ait plus rien du 22/01 quand on est le 22/03
  – Le journal systemd logue tout ce qui tourne autour de systemd notamment les services, on peut balancer ce qu’on veut dans le journal en le configurant mais j’ai rarement vu balancer les logs web dedans
  – A minima la proposition matche une date mais ne trie aucune entrée, sachant tout ce qui est balancé dans le journal il faudrait ensuite récupérer uniquement les logs web (en quelque sorte on retourne le problème)

  Tcho !

• marc

  23 mars 2019 à 7 h 54 min

  par habitude (pas testé) je dirais

  perl -lne '
print if m{
\[22/Jan/2019
:(\d{2})
:(\d{2})
}x && ( ($1 > 11) || (($1 == 11) && ($2 >= 45 )) )
' *.log

• Breizh

  23 mars 2019 à 16 h 13 min

  Tous les systèmes de logs sont circulaires à plus ou moins long terme, sinon RIP l’espace disque. Suffit de bien configurer son système. En l’occurence si on nous demande des logs de janvier en mars, on réponds juste « lol nope, nous c’est 14 jour, avec les backups on peut remonter à un mois au mieux ».

  La commande systemd adaptée : `journalctl –since « 2019-03-22 11:40:00 » -u apache2.service`. Évidemment, à adapter, dans mon cas ce sera haproxy.service (j’ai reporté tout mes logs web via HAProxy par simplicité). Et oui, mes logs web vont dans systemd.

• Cascador

  24 mars 2019 à 10 h 43 min

  Yo @marc,

  Je trouve ça complexe sinon c’est pas mal.

  Tcho !

• Cascador

  24 mars 2019 à 11 h 39 min

  Yo @Breizh,

  Je ne suis pas d’accord sur ta façon de dire/présenter les choses. Le fonctionnement du journal systemd est circulaire, c’est le bon terme qui est utilisé, les anciennes entrées sont remplacées par les nouvelles. Si on passe par rsyslog par exemple, il n’y a aucune gestion de la rotation des logs, c’est logrotate qui s’en occupera.

  Par défaut la config du journal systemd c’est de loguer dans /run/log/journal qui sera perdu au prochain démarrage. Si on le met dans /var/log/journal c’est par défaut 10% de l’espace total de la partition où sont stockés les fichiers, bien loin de ce que rsyslog et logrotate prendront comme espace puisque effectivement comme tu le dis ils peuvent le remplir.

  Concernant les logs web à 14 jours, c’est jouer avec le feu puisque la loi Française demande 1 an mais la loi Européenne dit autre chose lol (https://korben.info/a-propos-de-duree-de-conservation-logs-de-connexion.html). Dans le doute et pour éviter tout problème, nous conservons 1 an chez nous.

  Tcho !

• Linuz

  25 mars 2019 à 10 h 40 min

  Hello,
  Autre petite solution avec awk (tant que la date est en 5ème colonne) :
  awk -v from="[22/Jan/2019:11:40:00" -v to="[22/Jan/2019:23:59:59" '$5>=from && $5<=to' test.log
• yoko

  25 mars 2019 à 11 h 30 min

  @Cascador t’es entrain de troller systemd/journald. Même si les configuration par défaut ne sont pas les même tu peux avoir des comportements proches entre systemd+journald et syslog+logrotate. C’est une évidence qu’il faut que ta gestion de log soit bien configurée pour pouvoir être correctement configurée. J’aime sincèrement beaucoup le scripting et je parse mes logs avec less, grep, rg et sed, mais ça n’empêche pas de se dire qu’avoir une date correctement parsée rend les choses beaucoup plus simple (ajoute 1h à ta date limite et ça invalide 90% des réponses que tu as eu). journald n’est pas la seule solution à sa les solutions des mutualisation des logs (ELK en tête mais il y en a d’autres) auront aussi cet intérêt (en plus d’être clairement plus pertinent si tu a un parc de 130 serveurs). Tout en permettant de gérer la rétention d’un an plus facilement (avoir un serveur avec un gros volume de log alloué c’est plus simple que de devoir prédire les besoins de chaque serveur).
• Cascador

  25 mars 2019 à 12 h 42 min

  Yo @Linuz,

  Ha ha top, merci !

  Tcho !

• Cascador

  25 mars 2019 à 12 h 48 min

  Salute @yoko,

  Il faut arrêter de dire qu’on trolle quand on n’est pas d’accord ou qu’on fait différemment. Comme d’hab on ne réfute pas les arguments, on ne les conteste pas mais on part sur autre chose pour dire « t’as tort ». Si vous voulez faire passer du gris pour du blanc c’est cool mais il faut pas s’attendre à ce que tout le monde suive.

  Dans ton discours on dirait que je suis contre journald, c’est être contre de dire que c’est différent de rsyslog + logrotate ? C’est faux de dire que le fonctionnement du journal systemd est circulaire contrairement à rsyslog ?

  On me demanderait presque de justifier que systemd-journald fait pas le boulot alors qu’à aucun moment je n’ai dit ça, c’est de l’interprétation, une forme de lecture supérieure des pensées d’autrui ?

  J’aime particulièrement systemd et j’apprécie grandement le journal systemd ainsi que journalctl (et il n’y a pas de mais). Dans le cadre de l’article, ces logs ne passent pas par le journal systemd et non journalctl --since "2019-03-22 11:40:00" ne fait pas le boulot, ça remonterait tous les logs donc ça sert à rien. Je n’ai pas parlé du journal systemd dans l’article, on est très loin du fait que tout le monde n’utilise que lui, je dois justifier davantage qu’une réponse avec journalctl est erronée ?

  Je précise que la proposition est pas mauvaise en soi, c’est même très bien de rappeler les bases mais c’est juste à côté du problème posé. Si il y a eu 10 réponses avant qui ne parlaient pas de systemd, c’est pas pour rien.

  Tcho !

• Breizh

  25 mars 2019 à 13 h 08 min

  Nan mais faut bien configurer journald au même titre que tu configures rsyslog et logrotate, sinon ça n’a aucun sens.

  Nous on ne logue que 14 jours parce que 1 an c’est bien gentil, mais ça prends de la place. 1 an de logs mails, de logs web, etc (surtout quand le site est bourré d’erreurs remplissant les errorlog) pour un site, ça représente déjà quelques dizaines de Gio. Si on les conserves sur l’infra du client (et c’est ce qu’on fait actuellement), ça lui coûterait plus cher en espace disque pour les logs que pour ses données, et ça remplirait nos hyperviseurs bien plus rapidement, ça serait pas rentable, aussi bien techniquement (plus d’espace consommé par chaque VM = moins de VM par hyperviseur) qu’économiquement (pareil, ratio VM vendues / hyperviseurs nécessaires qui diminue).

  Si on les conserve sur une infra dédiée… ben avec quelques centaines de clients, pour un total que plus de 1500 serveurs (dédiés ou virtuels), et jusqu’à quelques centaines de sites par serveur pour les plus gros, ça commence à chiffrer sévère (en stockage, et en coût d’exploitation de l’infra… sans parler de toute la complexité que ça ajoute). 1 an de logs, c’est juste intenable techniquement parlant, et catastrophique économiquement parlant dans notre cas.

  La loi Française a toujours été absurde, maintenant elle est carrément contradictoire à la loi Européenne, et il me semblait avoir lu que l’Europe avait indiqué que la loi Française ne pouvait être appliquée si on veut être dans les règles.

• Cascador

  25 mars 2019 à 14 h 12 min

  Yo @Breizh,

  « Nan mais faut bien configurer journald au même titre que tu configures rsyslog et logrotate, sinon ça n’a aucun sens » => On est bien d’accord, juste qu’à titre perso je trouve la config par défaut de journald très casse-gueule

  Intéressant ton retour sur les logs, je comprends en te lisant que tu parles d’un environnement professionnel. C’est pas toujours évident de saisir le contexte sur lequel on échange (perso, pro, association…). En simplifiant pas mal nous aussi on conserve deux semaines sur les différents serveurs mais simultanément on balance/centralise tous les logs sur un serveur (avec une rétention bien plus longue). Je me rends pas bien compte de votre volumétrie, un RAID 5 (+ hotspare) de 10 disques de 10 To par exemple, ça ne suffirait pas ?

  Il y a aussi des solutions qui paraissent crades mais quand il n’y en a pas d’autres… pourquoi pas plusieurs raspberry pi avec chacun un dd externe de 4 To qui synchronisent les logs toutes les nuits (puis changer le dd externe quand il est full) ? Je préfère mettre un truc crade en place, que de pas mettre de solution en face d’un problème.

  Tcho !

• Cascador

  25 mars 2019 à 17 h 32 min

  Je ferme les commentaires, il est probable que je fasse un article dans les 10 jours.

  Tcho !

Les commentaires sont fermés.