La journalisation structurée, semi-structurée et non structurée est un concept générique qui englobe trois notions distinctes, présentant chacune leurs propres avantages et défis. Les logs semi-structurés et non structurés peuvent être facilement consultés par l’homme, mais peuvent être difficiles à extraire pour les machines. Les logs structurés sont, quant à eux, faciles à analyser par un système de gestion des logs, mais difficilement exploitables en l’absence d’un tel outil.

Qu’est-ce que la journalisation structurée ?

La journalisation structurée est le processus qui consiste à formater les données de log afin de faciliter leur recherche, leur filtrage et leur traitement en vue d’une analyse plus approfondie. Le format standard utilisé pour la journalisation structurée est JSON, même si d’autres formats sont possibles. La meilleure pratique consiste à utiliser un cadre de journalisation pouvant s’intégrer à une solution de gestion des logs prenant en charge les champs personnalisés.

Journalisation structurée, semi-structurée et non structurée : quelle différence ?

Les logs non structurés sont des fichiers texte massifs constitués de chaînes, c’est-à-dire de séquences ordonnées de caractères conçues pour être lues par l’homme. Dans les logs, ces chaînes contiennent des variables, c’est-à-dire des emplacements réservés (en anglais, placeholder) à des attributs définis ailleurs. Une variable peut, par exemple, prendre la forme d’un métacaractère (en anglais, wildcard), c’est-à-dire un emplacement réservé représentant un attribut inconnu, comme au poker.

unstructured_data = ["Unstructured message","Hello Python World",str(datetime.now(timezone("EST")).isoformat())]

Ces variables sont facilement comprises par l’homme, mais ce n’est pas toujours le cas pour les machines. Ces dernières ne sont pas toujours en mesure de faire la différence entre une variable contenue dans une chaîne et une séquence similaire de caractères ailleurs dans le log. Dans ce cas, les résultats produits peuvent porter à confusion, avec pour conséquence une baisse de la productivité, une augmentation de la faillibilité et le gaspillage d’heures-personnes et de cycles de traitement.

Les logs structurés se composent d’objets plutôt que de chaînes. Un objet peut inclure des variables, une structure de données, des méthodes et des fonctions. Par exemple, un objet faisant partie d’un message de log peut inclure des informations concernant une application ou une plateforme. L’entreprise peut définir les critères à inclure dans l’objet de façon à ce que les logs répondent au mieux à ses besoins spécifiques. C’est ce qui constitue la « structure » d’un log structuré.

Voici un exemple de log structuré :

structured_data = [
 {
          "tags": {
               "host": "str(ip)",
               "host_name": "str(host)",
               "filename": "str(caller.filename)",
               "line": "str(caller.lineno)",
               "error_level": "INFO"
          },
          "events": [
               {
                    "timestamp": str(datetime.now(timezone("EST")).isoformat()), #.strftime("%Y-%m-%d %H:%M:%S %Z"),
                    "attributes": {
                         "message": "Structured message",
                    }
               }
          ]
     }
 ]

Comme les logs structurés sont conçus pour être lus par des machines, celles-ci peuvent y effectuer des recherches plus rapidement, produire des résultats plus clairs et assurer la cohérence entre plusieurs plateformes. Les logs structurés peuvent également être lus par l’homme, mais ce n’est pas le but premier. La fonction de l’homme est d’exploiter la sortie une fois que la machine a terminé de traiter les données.

Les logs semi-structurés, qui se composent à la fois de chaînes et d’objets, peuvent être lus tant par les machines que par l’homme. Avant de pouvoir être analysés correctement, ces logs doivent généralement être exportés sous la forme de tableaux. À l’heure actuelle, les logs semi-structurés ne sont pas encore normalisés, ce qui veut dire que certains programmes et systèmes ne sont pas encore totalement en mesure de les identifier et de les catégoriser. Par exemple, les règles d’utilisation de guillemets pour définir la valeur d’un espace ne sont à ce stade pas encore définies de manière universelle. La solution Falcon LogScale de CrowdStrike possède une longueur d’avance en la matière, puisqu’elle peut s’adapter aux logs semi-structurés de votre environnement.

