Suivre une action en échec dans une application auto-hébergée : relier les journaux
Cette liste de vérification propose une méthode à adapter à votre application pour examiner une action qui a échoué : identifiant de corrélation, horodatages, tâche en file d’attente et test contrôlé.
Cartographiez l’action avant de rechercher dans les journaux
Partez d’un échec visible et esquissez le parcours que son traitement a pu suivre. Une carte d’investigation possible comprend le proxy inverse, l’application, un processus de traitement en arrière-plan, la base de données et les dépendances externes concernées. Traitez cette carte comme une hypothèse à vérifier : votre application peut n’utiliser que certains de ces composants ou traiter les tâches autrement.
Pour chaque étape, notez quels journaux sont accessibles et quel événement pourrait indiquer que l’action est arrivée à destination ou a été menée à bien. Cette méthode est une proposition de travail à adapter à votre application et à vos outils, pas une garantie que chaque étape produira un journal exploitable.
- Notez l’action, l’heure approximative et le résultat attendu.
- Énumérez les composants susceptibles de la traiter, y compris tout processus en arrière-plan.
- Indiquez comment accéder aux journaux de chaque composant et si vos outils permettent de chercher par heure ou par champ.
- Signalez les lacunes : si les journaux d’un composant ne sont pas accessibles, ils ne pourront pas contribuer à cette investigation.
Choisissez un identifiant et vérifiez s’il est conservé
Un identifiant de requête ou de corrélation peut servir de valeur commune pour rechercher des événements associés. Ne présumez pas que chaque service l’accepte, le transmet ou l’enregistre : vérifiez la configuration et les journaux réels de chaque composant concerné.
Si une requête entrante comporte déjà un identifiant, vous pouvez vérifier s’il est possible de le conserver ou d’en créer un à une frontière que vous contrôlez. Examinez également la manière dont l’application traite une valeur fournie par le client avant de vous y fier. Le test proposé consiste à vérifier si la valeur choisie apparaît dans les enregistrements concernés, et non simplement si un paramètre existe.
- Envisagez un nom de champ et un format que les composants concernés peuvent enregistrer de façon cohérente.
- Vérifiez le proxy et l’application, puis les composants en aval qui font partie de votre parcours.
- Pour les composants que vous ne pouvez pas configurer, notez les autres éléments qui peuvent aider à circonscrire la recherche, comme une plage horaire ou un identifiant de tâche.
- Évitez d’utiliser des identifiants de connexion, des jetons ou des données personnelles comme identifiant de corrélation.
Examinez le parcours des tâches en file d’attente
Une action utilisateur peut se terminer côté web avant le démarrage ou la fin d’une tâche mise en file d’attente. Le journal de la requête ne montrera donc pas nécessairement, à lui seul, le résultat de cette tâche. Vérifiez dans votre application si une valeur de corrélation est transmise à la tâche et si le processus en arrière-plan l’enregistre au démarrage, à la fin ou lors d’un échec.
Si le système de tâches utilise son propre identifiant, recherchez si les journaux permettent de relier celui-ci à l’identifiant de requête ou de corrélation d’origine. Vérifiez ce comportement avec l’application et la configuration de file d’attente que vous utilisez : les possibilités et les noms de champs peuvent varier.
- Vérifiez si l’événement de mise en file d’attente contient un identifiant de tâche et un identifiant de corrélation.
- Cherchez si le processus en arrière-plan journalise le démarrage et le résultat de la même tâche.
- Si l’identifiant de corrélation n’est pas transmis, notez quel lien, le cas échéant, existe entre la requête et la tâche.
- Distinguez, à partir des éléments disponibles, une tâche qui ne semble pas avoir été mise en file d’attente d’une tâche mise en file d’attente dont le résultat n’est pas visible.
Rendez les horodatages et les champs comparables
Pour comparer des enregistrements, vérifiez le fuseau horaire utilisé par chaque service, si les horodatages indiquent leur fuseau et si les horloges semblent désynchronisées. Si les événements apparaissent dans un ordre inattendu, traitez cela comme une question à examiner : l’ordre affiché ne suffit pas toujours à établir la séquence réelle.
Des champs structurés peuvent faciliter le filtrage, selon les capacités de vos outils. La documentation de Datadog indique que, pour corréler les journaux avec les traces, ceux-ci doivent être au format JSON ou analysés par le processeur de journaux adapté au langage. Cette recommandation concerne la corrélation avec les traces ; pour une investigation fondée uniquement sur les journaux, vérifiez ce que vos propres outils savent rechercher.
- Vérifiez si les enregistrements pertinents contiennent un horodatage, le nom du service ou du composant, le niveau de gravité, le message et le champ de corrélation.
- Examinez les fuseaux indiqués et recherchez d’éventuels décalages entre les horloges des services.
- Si vos composants le permettent, utilisez un nom de champ stable pour la valeur de corrélation.
- Testez l’analyse des champs dans votre outil de consultation des journaux ; ne présumez pas qu’une valeur en texte non structuré est consultable comme un champ.
Effectuez un test d’échec contrôlé
Avant de vous appuyer sur cette méthode lors d’un incident, vous pouvez la tester avec une action à faible risque, dans un environnement contrôlé ou à un moment où le résultat peut être observé sans danger. Utilisez un identifiant connu et un échec identifiable. Évitez de provoquer un échec susceptible d’affecter des données importantes ou les opérations de l’entreprise.
Le test peut aider à déterminer si les journaux permettent de reconstituer une séquence utile : où l’action est entrée, quel composant l’a traitée, si du travail a été mis en file d’attente et où l’échec est devenu visible. Si la piste s’interrompt, consignez le transfert manquant et vérifiez si des journaux supplémentaires ou une autre source d’éléments pourraient être utiles.
- Choisissez une action de test dont le résultat d’échec est attendu et observable.
- Recherchez l’identifiant de corrélation choisi et comparez les enregistrements disponibles entre les composants.
- Vérifiez si le résultat du processus en arrière-plan peut être relié à l’action initiale.
- Notez les lacunes, les horodatages ambigus et les champs impossibles à rechercher.
Limitez les données recueillies dans les journaux
Les journaux utilisés pour examiner le comportement ou les échecs peuvent inclure des informations sensibles si l’application ou sa configuration les y inscrit. Comme précaution à valider pour votre application, examinez les champs présents dans les exemples réels et évitez d’y inscrire des identifiants de connexion, des jetons d’accès ou des données personnelles qui ne sont pas nécessaires à l’investigation.
Vous pouvez également examiner qui doit accéder aux journaux et combien de temps ils doivent rester disponibles pour vos besoins opérationnels. Ces choix dépendent de votre application, de vos risques et de vos exigences de gouvernance. Airbip gère l’infrastructure cloud des applications auto-hébergées et automatise le routage ainsi que les certificats TLS ; vérifiez séparément les modalités d’accès aux journaux et de conservation applicables à votre situation.
- Examinez des exemples réels de journaux avant d’élargir la collecte ou l’accès.
- Évaluez qui a besoin d’accéder aux journaux pour les activités opérationnelles ou de sécurité.
- Déterminez une durée de conservation adaptée à vos besoins et vérifiez les modalités effectivement appliquées.
- Revérifiez la journalisation après une modification de l’application ou de sa configuration.
Déterminez ce que les journaux permettent d’établir
Une piste de diagnostic corrélée peut aider à examiner le déroulement d’un échec, mais ne suffit pas nécessairement à établir qui a effectué une action ni à démontrer que l’enregistrement fait autorité. Si vos besoins de responsabilité ou de gouvernance exigent un relevé fiable des actions, déterminez, selon votre application et vos exigences, si des enregistrements d’audit distincts sont nécessaires.
Documentez les limites de la piste : composants dont les journaux ne sont pas accessibles, champs qui ne semblent pas être transmis, périodes sans couverture et événements qui ne peuvent pas être reliés avec certitude. Présentez le résultat comme une reconstitution fondée sur les éléments disponibles, et non comme une chronologie complète si ces éléments sont incomplets.
- Utilisez les journaux disponibles pour examiner le comportement et les échecs, en tenant compte de leurs limites.
- Évaluez si des enregistrements distincts sont nécessaires pour vos besoins de responsabilité ou de gouvernance.
- Consignez les lacunes connues et évitez de présenter une chronologie incomplète comme exhaustive.
- Répétez le test contrôlé lorsque des composants importants ou les modalités de journalisation changent.
Questions fréquentes
Tous les services ont-ils besoin du traçage distribué pour relier les journaux d’une action en échec ?
Non. Cette liste de vérification propose d’examiner si des événements de journal peuvent être reliés à l’aide d’un identifiant et comparés entre les composants. Elle ne suppose pas que chaque service prend en charge le traçage distribué. Vérifiez ce que chaque composant enregistre réellement et consignez les lacunes.
Que faire si une tâche en file d’attente ne contient pas l’identifiant de requête d’origine ?
Vérifiez si l’événement de mise en file d’attente contient un identifiant de tâche et si le processus en arrière-plan enregistre ce même identifiant. S’il n’existe pas de lien visible avec la requête initiale, notez cette lacune et vérifiez si la configuration de l’application ou des tâches peut permettre d’en enregistrer un.
Les journaux d’application doivent-ils être au format JSON ?
Cela dépend de votre usage et de vos outils. Pour la corrélation des journaux avec les traces, la documentation de Datadog indique que les journaux doivent être au format JSON ou analysés par le processeur de journaux adapté au langage. Pour une recherche dans les journaux seuls, vérifiez ce que vos outils peuvent analyser et rechercher.
Les journaux de diagnostic sont-ils équivalents aux enregistrements d’audit ?
Ne présumez pas qu’ils répondent aux mêmes besoins. Si vous avez besoin d’un relevé des actions pour la responsabilité ou la gouvernance, déterminez, selon votre application et vos exigences, quels enregistrements sont appropriés et s’ils doivent être distincts des journaux utilisés pour le diagnostic.
Une infrastructure gérée règle-t-elle l’accès aux journaux et leur conservation ?
Ne le présumez pas. Vérifiez les modalités applicables à votre application et à votre hébergement, notamment qui peut accéder aux journaux et combien de temps ils sont conservés. Une infrastructure gérée ne permet pas, à elle seule, de conclure que ces modalités correspondent à vos besoins de données et de gouvernance.
Sources et lectures complémentaires
- Correlate Logs and Traces — Datadog
- Application logs and agent traces in one view — Braintrust