Les logs sont une composante essentielle de tout système informatique et facilitent l’ensemble des opérations suivantes :

• Surveillance des performances des infrastructures
• Détection des bugs des applications
• Analyse des causes sous-jacentes
• Enquête sur les incidents de sécurité
• Suivi du comportement des utilisateurs
• Etc.

L’exploitation optimale des logs nécessite de disposer d’un système de gestion des logs robuste et à même de prendre en charge les divers formats (structurés ou non) dans lesquels ces fichiers se présentent.

Une solution de gestion des logs bien conçue est capable d’ingérer, d’analyser et de stocker les logs, quel que soit leur format. Il devient ainsi possible de rechercher, d’analyser et de mettre en corrélation les données provenant de différents systèmes afin de dégager des tendances, de créer des tableaux de bord et même de déclencher des alertes pour améliorer les processus métier.

Dans cet article, nous examinerons les formats de log en général, avant de nous attarder sur certains formats couramment utilisés par les systèmes informatiques.

Brève introduction aux formats des logs

Le format d’un log définit la manière dont son contenu doit être interprété. En règle générale, le format indique :

• Si le contenu du log est structuré ou non
• Si les données sont en texte brut ou en binaire
• Le type de codage utilisé
• Comment les enregistrements sont délimités

Les formats de log peuvent également définir les champs contenus dans ces fichiers et les types de données associés. Par exemple, name=text ou age=number. Les champs spéciaux, comme les horodatages, adoptent généralement des formats prédéfinis (tels que le format ISO 8601, qui se présentera de la manière suivante : 2022-07-10 15:21:00.000).

En général, les applications définissent les formats de logs qu’elles prennent en charge, avec parfois la possibilité pour l’utilisateur de choisir entre diverses options (par exemple, JSON et CSV). Dans le cas des terminaux physiques, les fabricants définissent généralement les types de logs à utiliser.

Logs structurés, semi-structurés et non structurés

Les logs se présentent sous la forme de fichiers structurés, semi-structurés et non structurés.

Les logs structurés suivent un schéma clair et cohérent, et sont lisibles par les humains et les machines. Les champs sont parfois séparés par un caractère tel qu’une virgule (comme dans les fichiers CSV), un espace ou un trait d’union. Il arrive aussi qu’ils soient reliés par un signe égal (=) (par exemple, name=Jane ou city=Paris).

La plupart des systèmes de gestion des logs sont dotés d’analyseurs préconfigurés et peuvent facilement ingérer les logs structurés, dont voici un exemple :

[{
  "Env" : "Prod",
  "ServerName" : "LAPTOP123",
  "AppName" : "Console1.vmhost.exe",
  "AppLoc" : "C:\Test\stackify-api-dotnet\dst\ConsoleApplication1\bin\Debug\Console1.vmhost.exe",
  "Logger" : "StackifyLib.net",
  "Msgs" : [{
    "Msg" : "Incoming metrics data",
    "data" : "{"clientid":12345}",
    "EpochMs" : 1445345672470,
    "Level" : "INFO",
    "id" : "0c12301b-e4ge-11e6-8933-897567896a4"
  }]
}]

Les logs non structurés ne suivent aucun schéma particulier, mais restent facilement lisibles par les humains. Cette absence de structure complique le découpage des événements et l’extraction de paires clé-valeur. Si aucun analyseur n’est intégré au système de gestion des logs, les logs non structurés nécessiteront une analyse personnalisée, ce qui entraîne souvent un surcroît de travail pour les ingénieurs.

2018-10-25 11:56:35,008 INFO  [LAPTOP321-1-3]  c.a.c.d.RFC4519DirectoryMembershipsIterable Found 7 children for 7 groups in 2 ms
Starting process to remove.
Process started.
Process completed.