Pourquoi utiliser la journalisation structurée ?

Trouver un événement dans un log non structuré n’est pas chose aisée, car une simple requête renvoie bien plus d’informations que souhaité et pas toujours celles recherchées. Prenons un exemple : un développeur recherche un événement de log qui a été créé au moment où une application spécifique a dépassé le quota du disque d’un certain seuil. Un log non structuré risque de renvoyer au développeur tous les événements correspondant à un dépassement du quota du disque créés par toutes les applications. À l’échelle d’une entreprise, cela représente un fichier particulièrement volumineux.

Pour trouver l’événement recherché, le développeur devra écrire une expression régulière complexe afin de préciser la recherche. Et plus l’événement est spécifique, plus l’expression sera complexe. Cette approche est gourmande en puissance de calcul, car les conditions définies dans l’expression doivent être comparées à chaque valeur de ligne du log. La consommation de puissance de calcul sera d’autant plus grande si des métacaractères sont utilisés. Et si les données de log sont modifiées, l’expression risque de ne pas produire les résultats escomptés.

Dans certaines entreprises, les développeurs écrivent le code sous la forme de chaînes, tandis que les équipes chargées des opérations l’écrivent en réorganisant ces chaînes en données structurées. Cela demande plus de temps et de puissance de calcul. De plus, si le développeur ou l’équipe chargée des opérations commet une erreur, le processus de journalisation sera rompu, provoquant une nouvelle perte de temps pour identifier la source de l’erreur.

La journalisation structurée permet d’éviter ces aléas, car elle structure les données à mesure qu’elles sont créées. L’entreprise peut choisir le format qui lui convient le mieux : colonne fixe, paires clé-valeur, JSON, etc. La plupart des entreprises modernes utilisent le format JSON, car il s’intègre bien aux systèmes d’automatisation, notamment les systèmes d’alerte.

Les logs au format texte continuent d’avoir leur place au sein des entreprises, étant donné que la journalisation structurée n’est pas sans inconvénients. Les logs structurés définissent les données à mesure qu’elles sont créées, limitant leur utilisation aux seules fins prévues par cette définition. De plus, si les données structurées sont stockées sur site ou dans un entrepôt de données dans un schéma de données rigide, toute modification de ce schéma nécessitera une mise à jour des données structurées, ce qui représente une tâche colossale et onéreuse. Au moment de choisir une stratégie de journalisation, l’entreprise doit prendre en compte plusieurs facteurs : qui utilisera les données, quels seront les types de données collectés, où et comment les données seront-elles stockées, et les données doivent-elles être préparées avant d’être stockées ou peuvent-elles être préparées au moment de leur utilisation.

Falcon LogScale prend en charge les logs structurés, semi-structurés et non structurés

Une entreprise ne pourra pleinement tirer parti des avantages de la journalisation structurée que si elle dispose d’un système de gestion des logs flexible et évolutif, qui répond à ses besoins spécifiques de développement, de conformité et de sécurité.

La solution Falcon LogScale de CrowdStrike prend en charge les logs non structurés, semi-structurés et structurés dans n’importe quel format, et est compatible avec les principaux expéditeurs de données open source. Les analyseurs personnalisés facilitent la prise en charge de tout format de texte, rendant l’intégration de Falcon LogScale simple et rapide.

La plupart des utilisateurs envoient des données structurées à Falcon LogScale sous forme d’objets JSON. Ceux-ci ne requièrent aucun formatage particulier, ils doivent juste être valides. L’horodatage peut être envoyé en tant qu’élément de l’entrée de log, auquel cas la solution Falcon LogScale utilisera celui-ci plutôt que d’appliquer son propre horodatage. Lors de l’envoi de données non structurées, l’horodatage est généré au moment de l’ingestion sous la forme d’une longue chaîne délimitée par des virgules et n’a aucun impact sur l’horodatage de l’ingestion.

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