Analyseur de fichiers journaux

Les fichiers journaux bruts sont des murs de timestamps, niveaux et messages en texte libre. Collez un journal d’accès Nginx, un journal d’erreurs Apache, un dump syslog ou un fichier de canal Laravel et l’analyseur le divise en lignes structurées, vous permettant de filtrer par plage de dates ISO, gravité (DEBUG à EMERGENCY), IP client ou regex contre le message, et met en évidence les correspondances pour que vous puissiez réellement voir ce qui s’est passé dans la fenêtre d’incident.

Comment analyser un fichier journal

  1. 1

    Collez le contenu du journal

    Déposez le texte brut du journal. Les formats courants (combiné, commun, syslog, JSON-lines) sont détectés automatiquement.

  2. 2

    Définir le filtre de date

    Utilisez un timestamp de début/fin pour zoomer sur la fenêtre d'incident.

  3. 3

    Filtrer par niveau ou IP

    Cochez les niveaux de gravité, tapez une IP ou entrez un motif regex pour faire correspondre les messages.

  4. 4

    Lire le tableau

    Chaque ligne montre le timestamp, le niveau, la source et le message avec les segments correspondants mis en évidence.

Formats reconnus par l’analyseur

Format Exemple Source
Nginx combiné 1.2.3.4 - - [18/Apr/2026:10:00:00 +0000] "GET / HTTP/1.1" 200 1234 journaux d’accès web
Apache commun Même que ci-dessus sans Referer et User-Agent stacks LAMP classiques
Syslog RFC 5424 <34>1 2026-04-18T10:00:00Z hôte app - ID47 - msg démons système Linux
Laravel quotidien [2026-04-18 10:00:00] production.ERROR: message canal de journal Laravel
JSON lines {"ts":"...","level":"ERROR","msg":"..."} journaux structurés, Loki, ELK

Niveaux de journal standard

Classés du plus bruyant au plus silencieux. La plupart des applications suivent l’ordre syslog / PSR-3 :

  1. EMERGENCY, système inutilisable.
  2. ALERT, action immédiate requise.
  3. CRITICAL, condition critique, par ex. base de données hors service.
  4. ERROR, erreur d’exécution à enquêter.
  5. WARNING, condition exceptionnelle, pas une erreur.
  6. NOTICE, événement normal mais significatif.
  7. INFO, messages opérationnels généraux.
  8. DEBUG, diagnostic de bas niveau, bruyant en production.

Conseils de filtrage

  • Réduisez d’abord par date. La plupart des journaux de production sont énormes ; réduire à la fenêtre d’incident rend chaque autre filtre rapide.
  • Utilisez regex pour les messages. Rechercher timeout|connection refused|5\d\d attrape la plupart des échecs réseau en un seul passage.
  • Isolez une IP. Lors de l’enquête sur un client suspect, filtrez tout le reste et lisez leurs demandes chronologiquement.
  • Excluez les robots. Les sous-chaînes User-Agent comme bot, crawl, spider filtrent la plupart du bruit des enquêtes de style analytique.

Remarques sur la performance

  • L’analyseur fonctionne côté client, donc les lignes restent sur votre machine. Cela signifie également que les fichiers très volumineux (plus de 100 Mo) ralentiront le navigateur, divisez-les d’abord avec split -l ou diffusez-les via un outil côté serveur.

Questions fréquentes

Non. L’analyse et le filtrage se font dans votre navigateur. Le journal que vous collez ne quitte jamais votre appareil, ce qui est important pour les fichiers pouvant contenir des IP, des jetons ou des PII.

Oui, les lignes qui commencent par un espace ou at ... sont attachées à l’entrée de journal précédente, donc une pile d’exception complète reste dans une seule ligne.

Utilisez le filtre regex contre la colonne message. Pour les journaux JSON structurés, toutes les clés sont recherchables en texte brut dans le message.

Pas directement, décompressez d’abord avec gunzip ou un outil de fichier et collez le texte brut. L’analyseur s’attend à des lignes de journal non compressées.

Il n’y a pas de limite stricte, mais tout ce qui dépasse 10 Mo peut ralentir le filtrage. Pour les grandes archives, utilisez grep sur le serveur d’abord et collez la sortie filtrée ici.

Outils similaires

Outil disponible dans d’autres langues