Les logs semi-structurés sont facilement lisibles par l’humain et présentent un schéma ou une configuration qui leur permet d’être lus par des machines. Leurs séparateurs de champs et d’événements sont plus complexes que la virgule ou le signe égal, mais ces logs restent malgré tout organisés selon un schéma particulier. Ces logs peuvent être ingérés par les systèmes de gestion des logs, mais cela nécessite généralement de passer par un analyseur pour séparer les différents événements et extraire les paires clé-valeur. Ces tâches sont généralement réalisées à l’aide d’expressions régulières ou de code annexe.

Formats de log courants

Bien que les formats de log varient considérablement d’un système, d’une application et d’un outil à l’autre, certains d’entre eux sont couramment utilisés. Penchons-nous sur les principaux.

JSON

JavaScript Object Notation (JSON) est l’un des formats de log les plus couramment utilisés. Les logs JSON sont semi-structurés et contiennent plusieurs paires clé-valeur. Ce format permet d’imbriquer les données dans différentes couches tout en conservant une présentation lisible par l’humain. Il permet en outre de préserver les types de données, comme les chaînes de caractères, les nombres, les variables booléennes, les valeurs null/empty, les objets ou les tableaux.

Étant relativement récent, JSON utilise généralement le codage UTF-8 pour les données au repos et en transit, ce qui le rend accessible aux systèmes d’exploitation *nix et Windows. Il n’existe aucune restriction quant à la quantité ou au type de champs pouvant être inclus. Ce format fonctionne bien avec les bases de données NoSQL (ou sans schéma), mais peut nécessiter un travail supplémentaire de la part de l’auteur du log pour assurer la cohérence des types de champs entre les applications et les sources de log.

Voici un exemple de log JSON :

{
  "timestamp": "2022-07-29T02:03:45.293Z",
  "message": "User Jane.Doe has logged in",
  "log": {
    "level": "info",
    "file": "auth.c",
    "line": 66,
  },
  "user": {
    "name": "jane.doe",
    "id": 235
  },
  "event": {
    "success": true
  }
}

Logs d’événements Windows

Les logs d’événements Windows contiennent des données relatives aux événements qui se produisent au sein du système d’exploitation Windows. Ils couvrent notamment les événements relatifs à la sécurité, aux applications, au système et au DNS, et adoptent tous le même format.

Les logs d’événements Windows sont souvent utilisés par les administrateurs système pour résoudre les erreurs système ou d’applications, enquêter sur les incidents de sécurité ou suivre les connexions des utilisateurs. Ils sont généralement très détaillés et contiennent des informations telles que l’horodatage, l’identifiant de l’événement, le nom d’utilisateur, le nom d’hôte, des messages et la catégorie de tâche.

Voici un exemple de log d’événements Windows :

An account was successfully logged on.

Subject:
    Security ID: SYSTEM
    Account Name: DESKTOP-LLHJ389$
    Account Domain: WORKGROUP
    Logon ID: 0x3E7

Logon Information:
    Logon Type: 7
    Restricted Admin Mode: -
    Virtual Account: No
    Elevated Token: No

Impersonation Level: Impersonation

New Logon:
    Security ID: AzureAD\RandyFranklinSmith
    Account Name: [email protected]
    Account Domain: AzureAD
    Logon ID: 0xFD5113F
    Linked Logon ID: 0xFD5112A
    Network Account Name: -
    Network Account Domain: -
    Logon GUID: {00000000-0000-0000-0000-000000000000}

Process Information:
    Process ID: 0x30c
    Process Name: C:\Windows\System32\lsass.exe

Network Information:
    Workstation Name: DESKTOP-LLHJ389
    Source Network Address: -
    Source Port: -

Detailed Authentication Information:
    Logon Process: Negotiate
    Authentication Package: Negotiate
    Transited Services: -
    Package Name (NTLM only): -
    Key Length: 0

CEF

Common Event Format (CEF) est un format de log texte ouvert utilisé par les terminaux et les applications de sécurité. Développé par ArcSight Enterprise Security Manager, le format CEF est utilisé par les systèmes SIEM et de gestion des logs pour la collecte et l’agrégation de données.

