Modifier

Partager via

Journalisation dans Gridwich

Azure

Les meilleures pratiques de journalisation sont les suivantes :

  • N’utilisez pas la mise en forme ou l’interpolation de chaîne. La journalisation d’une chaîne avec $"This broke {brokenThing}" n’est pas utile pour le débogage.

  • Transmettez des objets de façon à ce qu’ils deviennent des champs pouvant faire l’objet d’une recherche.

    Au lieu de LogInformation(LogEventIds.StartProcessing, $"Processing has started on item {Item.itemNumber}");, utilisez :

    • Un objet en tant que tel, comme LogInformationObject(LogEventIds.StartProcessing, Item);, ou
    • Des objets anonymes, comme LogInformationObject(LogEventIds.StartProcessing, new {Item.itemNumber, Item.itemDescription, someData});.

  • Suivez les conventions de numérotation d’ID d’événement décrites dans LogEventIds.

  • Pour toute tâche significative, utilisez le modèle de journalisation suivant :

    • Utilisez LogInformationObject en entrée, par exemple lors du démarrage d’un travail d’encodage.
    • Utilisez LogInformationObject en cas de réussite, par exemple lorsque la tâche d’encodage est réussie.
    • Utilisez LogWarningObject, LogErrorObject ou LogCriticalObject en cas d’échec, par exemple en cas d’échec du travail d’encodage. Utilisez des variantes de méthode d’exception, le cas échéant.

  • Même si vous pouvez journaliser des informations à tout moment, ne polluez pas les journaux avec des détails superflus.

ObjectLogger

ObjectLogger avec IObjectLogger est un petit utilitaire wrapper pour le Logger/ILogger standard. Cet utilitaire à une ligne journalise les objets C# en convertissant des objets C# en objets dictionnaire que l’enregistreur d’événements peut consommer.

ObjectLogger/IObjectLogger restreint l’utilisation des méthodes de journalisation qui n’ont pas de EventIds à l’aide d’un modèle d’adaptateur, plutôt que l’héritage. Cette restriction oblige les développeurs à utiliser des EventIds, qui sont utiles pour le débogage.

Voici d’autres recommandations relatives à l’utilisation de ObjectLogger :

  • Ne contournez pas IObjectLogger à l’aide de ILogger.
  • Utilisez IObjectLogger avec le type approprié pour votre classe : IObjectLogger<myClass>.
  • Dans tout bloc catch de gestion des exceptions, utilisez les méthodes IObjectLogger qui incluent des exceptions. Les fournisseurs de journalisation comme Application Insights peuvent utiliser les informations sur les exceptions.

Schéma et données de journalisation

L’infrastructure d’exécution Event Grid sous-jacente fournit un schéma de base. Le schéma d’événements Event Grid inclut l’heure de l’événement, l’appareil d’origine, le niveau de gravité et le message de type chaîne. Les propriétés personnalisées par défaut Logger/ILogger incluent EventId, Category et RequestPath.

Objets de contexte

Pour travailler avec des API et des workflows complexes qui requièrent plusieurs entrées et sorties, vous pouvez créer un objet de contexte, qui est un jeu de propriétés de variables importantes que votre code peut transmettre ou générer. Les objets de contexte peuvent gérer de nombreux paramètres, et les signatures de méthode n’ont pas besoin d’être modifiées lorsque vous ajoutez ou supprimez des paramètres. Vous pouvez également passer des objets de contexte à l’enregistreur d’événements et d’autres interfaces en tant qu’unité.

Par exemple, à la place de :

var store = new StorageBlob();
var tier = req.Query["tier"];
var result = await store.SetBlobStorageTier(blobName, tier);
logger.LogInformationObject(LogEventIds.setBlobProperties, result);

Vous pouvez coder :

var storageContext = new StorageContext();
storageContext.Store = new StorageBlob();
storageContext.Tier = req.Query["tier"];
storageContext.Result = await store.SetBlobStorageTier(blobName, storageContext.Tier);
logger.LogInformationObject(LogEventIds.setBlobProperties, storageContext);

Niveaux de journal

L’attribution du niveau de journalisation approprié peut être complexe. Les descriptions générales suivantes des niveaux de journal proviennent de l’énumération LogLevel.

LogLevel Enum Description
LogTrace 0 Contient les messages les plus détaillés et peut contenir des données d’application sensibles. Ces messages sont désactivés par défaut et ne doivent pas être activés dans un environnement de production.
LogDebug 1 Utilisé pour une investigation interactive pendant le développement. Ce type de journal contient principalement des informations qui sont utiles pour le débogage et n’ont pas de valeur à long terme.
LogInformation 2 Effectue le suivi du flux général de l’application. Ils ont généralement une utilité à long terme.
LogWarning 3 Met en évidence un événement anormal ou inattendu dans le workflow de l’application, mais n’arrête pas l’exécution de l’application.
LogError 4 Journalise lorsque le déroulement actuel de l’exécution est arrêté en raison d’un échec. Ces journaux doivent indiquer un échec dans l’activité en cours, et non un échec sur l’ensemble de l’application.
LogCritical 5 Décrit une panne irrécupérable de l’application ou du système, ou une défaillance catastrophique nécessitant une attention immédiate.
LogNone 6 Ils ne sont pas utilisés pour écrire des messages de journal. Spécifie qu’une catégorie de journalisation ne doit écrire aucun message.

Étapes suivantes

Documentation du produit :

Modules Microsoft Learn :