Share via


Suivi et propagation d'activité pour la corrélation de suivi de bout en bout

Cette rubrique décrit comment utiliser le suivi et la propagation d'activité à des fins de débogage.

Vue d'ensemble du suivi d'activité

Windows Communication Foundation (WCF) fournit des fonctionnalités d'instrumentation permettant de dépanner les applications sans utiliser de débogueur. Le diagnostic WCF inclut quatre composants : événements, suivi, qui inclut le suivi d'activité et la journalisation des messages.

Fonctionnalités de diagnostic Utilisateurs cibles Objectif

Événements

Professionnels de l'informatique

Afficher les erreurs critiques qui se sont produites dans le système

Suivi

Professionnels de l'informatique et développeurs

Afficher à la fois des événements positifs et négatifs dans le système, à différents niveaux de commentaires, afin de diagnostiquer un problème ou vérifier le comportement approprié.

Journalisation des messages

Professionnels de l'informatique et développeurs

Afficher les journaux de messages réels qui traversent le câble ou/et sont distribués au code utilisateur, afin de diagnostiquer un problème ou vérifier le comportement approprié

Suivi d'activité (sous-ensemble de la fonctionnalité de suivi)

Professionnels de l'informatique et développeurs

Bénéficier de la corrélation de suivi pour localiser la cause première d'une erreur.

Cette rubrique présente le suivi d'activité qui fournit une corrélation de suivi aux utilisateurs afin de leur permettre de diagnostiquer la cause première d'une erreur. WCF fournit trois mécanismes de corrélation : activités, propagation et transferts.

Activités

Les activités traitent des unités permettant à l'utilisateur de réduire la portée d'un échec. Les erreurs qui se produisent dans la même activité sont directement liées. Par exemple, une opération échoue en raison de l'échec du déchiffrement d'un message. Les suivis pour l'opération et l'échec de déchiffrement du message apparaissent dans la même activité, en affichant la corrélation directe entre l'erreur de déchiffrement et l'erreur de demande. WCF fournit des activités prédéfinies pour traiter les applications. Vous pouvez également définir des activités par programme pour grouper des suivis utilisateur.

Pour émettre des suivis d'activité au moment de l'exécution, utilisez le paramètre ActivityTracing de System.ServiceModel ou d'autres sources de suivi personnalisées, tel qu'indiqué par le code de configuration suivant.

<source name="System.ServiceModel" switchValue="Verbose,ActivityTracing">

Pour plus d'informations sur l'élément de configuration et les attributs utilisés, consultez la rubrique « Configuration du suivi ».

Vous pouvez activer le suivi d'activité sur n'importe quelle source de suivi, dont WCF ou des sources définies par l'utilisateur.

