Ce qu'il faut enregistrer du côté de l'application et jusqu'où
Bonjour, je suis Otsuka, CTO chez Liberogic.
La fois précédente, nous avons comparé les fonctionnalités de journalisation entre les services comme AWS, Cloudflare, Vercel, Supabase et les headless CMS.
Chaque service propose des journaux d'exécution, des journaux d'erreurs, des enregistrements d'opérations administratives, etc.
Si nous combinons tous ces journaux, disposons-nous de tous les journaux nécessaires pour un service web ?
Malheureusement, ce n'est pas si simple.
C'est parce que les journaux qu'un service cloud enregistre automatiquement sont différents de ceux que nous devons enregistrer nous-mêmes du côté de l'application.
Cette fois, nous allons examiner comment concevoir les journaux dans un vrai service web et mettre les choses en ordre du point de vue pratique.
Ce qu'on ne peut pas savoir avec les journaux du côté du service
Si vous utilisez Cloudflare Workers ou Vercel Functions, les résultats d'exécution et les erreurs de traitement sont enregistrés automatiquement dans une certaine mesure.
Avec Supabase, vous pouvez consulter les journaux de la base de données, de l'authentification, de l'API et bien d'autres.
Cependant, le service ne peut observer que ce qui se passe au sein de ce service lui-même.
Éléments automatiquement conservés | Éléments enregistrés côté application |
|---|---|
Exécution de Worker ou Function | Réception des demandes de contact |
Exceptions ou erreurs de traitement | Modifications des informations de membre |
Réponse de l'API | Modification des autorisations |
Connexion à la base de données | Succès ou échec de l'envoi d'e-mail |
Opérations de gestion de l'environnement cloud | Détection de spam ou rejet pour raisons professionnelles |
Par exemple, même si vous savez que l'écriture dans la base de données a réussi, vous ne pouvez pas savoir si c'était pour « accepter une demande de contact » ou « modifier les informations de membre ».
Ces événements commerciaux doivent être enregistrés avec du contexte du côté de l'application.
Il ne faut pas tout enregistrer dans les journaux
Il peut être tentant de consigner autant d'informations que possible dans les journaux pour se préparer aux investigations.
Cependant, plus il y a de journaux, mieux ce n'est pas nécessairement.
L'enregistrement détaillé de tous les traitements fait que les informations vraiment nécessaires se perdent. À mesure que le volume de journaux augmente, les coûts de stockage et de recherche augmentent également.
Pour cette raison, nous concevons nos journaux en gardant à l'esprit les « limites » du traitement.
Par exemple, dans le cas d'un formulaire de contact,
- la soumission a réussi
- le contenu saisi a été rejeté en raison d'un problème
- il a été rejeté en raison d'une détection de spam
- l'enregistrement en base de données a échoué
- l'envoi du courrier de notification a échoué
comme autant de points où le résultat du traitement change et qui doivent être enregistrés.
Au lieu de conserver chaque variable intermédiaire et chaque détail du traitement, l'idée est de sélectionner les événements qui sont nécessaires pour reconstituer ultérieurement l'historique.
Les journaux doivent être conservés comme des données, et non comme du texte.
Il est plus pratique d'inclure dans les journaux des informations consultables ultérieurement plutôt que de simplement écrire « une erreur s'est produite ».
Élément | Rôle |
|---|---|
Date et heure de l'événement | Vérifier quand l'événement s'est produit |
Nom de l'événement | Classer le traitement auquel l'événement s'est produit |
Niveau de gravité | Distinguer les succès, avertissements et échecs |
ID cible | Identifier les données concernées |
ID de requête | Suivre une série de traitements |
Temps de traitement | Vérifier les délais et les dégradations de performance |
L'enregistrement de ces éléments dans un format standardisé s'appelle journalisation structurée.
En normalisant les éléments dans un format comme JSON, les recherches deviennent plus faciles, par exemple « afficher uniquement les traitements liés à un ID de candidature spécifique » ou « extraire uniquement les envois d'e-mail en erreur ».
Ne pas écrire d'informations personnelles dans les journaux
Lors de la conservation des journaux de formulaires de contact, il arrive que le nom, l'adresse e-mail et le contenu de la demande soient enregistrés.
Bien que cela puisse sembler pratique pour l'investigation, cette conception doit être évitée.
À écrire dans les journaux | À ne pas écrire dans les journaux |
|---|---|
Date et heure de traitement | Mot de passe |
Nom de l'événement | Jeton d'accès |
Réussite/Échec | Cookie |
Identifiant des données concernées | Corps du message de contact |
ID de requête | Informations de carte de crédit |
Temps de traitement | Informations personnelles inutiles |
Les journaux peuvent être transférés vers plusieurs services ou conservés longtemps. S'ils contiennent des informations personnelles ou des informations d'authentification, le journal lui-même peut devenir une source de nouvelle fuite de données.
Les données métier comme le contenu des demandes de contact doivent être sauvegardées dans une base de données, et seul l'identifiant permettant d'identifier la demande et le fait que la réception a réussi doivent être enregistrés dans le journal.
Lorsque le besoin se manifeste, cet ID est utilisé pour croiser les informations avec la base de données.
Réfléchir au formulaire de contact
Les formulaires de contact présentent souvent une structure qui envoie simplement un email de notification.
Cependant, même si le traitement d'envoi de l'email réussit, le message n'est pas garanti d'arriver au destinataire.
C'est pourquoi il est plus prudent de d'abord enregistrer le contenu du contact dans la base de données et de traiter l'email comme une simple notification pour le responsable.
Avec cette structure, on peut distinguer si « le contact lui-même n'a pas été reçu » ou si « le contact a été enregistré mais seul l'email de notification a échoué ».
Ces petites différences subtiles sont très importantes dans la gestion réelle des contacts.
Séparer la recherche à court terme de l'archivage à long terme
Dans les investigations quotidiennes de problèmes, il est important de pouvoir rechercher rapidement les journaux récents.
En revanche, pour les journaux destinés à l'audit ou à l'investigation d'incidents, il est important de pouvoir les récupérer des mois ou des années plus tard, même s'ils ne sont presque jamais consultés au quotidien.
Destination de stockage | Objectif principal |
|---|---|
Écrans de journal de chaque service | Vérification opérationnelle récente |
Services de gestion des journaux tels que Datadog | Recherche transversale, surveillance, notifications |
R2 ou S3 | Conservation à long terme des preuves |
Placer les éléments nécessaires pour les investigations récentes dans un endroit facile à consulter, et transférer les preuves à long terme vers une destination de stockage économique.
C'est simple, mais en pratique, cette distinction s'avère très efficace.
Les journaux et les tableaux de bord sont des choses différentes
Si vous avez des journaux, vous pouvez penser que vous comprenez tout, comme le nombre d'accès ou le taux d'erreur.
Cependant, les valeurs affichées dans les journaux et le tableau de bord jouent des rôles légèrement différents.
- Journaux : examiner en détail chaque événement individuel
- Métriques : agréger les nombres, les ratios, les temps de traitement, etc.
- Tableau de bord : comprendre les tendances globales du système
Effectuez les vérifications d'état quotidiennes via le tableau de bord, et si une anomalie est détectée, enquêtez en détail dans les journaux.
En combinant ces deux approches, votre exploitation devient plus facile.
Éléments à définir au minimum
Pour finir, voici un récapitulatif des points à vérifier lors de la conception des journaux.
- Événements à enregistrer
- Éléments à inclure dans le journal
- Exclusion des données personnelles et des informations d'authentification
- Période pendant laquelle les journaux récents peuvent être recherchés
- Étendue des journaux à conserver à long terme
- Destination de stockage des journaux à long terme
- Responsables pouvant consulter les journaux
- Méthode de suppression des journaux après expiration de la période de conservation
Lorsque vous entendez parler de journaux d'audit, vous pourriez avoir l'impression que vous devez enregistrer toutes les opérations et mettre en place une infrastructure de gestion des journaux de grande envergure.
En revanche, pour un site web ordinaire ou un site médias, vous pouvez commencer par définir les opérations et résultats de traitement importants, puis séparer la recherche à court terme de la conservation à long terme.
L'important n'est pas d'énumérer les fonctionnalités de journalisation des services utilisés, mais de vérifier que l'ensemble du système conserve les enregistrements nécessaires.
Que conserver ?
Pourquoi conserver ?
Pendant combien de temps conserver ?
En clarifiant ces trois points, vous pouvez concevoir une architecture de journalisation adaptée à votre projet sans la surcharger inutilement.
Les journaux ne sont généralement pas très visibles.
Mais la capacité à expliquer « ce qui s'est passé » lorsque quelque chose survient est déterminée par la conception initiale.
C'est vraiment important de bien construire ces fondamentaux solides.
Bon, à bientôt.
Le pilier du département technique de Liberogic. Dès qu'il entend « J'aimerais bien avoir ça, ce serait pratique », il se met au travail avec sa créativité naturelle et ajoute de la valeur en un rien de temps. Avec ses excellentes compétences en communication et ses nombreux fans parmi nos clients, c'est un trésor de l'entreprise — et passionné par les chats.
Shō Ōtsuka
Directeur technique / Ingénieur en chef / Représentant de Neko-Ana LLC / Étonnamment jeune d'apparence