Conseils et bonnes pratiques d’applications Logging

Nous supposons que, à mesure que des aspects tels que la sécurité et les tests doivent être pris en compte pendant l’ensemble. cycle de vie du projet, de ses origines à son achèvement. Qui ne sont pas des exigences non fonctionnelles non fonctionnelles ou secondaires, sinon sont des priorités dans le cadre de la structure fondamentale de l’applicateur (ce n’était pas tellement de fonctionnalités ou de mécanismes conçus et mis en œuvre l’achèvement du projet comme un ajout , s’ils avaient été terminés). Cependant, la trace d’application, qui a toujours fait du mérite n’a pas reçu dans de nombreux cas la même considération; – p.

Dans ce poste, je ne pense pas que je découvre rien de nouveau à ceux qui ont une expérience de développement . L’idée est d’exercer une synthèse et un examen pour résumer ce que, à mon avis, sont les meilleures ou les meilleures pratiques du journal des applications. Bien entendu, les contributions, les observations, les nuances et la critique sont les bienvenues. Je vous invite à rejoindre cet exercice.

Le journal ou la trace d’application est le traitement et le stockage des informations concernant l’exécution d’une application. Il contient des données d’entités, de modifications d’état et de composants logiciels impliqués dans cette exécution. Sa fonctionnalité principale est de faciliter la surveillance ou l’analyse de l’exécution de l’application:

• analyser le comportement de l’application lors de la phase de développement et de débogage (tests de boîte blanche)
• Analyser les bugs ou les erreurs d’exécution détectées, leurs causes et conséquences
• servent d’enregistrement d’audit lorsque les informations contenues et le mode dans lequel il a été traité répond à la mesure requise
• la performance ou le chargement de systèmes ou d’applications
• inverser l’état de la demande suivant dans l’ordre inverse, le journal

Cela dépend des circonstances dans lesquelles nous nous trouvons, le Le deuxième des utilisations est généralement le plus pertinent. Un bon journal développé correctement dans le code et entretenu ou configuré en fonctionnement est une garantie de réponse rapide pour l’analyse des erreurs; qui pourrait même être fait sans la nécessité d’arrêter l’application, de la reconfigurer ou d’appliquer tout changement.

La trace de l’application est généralement formée par un ensemble d’événements stockés séquentiellement, généralement dans l’ordre dans lequel ils arriver, persistant ou récupérable. Ils peuvent être stockés dans des fichiers, en BBDD, dans les composants distribués à cet effet … Les mécanismes de rotation ou d’historisation peuvent être activés, ils peuvent être utilisés par des moniteurs pour lancer des alertes, ils peuvent être intégrés et fusionnés pour faire des analyses plus exhaustives. . Le pertinent est que les informations enregistrées et la manière dont il est réussi à être utile.

Il existe de nombreuses solutions et propositions de logiciels, à la fois gratuites et les plus complètes, plus ou moins standardisées, plus simples ou plus complètes. types et formulaires. L’important est de rechercher cela correspond à nos besoins et à nos environnements, d’oublier complètement la mise en œuvre du mécanisme; et coller aux deux aspects les plus importants:

• Le contenu de chaque enregistrement ou événement, la principale préoccupation du développeur
• la manière dont elle est traitée, persiste et Gère, la principale préoccupation de l’exploitation du système ou de l’applicateur

Le coût de la mise en œuvre de la journalisation est dans l’IR, tout en développant la trace à différents points du code. Cette activité devrait être effectuée pendant le développement, à la suite des schémas, des critères et des procédures préétablies. De cette manière, les développeurs auront des critères communs et la trace sera cohérente entre les différentes parties du code.

La trace et la documentation du code peuvent avoir des points communs en termes de philosophie, d’objectifs et de Mode d’application, mais il y a une différence importante entre les deux: tandis que la documentation du code passe dans la raison pour laquelle quelque chose se fait de cette façon, la trace doit couvrir ce qui est fait. En définissant un exemple, dans une boucle, la documentation du code doit indiquer pourquoi les limites ou les conditions de sortie sont telles et que le registre de trace pendant l’exécution à quel point ladite condition de sortie a été remplie.

Informations enregistrées dans le Trace doit être pertinent et complet. Vous pouvez envisager les aspects suivants lorsque vous décidez quelles informations incluent:

• Quoi:
  • Quel événement ou quel action est arrivé.
  • Quelles entités ont impliqué.
  • S’il y a un changement de statut, quel était le précédent? Quel est le nouvel état?
• Où:
  • à quel moment du code a eu lieu: composant, classement, fichier de code, bloc de code ou d’exécution, ligne de code … Comment Beaucoup plus détaillé est que ces informations sont mieux pour localiser le lieu d’erreur possible ou où l’exécution est passée, d’une part; Mais plus peut affecter la journalisation des performances (les informations de débogage peuvent être nécessaires) et la conclusion d’informations de trace, de l’autre.
• Quand:
  • Enregistrement du temporaire moment, absolument ou lié au début de l’exécution ou à tout autre événement.
  • générant une trace séquentielle ou causale, dans laquelle les événements qui se produisent plus tôt dans le temps ou font que d’autres, apparaissent auparavant.
• dans quel contexte:
  • Inscription des états ou des variables: exécuter elle-même (paramètres), personnalisation ou spécifique à l’utilisateur, référent de la session ou de la transaction …
  • indiquant des brins, des transactions ou des demandes connexes lorsque nous sommes dans des environnements simultanés.