Vous pouvez définir une activité dans le code utilisateur (à l'aide de System.Diagnostics) avant que tout traitement WCF ne commence. Une activité de ce type est appelée « activité ambiante ».

Vous pouvez afficher les activités et leur utilité dans Service Trace Viewer Tool. Cet outil prend les suivis et les trie en fonction de l'activité. Lorsque ActivityTracing est activé, vous pouvez également consulter des transferts de suivi. Un transfert de suivi indique de quelle manière les différentes activités sont liées les unes par rapport aux autres. Vous pouvez voir qu'une activité spécifique a provoqué le démarrage d'une autre. Par exemple, une demande de message a démarré une négociation de sécurité pour obtenir un jeton de conversation sécurisée. Pour plus d'informations, et pour consulter une vue graphique de l'outil Service Trace Viewer, consultez Service Trace Viewer Tool et Utilisation de Service Trace Viewer pour afficher les suivis corrélés et résoudre les problèmes.

Propagation

La propagation fournit à l'utilisateur la corrélation directe de suivi d'erreur pour la même unité de traitement sur des points de terminaison d'application, par exemple, une demande. Les erreurs émises à différents points de terminaison pour la même unité de traitement (par exemple, une demande) sont regroupées dans la même activité, et même sur des domaines d'application. Cette opération s'effectue par la propagation de l'ID d'activité dans les en-têtes de message. Par conséquent, en cas d'expiration d'un client en raison d'une erreur interne dans le serveur, les deux erreurs apparaissent dans la même activité pour une corrélation directe.

Pour ce faire, utilisez le paramètre ActivityTracing, tel qu'indiqué dans l'exemple précédent. Définissez également l'attribut propagateActivity pour la source de suivi System.ServiceModel.

<source name="System.ServiceModel" switchValue="Verbose,ActivityTracing" propagateActivity=”true” >

La propagation d'activité est une fonction configurable qui entraîne l'ajout par WCF d'un en-tête aux messages sortants, et qui inclut l'ID d'activité sur le stockage local des threads. En incluant ces informations dans les suivis ultérieurs sur le côté serveur, il est possible de mettre en corrélation les activités de client et de serveur.

Transferts

Les transferts entre activités représentent des liens de causalité entre événements dans les activités connexes dans des points de terminaison. Deux activités sont associées à des transferts lorsqu'un contrôle circule entre ces activités, par exemple, un appel de méthode qui traverse des limites d'activité. Dans WCF, lorsque des octets entrent sur le service, l'activité Écouter est transférée à l'activité Recevoir des octets où l'objet de message est créé.

Pour émettre des suivis de transfert, utilisez le paramètre ActivityTracing sur la source de suivi tel qu'indiqué dans l'exemple précédent.

Pour obtenir une liste de scénarios de suivi de bout en bout, et leur conception d'activité et de suivi respective, consultez Scénarios de suivi de bout en bout.

Modèle de suivi E2E

Cette section fournit des définitions pour les activités et leurs limites, la corrélation d'activité sur les points de terminaison via la propagation, et dans les points de terminaison via les transferts, et le profilage d'activité. Elle fournit également un résumé de tous les types de suivis d'activité et indique comment les regrouper afin de former une séquence de suivis valide.

Activités

Définition et portée

Une activité a un identificateur local et global. Elle est définie au moment de la conception et désigne une unité de travail logique. Les suivis émis avec le même identificateur d'activité sont directement liés, ils font partie de la même activité. Une activité pouvant traverser des limites de point de terminaison (par exemple, une demande), deux portées sont donc définies.

  • Portée globale, par application. Dans cette portée, l'activité est identifiée par son identificateur d'activité global unique 128 bits (gAId). Le gAid correspond à ce qui est propagé sur des points de terminaison.
  • Portée locale, par processus et source de suivi. Dans le cadre de cette portée, les activités sont identifiées à l'aide de leur identificateur gAId, du nom de la source de suivi émettant leurs suivis et de l'ID de processus. Ce trio constitue l'ID local d'activité, appelé lAId. Le lAId est utilisé pour définir les limites (locales) d'une activité.

Une activité est identifiée localement à une source de suivi par le triplet lAId={ProcessId, TraceSourceName, gAId} et globalement dans l'application par son gAId.

Schéma

Les suivis peuvent être émis à l'aide de schémas et, sur l'ensemble des plateformes Microsoft, un schéma commun connu sous le nom de schéma « e2e » (pour la «End to End »)" est utilisé. Ce schéma inclut un identificateur 128 bits (identificateur d'activité) qui est unique dans le processus et la source de suivi, le nom de source de suivi et l'ID de processus. L'identificateur d'activité (AID) permet la corrélation des suivis émis. Cela est dû au fait que les suivis émis avec la même AID sont directement liés, car ils font partie de la même activité. Dans le code managé, XmlWriterTraceListener émet des suivis dans le schéma E2E.

Les développeurs peuvent définir l'AID émis avec un suivi en définissant la propriété ActivityId avec un Guid sur le stockage local des threads. C'est ce que montre l'exemple suivant.

// set the current Activity ID to a new GUID.
CorrelationManager.ActivityId = Guid.NewGuid();

La définition du gAId dans le stockage local des threads sera évidente lorsque les suivis seront émis à l'aide d'une source de suivi, tel que l'indique l'exemple suivant.

TraceSource traceSource = new TraceSource("myTraceSource");
traceSource.TraceEvent(TraceEventType.Warning, eventId, "Information");

Le suivi émis contiendra le gAId actuellement dans le stockage local des threads, le nom de source de suivi passé comme paramètre au constructeur de la source de suivi, et l'ID du processus actuel.

Corrélation d'activités dans Service Trace Viewer

L'outil Service Trace Viewer fournit deux vues des activités qui sont les suivantes.

  • La vue Liste, dans laquelle le gAId permet de corréler directement des suivis sur des processus et sources de suivi. Les suivis provenant de différentes sources, par exemple le client et le service, mais ayant le même gAId sont regroupés dans la même activité. Par conséquent, si une erreur se produit sur le service et provoque ensuite une erreur sur le client, les deux erreurs s'afficheront dans la même vue d'activité de l'outil.
  • Vue Graphique, dans laquelle les activités sont regroupées par processus. Dans cette vue, un client et un service ayant le même gAId, mais un lAId différent (parce qu'ils sont dans deux processus différents), auront leurs suivis dans des activités différentes. Pour corréler des activités ayant le même gAId dans des processus différents, l'outil affiche les flux de messages sur les activités connexes.

Durée de vie des activités

  • Suivi de début : signale le début des activités. Un suivi « Démarrer » fournit un enregistrement du début d'un nouveau jalon de traitement. Il contient toujours un nouveau AID pour une source de suivi spécifiée dans un processus donné, sauf lorsque l'ID d'activité est propagé sur des points de terminaison qui utilisent le même nom de source de suivi (par exemple, System.ServiceModel) et s'exécutent dans le même processus. Les exemples de démarrage d'une nouvelle activité incluent la création d'un thread permettant de traiter ou d'entrer une nouvelle méthode publique.
  • Suivi de fin : signale la fin des activités. Un suivi « Arrêter » fournit un enregistrement de fin d'un jalon de traitement existant. Il contient toujours un nouveau AID pour une source de suivi spécifiée dans un processus donné, sauf lorsque l'ID d'activité est propagé sur des points de terminaison qui utilisent le même nom de source de suivi (par exemple, System.ServiceModel) et s'exécutent dans le même processus. Les exemples d'arrêt d'une activité incluent l'arrêt d'un thread de traitement ou la sortie d'une méthode dont le début a été désigné par un suivi « Démarrer ».
  • Suivi d'interruption : signale l'interruption d'une activité. Un suivi « Interrompre » contient un AID existant dont le traitement est supposé reprendre ultérieurement. Aucun suivi n'est émis avec cet AID entre les événements d'interruption et de reprise de la source de suivi actuelle. Les exemples incluent l'interruption d'une activité lors de l'appel dans une fonction de bibliothèque externe ou lors de l'attente d'une ressource telle qu'un port de terminaison d'E/S.
  • Suivi de reprise : signale la reprise d'une activité. Un suivi « Reprendre » contient un AID existant dont le dernier suivi provenant de la source de suivi actuelle était un suivi « Interrompre ». Les exemples incluent le retour d'un appel vers une fonction de bibliothèque externe ou lors du signalement de la reprise du traitement par une ressource telle qu'un port de terminaison d'E/S.
  • Suivi de transfert : certaines activités pouvant être initiées par d'autres, les suivis de transfert permettent de relier ces activités entre elles. Un transfert enregistre la relation dirigée d'une activité vers une autre

Instructions relatives à l'utilisation du suivi d'activité

La section suivante fournit des instructions sur l'utilisation des suivis ActivityTracing (Démarrer, Arrêter, Interrompre, Reprendre et Transfert).

  • Le suivi est un graphique cyclique dirigé, et non pas une arborescence. Vous pouvez retourner le contrôle à une activité qui a généré une activité, tel qu'indiqué dans l'exemple précédent.
  • Une activité désigne une limite de traitement qui peut être explicite pour l'administrateur du système ou pour la supportabilité.
  • Chaque méthode WCF, à la fois sur le client et le serveur, est liée en commençant une nouvelle activité, puis (une fois que le travail est effectué) en terminant la nouvelle activité et en retournant à l'activité ambiante.
  • Les activités longues (continues) telles qu'écouter des connexions ou attendre des messages sont représentées par des marqueurs démarrage/arrêt correspondants.
  • Les activités déclenchées par la réception ou le traitement d'un message sont représentées par les limites de suivi.
  • Les activités représentent des activités, et non pas des objets. Une activité doit être interprétée comme suit : « cela était en train de se produire lorsque. . . (l'émission de suivi explicite s'est produite) ».

Utilisation des suivis Démarrer et Arrêter pour marquer les limites d'activité

Dans les termes les plus stricts, la preuve d'une activité commence la première fois que le lAId est utilisé dans un suivi émis, et se termine la dernière fois que le lAId est utilisé dans un suivi émis.

La vie d'une activité commence la première fois que le lAId est utilisé dans un suivi émis, et se termine la dernière fois que le lAId est utilisé dans un suivi émis. Un ensemble prédéfini de types de suivis est fourni par System.Diagnostics, qui utilise deux types de suivis (Démarrer et Arrêter) pour marquer explicitement les limites d'activité.

Démarrer - début d'une activité

Un suivi « Démarrer » fournit un enregistrement du début d'un nouveau jalon de traitement. Il contient toujours un nouveau lAId pour une source de suivi spécifiée dans un processus donné, sauf lorsque l'ID d'activité est propagé sur des points de terminaison qui utilisent le même nom de source de suivi (par exemple, System.ServiceModel) et s'exécutent dans le même processus. Ou lorsque le même gAId est propagé plusieurs fois sur les mêmes points de terminaison (par exemple, l'activité Configurer la sécurité WCF). La dernière opération n'est recommandée que si les demandes sont synchrones et séquentielles. Dans ce cas, un suivi Démarrer (et Arrêter) ayant le même gAId pour chaque point de terminaison s'affichera. Consultez la section « Propagation » pour plus d'informations sur la propagation. WCF a défini le nom de l'activité via le suivi Démarrer.

Les exemples de démarrage d'une nouvelle activité incluent la création d'un thread permettant de traiter ou d'entrer une nouvelle méthode publique.

Arrêter - fin d'une activité.

Un suivi « Arrêter » fournit un enregistrement de fin d'un jalon de traitement existant. Il contient toujours un lAId qui n'apparaîtra plus pour une source de suivi spécifiée dans un processus donné, sauf lorsque l'ID d'activité est propagé sur des points de terminaison qui utilisent le même nom de source de suivi (par exemple, System.ServiceModel) et s'exécutent dans le même processus. Ou lorsque le même gAId est propagé plusieurs fois sur les mêmes points de terminaison (par exemple, l'activité WCF Set Up Security). La dernière opération n'est recommandée que si les demandes sont synchrones et séquentielles. Dans ce cas, un suivi Démarrer (et Arrêter) ayant le même gAId pour chaque point de terminaison s'affichera. Consultez la section « Propagation » pour plus d'informations sur la propagation.

  • Les exemples d'arrêt d'une activité incluent l'arrêt d'un thread de traitement ou la sortie d'une méthode dont le début a été désigné par un suivi « Démarrer ».

Si le gAId est propagé sur des points de terminaison pour la corrélation, il y aura un suivi Démarrer et Arrêter avec ce gAId à partir de chaque source de suivi.

Utilisation des suivis Démarrer et Arrêter

Les suivis Démarrer et Arrêter ne sont pas critiques pour la corrélation. Toutefois, ils peuvent améliorer les performances, le profilage et la validation de la portée de l'activité.

À l'aide de ces types, les outils peuvent optimiser la navigation des journaux de suivi afin de rechercher les événements immédiatement associés de la même activité, ou des événements dans les activités connexes si l'outil suit les suivis de transfert. Par exemple, les outils cesseront d'analyser les journaux pour une activité donnée lorsqu'ils verront un suivi Démarrer/Arrêter.

Les outils utilisent le lAId comme identificateur d'activité, mais peuvent utiliser le gAId pour identifier des activités connexes sur des fichiers chargés.

Ces types de suivis peuvent également être utilisés pour le profilage. Les ressources consommées entre les marqueurs de démarrage et d'arrêt représentent le temps inclusif de l'activité, dont les activités logiques contenues. La soustraction des intervalles de temps entre les suivis Interrompre et Reprendre fournit le temps d'activité réelle.

Le suivi Arrêter est particulièrement utile pour valider la portée des activités implémentées. Si certains suivis de traitement apparaissent après le suivi Arrêter au lieu d'apparaître dans une activité donnée, cela peut suggérer une erreur de code.

Les suivis Démarrer et Arrêter sont émis si l'attribut ActivityTracing est défini pour la source de suivi.

Utilisation de la propagation pour corréler des activités sur des points de terminaison

Une activité fournit une corrélation directe pour les suivis qui sont liés à la même unité de traitement localement à une source de suivi. Dans WCF, pour lier des suivis faisant partie de la même unité logique de traitement sur des points de terminaison, par exemple une demande, le gAId est propagé. Une fois corrélés, les suivis provenant d'activités ayant le même gAId dans les points de terminaison distincts peuvent être fusionnés dans la même activité.

Le gAId de l'activité M est propagé à l'activité N si toutes les conditions suivantes sont vérifiées.

  • N est créé à cause de M
  • Le gAId de M est connu de N
  • Le gAId de N est égal au gAId de M.

Le gAId est propagé par l'en-tête de message ActivityId, tel qu'indiqué dans le schéma XML suivant.

<xsd:element name=”ActivityId” type=”integer” minOccurs=”0”>
  <xsd:attribute name=”CorrelationId” type=”integer” minOccurs=”0”/>
</xsd:element>

Exemple d'en-tête de message :

<MessageLogTraceRecord>
  <s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope"   
                      xmlns:a="http://www.w3.org/2005/08/addressing">
    <s:Header>
      <a:Action s:mustUnderstand="1">http://Microsoft.ServiceModel.Samples/ICalculator/Subtract
      </a:Action>
      <a:MessageID>urn:uuid:f0091eae-d339-4c7e-9408-ece34602f1ce
      </a:MessageID>
      <ActivityId CorrelationId="f94c6af1-7d5d-4295-b693-4670a8a0ce34" 
                          
               xmlns="https://schemas.microsoft.com/2004/09/ServiceModel/Diagnostics">
        17f59a29-b435-4a15-bf7b-642ffc40eac8
      </ActivityId>
      <a:ReplyTo>
          <a:Address>http://www.w3.org/2005/08/addressing/anonymous
          </a:Address>
      </a:ReplyTo>
      <a:To s:mustUnderstand="1">net.tcp://localhost/servicemodelsamples/service</a:To>
   </s:Header>
   <s:Body>
     <Subtract xmlns="http://Microsoft.ServiceModel.Samples">
       <n1>145</n1>
       <n2>76.54</n2>
     </Subtract>
   </s:Body>
  </s:Envelope>
</MessageLogTraceRecord>

Limites de propagation et d'activité

Dans System.ServiceModel, l'ID d'activité est propagé sur des points de terminaison si l'utilisateur définit propagateActivity=true dans la configuration sur les deux côtés.

Lorsque l'ID d'activité est propagé sur des points de terminaison, le récepteur de message émet un suivi de démarrage et d'arrêt avec cet ID d'activité (propagé). Par conséquent, il y a un suivi de démarrage et d'arrêt avec ce gAId à partir de chaque source de suivi. Si les points de terminaison sont dans le même processus et utilisent le même nom de source de suivi, plusieurs suivis Démarrer et Arrêter ayant le même lAId (gAId identique, source de suivi et processus identiques) sont créés.

Synchronisation

Vous pouvez activer la synchronisation de suivis de point de terminaison sur des ordinateurs en définissant l'attribut Correlation de ActivityId dans l'en-tête de message.

Pour synchroniser des événements sur les points de terminaison qui s'exécutent sur des ordinateurs différents, CorrelationId est ajouté à l'en-tête ActivityId propagé dans les messages. Les outils peuvent utiliser cet ID pour synchroniser des événements sur des ordinateurs présentant des différences d'horloge. En particulier, l'outil Service Trace Viewer utilise cet ID pour afficher les flux de messages d'un point de terminaison à un autre.

Utilisation du suivi Transfert pour corréler des activités dans des points de terminaison

Un suivi de transfert est émis de l'activité M vers l'activité N, lorsqu'il existe un flux de contrôle entre M et N. Par exemple, N exécute une tâche pour M à cause d'un appel de méthode franchissant les limites des activités.

N existe peut-être déjà ou a été créé. N est généré par M lorsque N est une nouvelle activité qui exécute une tâche pour M.

Un transfert de M à N peut pas être suivi d'un transfert réciproque de N à M. Cela est dû au fait que M peut générer une tâche dans N sans assurer le suivi de l'exécution de cette tâche par N. En fait, M peut se terminer avant que N n'ait achevé sa tâche. C'est le cas pour l'activité « Ouvrir ServiceHost » (M) qui génère les activités Écouteur (N), puis s'arrête.

Un transfert de N à M indique que N a achevé la tâche liée à M.

N peut continuer à exécuter d'autres processus non liés à M, par exemple, une activité d'authentificateur existante (N) qui continue à recevoir des demandes de connexion (M) provenant de différentes activités de connexion.

Les transferts entre activités désignent des liens de causalité entre événements dans les activités connexes. Les activités et transferts permettent à l'utilisateur de rechercher de manière probabiliste la cause première d'une erreur. Par exemple, si nous transférons des données entre les activités M et N, dans les composants M et N, et qu'un incident se produit en N juste après le transfert vers M, il est possible de conclure que le problème provient du passage de données de N vers M.

Il n'existe pas nécessairement de relation d'imbrication entre les activités M et N, et ce pour deux raisons : d'une part lorsque l'activité M ne surveille pas le traitement réel effectué dans N bien qu'il ait initié ce traitement, d'autre part lorsque N existe déjà.

Deux exemples de transferts sont présentés ci-dessous.

  • Lorsque vous créez un hôte de service, le constructeur prend le contrôle à partir du code appelant, ou le code appelant est transféré au constructeur. Lorsque le constructeur a terminé de s'exécuter, il rend le contrôle au code appelant, ou le constructeur est transféré au code appelant. C'est le cas d'une relation imbriquée.
  • Lorsqu'un écouteur commence à traiter des données de transport, il crée un nouveau thread et remet à l'activité Recevoir des octets le contexte de traitement approprié, c.-à-d., en passant le contrôle et les données. Lorsque ce thread a fini de traiter la demande, l'activité Recevoir des octets ne retourne aucune donnée à l'écouteur. Dans ce cas, la nouvelle activité de thread fait l'objet d'un transfert entrant mais pas d'un transfert sortant. Les deux activités sont liées mais pas imbriquées.

Séquence de transfert d'activité

Une séquence de transfert d'activité bien formée comprend les étapes suivantes.

  1. Commencer une nouvelle activité, qui consiste à sélectionner un nouveau gAId
  2. Émettre un suivi de transfert vers ce nouveau gAId à partir de l'ID d'activité actuel
  3. Définir le nouvel ID dans le stockage local des threads (TLS)
  4. Émettre un suivi de démarrage permettant d'indiquer le début de la nouvelle activité
  5. Retourner à l'activité d'origine implique les étapes suivantes :
  6. Émettre un suivi de transfert vers le gAId d'origine
  7. Émettre un suivi d'arrêt pour indiquer la fin de la nouvelle activité
  8. Affecter au TLS l'ancien gAId

L'exemple de code suivant montre comment procéder. Cet exemple suppose qu'un appel bloquant est effectué lors du transfert vers la nouvelle activité, et inclut des suivis d'interruption/reprise.

// 0. Create a trace source
TraceSource ts = new TraceSource(“myTS”);
// 1. remember existing (“ambient”) activity for clean up
Guid oldGuid = Trace.CorrelationManager.ActivityId;
// this will be our new activity
Guid newGuid = Guid.NewGuid(); 
// 2. call transfer, indicating that we are switching to the new AID
ts.TraceTransfer(667, "Transferring.", newGuid);
// 3. Suspend the current activity.
ts.TraceEvent(TraceEventType.Suspend, 667, "Suspend: Activity " + i-1);
// 4. set the new AID in TLS
Trace.CorrelationManager.ActivityId = newGuid;
// 5. Emit the start trace
ts.TraceEvent(TraceEventType.Start, 667, "Boundary: Activity " + i);
// trace something
ts.TraceEvent(TraceEventType.Information, 667, "Hello from activity " + i);
// Perform Work
// some work.
// Return
ts.TraceEvent(TraceEventType.Information, 667, "Work complete on activity " + i); 
// 6. Emit the transfer returning to the original activity
ts.TraceTransfer(667, "Transferring Back.", oldGuid);
// 7. Emit the End trace
ts.TraceEvent(TraceEventType.Stop, 667, "Boundary: Activity " + i);
// 8. Change the tls variable to the original AID
Trace.CorrelationManager.ActivityId = oldGuid;  
// 9. Resume the old activity
ts.TraceEvent(TraceEventType.Resume, 667, "Resume: Activity " + i-1);

Liste des types de suivis

Consultez Niveaux de source (page pouvant être en anglais) pour plus d'informations sur les divers niveaux de suivi : Critical, Error, Warning, Information et Verbose, ainsi qu'une description de l'indicateur ActivityTracing, qui bascule la sortie des événements de limite de suivi et de transfert d'activité. Consultez

TraceEventType (page pouvant être en anglais) pour connaître les types de suivis qui peuvent être émis à partir de System.Diagnostics. Le tableau suivant répertorie les plus importants.

Type de suivi Description

Critical

Erreur irrécupérable ou panne d'application.

Error

Erreur récupérable.

Warning

Message d'informations. 

Information

Problème non critique. 

Verbose

Suivi de débogage. 

Start

Démarrage d'une unité logique de traitement. 

Suspend

Interruption d'une unité logique de traitement. 

Resume

Reprise d'une unité logique de traitement. 

Stop

Arrêt d'une unité logique de traitement. 

Transfer

Changement d'identité de corrélation. 

Une activité est définie comme une combinaison des types de suivis ci-dessus.

Le code suivant est une expression régulière qui définit une activité idéale dans une portée locale (source de suivi),

R = Start ( (Critical | Error | Warning | Information | Verbose | Transfer)* (Transfer Suspend Transfer Resume)* )* Stop

Cela signifie qu'une activité doit remplir les conditions suivantes.

  • Elle doit démarrer et s'arrêter respectivement en fonction des suivis Démarrer et Arrêter
  • Elle doit avoir un suivi Transfert qui précède immédiatement un suivi Interrompre ou Reprendre.
  • Elle ne doit pas avoir de suivi entre les suivis Interrompre et Reprendre, s'ils existent.
  • Elle peut contenir n'importe quel type de suivi Critique/Avertissement/Informations/Commentaires/Transfert, en nombre illimité, tant que les conditions précédentes sont observées.

Le code suivant est une expression régulière qui définit une activité idéale dans la portée globale,

R+ 

R étant l'expression régulière d'une activité dans la portée locale. Cela se traduit par :

[R+ = Start ( (Critical | Error | Warning | Information | Verbose | Transfer)* (Transfer Suspend Transfer Resume)* )* Stop]+

Voir aussi

Concepts

Configuration du suivi
Utilisation de Service Trace Viewer pour afficher les suivis corrélés et résoudre les problèmes
Scénarios de suivi de bout en bout

Autres ressources

Service Trace Viewer Tool