Codés en UTF-8, les logs CEF comprennent un préfixe commun, un en-tête CEF, ainsi qu’une extension variable contenant une liste de paires clé-valeur.

Le préfixe contient l’horodatage de l’événement et le nom d’hôte. L’en-tête inclut la version du logiciel CEF, le fournisseur du terminal, le terminal utilisé, sa version, l’identifiant de la catégorie d’événement, le nom de l’événement et sa gravité. Le reste du log comprend des champs personnalisés supplémentaires destinés à l’enrichir.

Voici un exemple d’entrée au format CEF :

CEF:0|Trend Micro|Deep Security Manager|<DSM version>|600|User Signed In|3|src=10.52.116.160 suser=admin target=admin msg=User signed in from 2001:db8::5

Le format NCSA Common Log Format (CLF) est l’un des plus anciens formats de log utilisés par les serveurs web. Ce log texte standardisé présente un format fixe, ce qui signifie que vous ne pouvez pas personnaliser les champs. Chacune de ses lignes contient les informations suivantes :

• Adresse de l’hôte distant
• Nom de la connexion à distance
• Nom de l’utilisateur
• Horodatage
• Requête et version du protocole
• Code d’état HTTP
• Octets envoyés

Le trait d’union est utilisé pour un champ qui ne contient pas de données pour l’événement, tandis que le signe plus (+) représente des caractères non pris en charge.

Voici un exemple de log CLF :

127.0.0.1 - frank [10/Oct/2000:13:55:36 -0700] "GET /apache_pb.gif HTTP/1.0" 200 2326

ELF

Le format ELF (Extended Log Format) est utilisé par les applications web. Semblable au format CLF, il contient toutefois plus d’informations et présente davantage de flexibilité au niveau des champs utilisés. Les logs ELF ne contiennent les données que d’une seule transaction HTTP. Les champs sont séparés par un espace, tandis que le trait d’union indique un champ manquant.

La première partie des logs ELF contient des informations sur la version, la date, l’heure, le logiciel et tout commentaire pertinent. Ces éléments sont précédés du symbole dièse (#). Le log contient également des noms de champs, ce qui facilite considérablement l’analyse par les gestionnaires de logs.

W3C

Le format de log W3C Extended Log File, hautement personnalisable, est utilisé par les serveurs Windows IIS. Vous pouvez configurer les champs à inclure de façon à ne conserver que les informations pertinentes et à réduire la taille des fichiers. Les champs disponibles sont les suivants :

• Horodatage
• Adresse IP du client
• Adresse IP du serveur
• URI demandée
• Code d’état HTTP
• Octets envoyés
• Octets reçus
• Durée de l’opération
• Version

Certains champs incluent les préfixes s (serveur), c (client), sc (action du serveur vers le client) ou cs (action du client vers le serveur), qui précisent s’ils sont liés au serveur ou au client.

Voici un exemple de log W3C :

#Software: Internet Information Services 6.0 
#Version: 1.0 
#Date: 2001-05-02 17:42:15 
#Fields: time c-ip cs-method cs-uri-stem sc-status cs-version 
17:42:15 172.16.255.255 GET /default.htm 200 HTTP/1.0

Journalisez toutes vos données et répondez à toutes les questions – gratuitement

Falcon LogScale Community Edition (anciennement Humio) offre une plateforme moderne et gratuite de gestion des logs pour le cloud. Exploitez l’ingestion des données de streaming pour bénéficier d’une visibilité instantanée sur les systèmes distribués, de même que détecter et résoudre les incidents.

Falcon LogScale Community Edition, disponible instantanément et gratuitement, inclut les fonctionnalités suivantes :

• Ingestion de jusqu’à 16 Go de données par jour
• Durée de rétention de 7 jours
• Aucune carte de crédit n’est requise
• Accès continu sans période d’essai
• Journalisation sans index, alertes en temps réel et tableaux de bord en direct
• Accès à notre place de marché et à nos packages, y compris aux guides de création de nouveaux packages
• Formation et collaboration avec une communauté active

Démarrer gratuitement