pour les informations de trace est plus détaillée au moment de l’analyse et Plus gérables pendant l’exploitation de celui-ci, des niveaux de filtrage sont établis. De manière à ce que seuls les événements soient montrés ou stockés avec un niveau supérieur ou égal au niveau de suivi établi. Les bibliothèques de journalisation permettent aux événements de filtrer les événements par d’autres critères tels que la classe ou le contexte de l’événement.

Les niveaux les plus courants sont le débogage, les informations, l’avertissement et l’erreur. La classification des différents événements à chaque niveau fait partie de l’exercice d’analyse et devrait viser au fait que la trace est lisible et utile dans les différents contextes de l’application, du développement à l’exploitation.

Ceci peut être un exemple de sémantique des niveaux de journalisation:

• débogage, pour des informations de niveau très basse utiles pour le débogage de l’application, tant dans le développement que dans l’analyse des incidents
  • Appels appels vers des fonctions et des procédures et d’autres composants, avec des paramètres et des réponses
  • exécution de flux
  • développement d’algorithmes et de procédures qui vous permettent d’identifier et de suivre son exécution de développement
• info, informations de niveau supérieur qui permet de surveiller l’exécution normale
  • stops et arrêts de services et de systèmes
  • paramètres critiques ou de configuration pertinente
  • Démarrage et fin des transactions et des opérations complètes
  • changements de Statut des opérations
• avertissement, informations de situations, qui toujours sans erreur, si elle est anormale ou non prévue, bien que l’application ait des alternatives à les résoudre
  • pas paramètres définis et dont la valeur est prise par défaut
  • situations anormales, mais qui sont résolues par l’application, laissant l’opération dans un état correct
  • fonctionnalités non primordiales ou essentielles, que Ils ne peuvent pas être résolus, mais ils laissent l’opération dans un état correct

error, des informations de situations erronées et qui empêchent l’exécution correcte d’une opération ou d’une transaction, mais sans affecter d’autres opérations ou transactions (erreur isolée ou contenu)

• aucune opération ou transaction n’a pu être effectuée, mais cela n’affecte pas les autres demandes
• ou des requêtes erronées (stockant les paramètres de Entrée)
• fonctionnalités générales de l’application, qui affecte toujours le fonctionnement général de l’application Ivo, ne sont pas considérés comme primordiaux ou essentiels
• fatal, des informations d’erreur des situations d’erreur qui affectent le fonctionnement général de l’application (erreurs non isolées ou contenu dans la portée)
  • Paramètres non définis ou paramètres erronés
  • manque de connexion ou de communication avec d’autres composants
  • Erreurs d’exécution pouvant affecter les opérations ou les transactions indépendantes, ou qui affectent le fonctionnement général de l’application

Le contenu et la forme de chaque événement de journal, tels que la sémantique des niveaux faisant partie de la conception de l’application. Ces critères doivent être définis et communiqués à l’équipe de développement pour appliquer de manière homogène et cohérente tout au long du développement. Si ces critères sont convenus avec l’équipement, vous pouvez obtenir beaucoup d’avantage de l’expérience du développeur.

Autres recommandations à prendre en compte sont les suivants:

• enregistrer des événements d’une manière Atomique, que toutes les informations concernant un événement sont stockées dans un enregistrement ou une ligne.
• guide le format des informations montrées à utiliser de manière informatisée ou automatique avec des outils spécifiques.
• En ce qui concerne les exceptions:
  • affiche toujours la trace complète de l’exception avec votre message et toute la stacktrace.
  • Si l’exception est capturée, traitée et ensuite jetée à nouveau (bien le même ou l’autre) ne laissez pas de trace de l’exception jusqu’à ce qu’elle soit capturée et finalement. De cette manière, chaque exception ne sera affichée qu’une seule fois. Si nous ne le faisons pas de cette façon et que vous enregistrez chaque capture et relancez apparaîtra dans la trace plusieurs fois et nous ne saurons pas si c’est la même chose ou qu’il en est plusieurs. (Jet d’attaque d’antipatron).
  • Utilisez la preuve d’exception causée ou interne lorsque nous capturons et accueillons l’exception. En Java, il s’agit de la méthode GetCouse (), dans .NET la propriété InnerException.

• Utilisez des mécanismes MDC / NDC (informations de contexte) Pour les environnements de threads multiples ou de zones de transaction. Ces informations peuvent nous permettre de filtrer ou de spécifier les informations de journal dans un contexte commercial spécifique telle que les clients, les utilisateurs, les produits …
• implémenter la méthode Tostring () de toutes les classes d’entreprise ou des pics pour faciliter votre traceado.
• Vous devez prendre en compte les différences et des fuseaux horaires lorsque vous travaillez avec des journaux de diverses machines ou composants.
• la journalisation ne peut pas avoir d’effets secondaires, vous ne pouvez pas modifier le statut de tout paramètre, variable ou procédure. Cela montre uniquement des informations. Il doit être léger, la journalisation elle-même peut ne pas nécessiter une transformation longue ou coûteuse.
• Les appels à des méthodes, composants et composants distribués externes, doivent être enregistrés après l’appel, y compris les paramètres d’entrée et de réponse, ainsi que de la classe. / Composant et méthode, au niveau du débogage. Et à l’erreur et au niveau fatal lorsqu’une erreur se produit dans l’appel (si une exception doit être la trace, les paramètres d’entrée et d’exception)

Un message d’accueil,

Juan Francisco ADAME LORITE