web-dev-qa-db-fra.com

Quelle est la meilleure pratique pour formater les journaux?

J'écris un logiciel honeypot qui enregistrera de manière exhaustive les interactions, je compte enregistrer des fichiers en texte brut .log.

J'ai deux questions, de quelqu'un qui n'est pas trop familier avec la façon dont les serveurs se connectent.

  1. Premièrement, comment dois-je diviser mes fichiers journaux? Je suppose qu'après avoir exécuté ce programme pendant un mois, je ne veux pas d'un gros fichier .log. Est-ce que je le fais par jour, par mois et par année? Y at-il une norme pour cela?

  2. Le format de chaque ligne, est-ce que j'ai un séparateur standard qui est ce que vous voulez, *, -, +, quelque chose? Existe-t-il une norme n'importe où (ma recherche sur Google n'a pas beaucoup évolué)?

standardslogging
35
Andy Smith

J'aime ce format pour les fichiers de log:

$ python simple_logging_module.py
2005-03-19 15:10:26,618 - simple_example - DEBUG - debug message
2005-03-19 15:10:26,620 - simple_example - INFO - info message
2005-03-19 15:10:26,695 - simple_example - WARNING - warn message
2005-03-19 15:10:26,697 - simple_example - ERROR - error message
2005-03-19 15:10:26,773 - simple_example - CRITICAL - critical message

Cela provient du module logging de python . J'ai généralement un fichier par jour, un dossier par mois, un dossier par année. Vous obtiendrez d'énormes fichiers journaux que vous ne pourriez pas éditer correctement autrement.

logs/
  2009/
    January/
     01012009.log
     02012009.log
     ...
    February/
     ...
  2008/
   ...
20
Pierre-Antoine LaFayette

Il n'y a pas de standard pour une telle journalisation. Et le roulement, la disposition des fichiers, tout dépend de ce dont vous avez besoin. En général, j'ai été confronté à 3 scénarios principaux:

  • Tout en un fichier . Ne semble pas une option pour vous.
  • Rouleau de taille fixe . Vous définissez la taille lorsque le nouveau fichier journal est créé lorsque le fichier actuel est supérieur à la valeur définie. Il existe généralement une prise en charge immédiate pour cela dans la plupart des packages log4anything.
  • Total personnalisé roulant . J'ai vu des mises en page comme celle-ci
    • Chaque jour, son propre répertoire est nommé au format YYYYMMDD. Si vous ne mettez pas vos journaux en scène, considérez la structure du répertoire comme suit: AAAA\MM\AAAAMMJJ, comme indiqué dans les autres réponses.
    • Dans ce répertoire la taille fixe rolling devrait être utilisée.
    • Chaque fichier a pour nom logfile_yyyymmdd_ccc.log où ccc est un nombre croissant. Il est également judicieux d’ajouter du temps au nom du fichier (par exemple, pour juger facilement du nombre de journaux que vous générez par minute)
    • Pour économiser de l'espace, chaque journal est automatiquement compressé avec Zip.
    • Les 3 derniers jours sont toujours maintenus non compressés pour vous permettre un accès rapide aux outils de texte UNIX.

Cette coutume ressemblait à ceci

 logs /
 20090101 /
 logfile_20090101_001.Zip 
 logfile_20090101_002.Zip 
 ... 
 20090102 /
 logfile_20090102_001.Zip 
 logfile_20090102_002.Zip 
 logfile_20090101_001.log 
 logfile_20090101_002.log 
 logfile_20090102_001.log 
 logfile_200902

Il existe également quelques bonnes pratiques pour une bonne exploitation forestière:

  • Toujours conservez la date dans le nom de votre fichier journal
  • Toujours ajoute un nom à votre nom de fichier journal. Cela vous aidera dans l’avenir à distinguer les fichiers journaux de différentes instances de votre système.
  • Toujours log heure et date (de préférence, résolution en millisecondes) pour chaque événement de journal.
  • Toujours stockez votre date sous le nom AAAAMMJJ. Partout. Dans le nom du fichier, à l'intérieur du fichier journal. Cela aide grandement au tri. Certains séparateurs sont autorisés (par exemple, 2009-11-29).
  • En général, évitez de stocker les journaux dans la base de données. In est un autre point d'échec dans votre schéma de journalisation.
  • Si vous avez un système multithread, enregistrez toujours l'ID du thread.
  • Si vous avez un système multi-processus, enregistrez toujours l'ID de processus.
  • Si vous avez plusieurs ordinateurs, enregistrez toujours l'ID d'ordinateur.
  • Assurez-vous de pouvoir traiter les journaux ultérieurement. Essayez simplement d’importer un fichier journal dans la base de données ou Excel. Si cela prend plus de 30 secondes, cela signifie que votre journalisation est incorrecte. Ceci comprend:
    • Choisir un bon format de journalisation interne. Je préfère les espaces délimités, car cela fonctionne bien avec les outils de texte Unix et avec Excel.
    • Choisir le bon format pour la date/heure afin de pouvoir facilement importer dans une base de données SQL ou Excel pour un traitement ultérieur.
13
Michal Sznajder

Pour décomposer vos fichiers journaux, vous pouvez utiliser une application externe telle que logrotate et la laisser s’occuper du sale boulot.

En ce qui concerne le format de chaque ligne, il n'y a pas de standard, vous devez donc utiliser celui qui vous convient le mieux. Si vous souhaitez analyser automatiquement le fichier journal ultérieurement, gardez cela à l'esprit lorsque vous formatez la sortie du journal.

2
Jeff

Je vous recommande d'utiliser une bibliothèque de journalisation bien connue. La plupart des bibliothèques de journalisation prennent en charge le basculement pour vous. Log4Net (.net)/Log4J (Java) est une bibliothèque de journalisation particulièrement bonne à utiliser. Elle comporte de nombreuses options qui pourraient vous être utiles. Utilisez l'intervalle de survol qui vous convient le mieux. Pour une application pot de miel, je pense que vous trouverez le chiffre d’affaires horaire ou quotidien optimal. Vous pouvez également utiliser une limite fixe, telle que 256 Mo, pour vous assurer que vos efforts de journalisation ne surchargent pas l'espace disque disponible. Log4Net/Log4J le supporte également.

Log4J @ Apache.Org
Log4Net @ Apache.Org

Le format de vos fichiers journaux doit être configuré en fonction de vos besoins. Il est hautement souhaitable d’utiliser un délimiteur qui ne se présente probablement pas dans votre entrée de journal. Pour votre application, cela peut ne pas être possible. Dans des circonstances typiques, certaines parties utilisent des espaces (journaux NCSA), d'autres utilisent des virgules (pour créer des fichiers CSV), d'autres utilisent des tabulations (pour créer des fichiers délimités par des tabulations). Chacun de ceux-ci a ses propres avantages et inconvénients.

2
meklarian

Une suggestion:

C’est pour un système de pot de miel (et à moins que les méchants ne soient vraiment en train de frapper l’application/le site), vous pouvez pensez à prendre le temps supplémentaire nécessaire pour vous connecter à une base de données .

Cela facilitera l’analyse et l’utilisation des journaux en temps réel (c’est-à-dire que vous n’avez pas besoin de passer par le processus ETL avant d’analyser/parcourir les journaux.

Ceci étant dit, qu'il s'agisse de tables de base de données ou de fichiers, cela n'exclut pas la nécessité de définir un format . Provisoirement, vous pouvez avoir un format "polymorphe _", avec quelques attributs communs (ID, adresse IP, Horodatage, Cookie/ID, "niveau" [d'importance/urgence]) suivi d'un code mnémonique court. définir un type d’événement particulier (par exemple, "LIA" = tentative de connexion, "GURL" = adresse spécifiée, tentative d’injection SQL "SQLI", etc.) suivi de quelques champs numériques et de quelques champs de chaîne dont la sémantique varie le mnémonique. Résumer:

 - Id 
 - TimeStamp (peut être scindé en date et heure) 
 - IP_Address 
 - UserID_of_sorts 
 - // autres champs génériques/communs qui vous pouvez penser à 
 - EventCode (LIA, GURL, SQLI ...) 
 - Message Message texte (varie en fonction de l’événement, en particulier) 
 - Int1 // Numbers ... 
 - Int2 
 - Str1 // ... et le texte dont la signification varie avec EventCode 
 - Str2 
 - // ...?

Maintenant ... indépendamment du fait que vous alliez dans un fichier plat ou dans une base de données SQL (et peut-être surtout si vous utilisiez une base de données), vous pourriez/devriez utiliser une bibliothèque de journalisation standard . Peut-être que log4j comme suggéré dans d'autres réponses (même si je ne suis pas sûr qu'il y ait facilement des liaisons en Python, et de toute façon, le module de journalisation standard de Python est +/- identique…) ou même le Le module de journalisation de la bibliothèque standard de Python peut probablement être adapté à vos besoins.

1
mjv

À mon avis, le plus important est:

  • Commencer les enregistrements (lignes) avec la date/heure formatée après le Profil W3C de l’ISO 8601
  • Utiliser tab comme séparateur de champs dans les enregistrements
0
Hibou57