Partager via


Utilisation de la visionneuse de traces de service pour afficher les traces corrélées et la résolution des problèmes

Cette rubrique décrit le format des données de trace, comment l’afficher et les approches qui utilisent la Visionneuse de trace de service pour résoudre les problèmes de votre application.

Utilisation de l'outil Service Trace Viewer

L’outil Visionneuse de suivi de service Windows Communication Foundation (WCF) vous aide à mettre en corrélation les traces de diagnostic produites par les écouteurs WCF pour localiser la cause racine d’une erreur. L’outil vous permet d’afficher, de regrouper et de filtrer facilement les traces afin de pouvoir diagnostiquer, réparer et vérifier les problèmes liés aux services WCF. Pour plus d’informations sur l’utilisation de cet outil, consultez Service Trace Viewer Tool (SvcTraceViewer.exe).

Cette rubrique contient des captures d’écran des traces générées en exécutant l’exemple Tracing and Message Logging, lorsqu’elles sont consultées à l’aide de l’outil Service Trace Viewer Tool (SvcTraceViewer.exe). Cette rubrique montre comment comprendre le contenu de suivi, les activités et leur corrélation, et comment analyser un grand nombre de traces lors de la résolution des problèmes.

Consultation du contenu de suivi

Un événement de trace contient les informations les plus importantes suivantes :

  • Nom de l’activité lorsqu’il est défini.

  • Temps d’émission.

  • Niveau de suivi.

  • Nom de la source de la trace.

  • Nom du processus.

  • ID de thread.

  • Identificateur de trace unique, qui est une URL qui pointe vers une référence technique Microsoft qui fournit plus d’informations relatives à la trace.

Tous ces éléments sont visibles dans le volet supérieur droit de la Visionneuse de trace de service, ou dans la section Informations de base dans la vue mise en forme du panneau inférieur droit lors de la sélection d’une trace.

Remarque

Si le client et le service se trouvent sur le même ordinateur, les traces des deux applications sont présentes. Celles-ci peuvent être filtrées à l’aide de la colonne Nom du processus .

De plus, la vue mise en forme fournit également une description du suivi et des informations détaillées supplémentaires lorsqu'elles sont disponibles. Ces informations peuvent contenir le type d'exception et le message, les piles d'appel, l'action du message, les champs De/À, et d'autres informations sur les exceptions.

Dans la vue XML, les balises XML utiles sont les suivantes :

  • <SubType> (niveau de suivi).

  • <TimeCreated>.

  • <Source> (nom de la source de trace).

  • <Correlation> (ID d’activité défini lors de l’émission de la trace).

  • <Execution> (processus et ID de thread).

  • <Computer>.

  • <ExtendedData>, y compris <Action>, <MessageID> et <ActivityId> définis dans l’en-tête du message lors de l’envoi d’un message.

Si vous examinez la trace « Envoyer un message sur un canal », vous pouvez voir le contenu suivant.

<E2ETraceEvent xmlns="http://schemas.microsoft.com/2004/06/E2ETraceEvent">
   <System xmlns="http://schemas.microsoft.com/2004/06/windows/eventlog/system">
      <EventID>262163</EventID>
      <Type>3</Type>
      <SubType Name="Information">0</SubType>
      <Level>8</Level>
      <TimeCreated SystemTime="2006-08-04T18:45:30.8491051Z" />
      <Source Name="System.ServiceModel" />
       <Correlation ActivityID="{bbbb1111-cc22-3333-44dd-555555eeeeee}"/>
       <Execution ProcessName="client" ProcessID="1808" ThreadID="1" />
       <Channel />
       <Computer>TEST1</Computer>
   </System>
   <ApplicationData>
       <TraceData>
          <DataItem>
             <TraceRecord xmlns="http://schemas.microsoft.com/2004/10/E2ETraceEvent/TraceRecord" Severity="Information">
                 <TraceIdentifier>http://msdn.microsoft.com/library/System.ServiceModel.Channels.MessageSent.aspx</TraceIdentifier>
                 <Description>Sent a message over a channel.</Description>
                 <AppDomain>client.exe</AppDomain>
                 <Source>System.ServiceModel.Channels.ClientFramingDuplexSessionChannel/35191196</Source>
                <ExtendedData xmlns="http://schemas.microsoft.com/2006/08/ServiceModel/MessageTransmitTraceRecord">

                  <MessageProperties>
                     <AllowOutputBatching>False</AllowOutputBatching>
                  </MessageProperties>
                  <MessageHeaders>
                     <Action d4p1:mustUnderstand="1" xmlns:d4p1="http://www.w3.org/2003/05/soap-envelope" xmlns="http://www.w3.org/2005/08/addressing">http://Microsoft.ServiceModel.Samples/ICalculator/Multiply</Action>
                     <MessageID xmlns="http://www.w3.org/2005/08/addressing">urn:uuid:7c6670d8-4c9c-496e-b6a0-2ceb6db35338</MessageID>
                     <ActivityId CorrelationId="aaaa0000-bb11-2222-33cc-444444dddddd" xmlns="http://schemas.microsoft.com/2004/09/ServiceModel/Diagnostics">bbbb1111-cc22-3333-44dd-555555eeeeee</ActivityId>
                     <ReplyTo xmlns="http://www.w3.org/2005/08/addressing">
                        <Address>http://www.w3.org/2005/08/addressing/anonymous</Address>
                    </ReplyTo>
                    <To d4p1:mustUnderstand="1" xmlns:d4p1="http://www.w3.org/2003/05/soap-envelope" xmlns="http://www.w3.org/2005/08/addressing">net.tcp://localhost/servicemodelsamples/service</To>
                  </MessageHeaders>
                  <RemoteAddress>net.tcp://localhost/servicemodelsamples/service</RemoteAddress>
                </ExtendedData>
            </TraceRecord>
          </DataItem>
       </TraceData>
   </ApplicationData>
</E2ETraceEvent>

Suivi de ServiceModel E2E

Lorsque la source de suivi System.ServiceModel est définie avec un switchValue différent de « Désactivé » et ActivityTracing, WCF crée des activités et des transferts pour le traitement WCF.

Une activité est une unité logique de traitement qui regroupe toutes les traces liées à cette unité de traitement. Par exemple, vous pouvez définir une activité pour chaque requête. Les transferts créent une relation causale entre les activités au sein des points de terminaison. La propagation de l’ID d’activité vous permet de lier des activités entre les points de terminaison. Pour ce faire, définissez propagateActivity=true dans la configuration à chaque point de terminaison. Les activités, les transferts et la propagation vous permettent d’effectuer une corrélation d’erreurs. De cette façon, vous pouvez trouver la cause racine d’une erreur plus rapidement.

Sur le client, une activité WCF est créée pour chaque appel de modèle objet (par exemple, Ouvrir ChannelFactory, Ajouter, Diviser, et ainsi de suite.) Chacun des appels d’opération est traité dans une activité « Action de processus ».

Dans la capture d’écran suivante, extraite de l’exemple suivi et journalisation des messages , le panneau gauche affiche la liste des activités créées dans le processus client, triées par heure de création. Voici une liste chronologique d’activités :

  • Construit l'usine de canaux (ClientBase).

  • Ouverture de la fabrication de canal.

  • Traitement de l'action Add.

  • Configurez la session sécurisée (ceci s’est produit sur la première demande) et avez traité trois messages de réponse d’infrastructure de sécurité : RST, RSTR, SCT (message de traitement 1, 2, 3).

  • J'ai traité les demandes de soustraction, de multiplication et de division.

  • Fermeture de la fabrication de canal, et ce faisant de la session sécurisée et traitement de la réponse de message de sécurité Cancel.

Nous voyons les messages d’infrastructure de sécurité en raison de wsHttpBinding.

Remarque

Dans WCF, nous affichons les messages de réponse traités initialement dans une activité distincte (message de processus) avant de les mettre en corrélation avec l’activité d’action de processus correspondante qui inclut le message de requête, via un transfert. Cela se produit pour les messages d’infrastructure et les requêtes asynchrones et est dû au fait que nous devons inspecter le message, lire l’en-tête activityId et identifier l’activité d’action de processus existante avec cet ID pour la mettre en corrélation. Pour les requêtes synchrones, nous attendons la réponse et savons donc à quelle action de processus la réponse est liée.

L’image suivante montre les activités clientes WCF répertoriées par l’heure de création (volet gauche) et leurs activités et traces imbriquées (panneau supérieur droit) :

Capture d’écran montrant les activités du client WCF répertoriées par heure de création.

Lorsque nous sélectionnons une activité dans le panneau de gauche, nous pouvons voir les activités imbriquées et les traces dans le panneau en haut à droite. Par conséquent, il s’agit d’une vue hiérarchique réduite de la liste des activités à gauche, en fonction de l’activité parente sélectionnée. Étant donné que l'action de processus 'Ajouter' sélectionnée est la première requête, cette activité contient l'activité Configurer la session sécurisée (transfert vers, transfert à partir de) et les traces pour le traitement effectif de l'action 'Ajouter'.

En double-cliquant sur l’activité « Traiter l’action Add » dans le volet gauche, une représentation graphique des activités WCF clientes liées à l’activité Ajouter est affichée. La première activité à gauche est l’activité racine (0000), qui est l’activité par défaut. WCF transfère l’activité ambiante. Si celle-ci n’est pas définie, WCF transfère hors de 0000. Dans ce contexte, la deuxième activité (« Traiter l'action Add ») transfère hors de 0. Ensuite, nous voyons la configuration de la session sécurisée.

L’image suivante montre une vue graphique des activités clientes WCF, en particulier l’activité ambiante (ici 0), l’action traiter et configurer une session sécurisée :

Graphique dans le Trace Viewer montrant l’activité ambiante et l’action processus.

Dans le volet supérieur droit, nous pouvons consulter tous les suivis se rapportant à l'activité Traiter l'action Add. Plus précisément, nous avons envoyé le message de demande (« Envoyé un message sur un canal ») et reçu la réponse (« Reçu un message sur un canal ») dans la même activité. Ceci est illustré dans le graphique suivant. Pour plus de clarté, l’activité Configurer une session sécurisée est réduite dans le graphique.

L’image suivante montre une liste de traces pour l’activité Traiter l’action. Nous envoyons la demande et recevons la réponse dans la même activité.

Capture d’écran de trace Viewer montrant une liste de traces pour l’activité Action de processus

Ici, nous chargeons les traces du client uniquement pour plus de clarté, mais les traces de service (message de demande reçu et message de réponse envoyé) apparaissent dans la même activité si elles sont également chargées dans l’outil et propagateActivity a été défini sur true.. Ceci est montré dans une illustration ultérieure.

Sur le service, le modèle d’activité est mappé aux concepts WCF comme suit :

  1. Nous construisons et ouvrez un ServiceHost (cela peut créer plusieurs activités liées à l’hôte, par exemple, dans le cas de la sécurité).

  2. Nous créons une activité Écouter à pour chaque écouteur dans le ServiceHost (avec des transferts en entrée et en sortie de l'activité Ouvrir ServiceHost).

  3. Lorsque l’écouteur détecte une demande de communication lancée par le client, il transfère vers une activité « Octets de réception » dans laquelle tous les octets envoyés du client sont traités. Dans cette activité, nous pouvons voir toutes les erreurs de connexion qui se sont produites pendant l’interaction avec le service client.

  4. Pour chaque ensemble d’octets reçus qui correspondent à un message, nous traitons ces octets dans une activité « Traiter le message », où nous créons l’objet Message WCF. Dans cette activité, nous voyons des erreurs liées à une enveloppe incorrecte ou à un message mal formé.

  5. Une fois le message formé, nous transférons vers une activité de traitement. Si propagateActivity est défini true sur le client et le service, cette activité a le même identifiant que celui défini par le client et décrit précédemment. À partir de cette étape, nous commençons à tirer parti de la corrélation directe entre les points de terminaison, car toutes les traces émises dans WCF liées à la requête se trouvent dans cette même activité, y compris le traitement des messages de réponse.

  6. Pour une action hors processus, nous créons une activité « Exécuter du code utilisateur » pour isoler les traces émises dans le code utilisateur des activités émises dans WCF. Dans l’exemple précédent, le suivi « Service envoie une réponse » est émis dans l’activité « Exécuter le code utilisateur » et non dans l’activité propagée par le client, le cas échéant.

Dans l’illustration suivante, la première activité à gauche est l’activité racine (0000), qui est l’activité par défaut. Les trois activités suivantes visent à ouvrir ServiceHost. L’activité de la colonne 5 est l’écouteur et les activités restantes (6 à 8) décrivent le traitement WCF d’un message, du traitement des octets à l’activation du code utilisateur.

L’image suivante montre une vue graphique des activités de service WCF :

Capture d’écran de trace Viewer montrant la liste des activités de service WCF

La capture d’écran suivante montre les activités du client et du service, et met en évidence l’activité Ajouter une action de processus entre les processus (orange). Les flèches concernent les messages de demande et de réponse envoyés et reçus par le client et le service. Les suivis de Traiter l'action sont séparés par processus dans le graphique, mais sont affichés dans le cadre de la même activité dans le volet supérieur droit. Dans ce panneau, nous pouvons voir les traces clientes des messages envoyés suivis des traces de service pour les messages reçus et traités.

Les images suivantes illustrent une vue graphique des activités clientes et de service WCF

Graphique du Trace Viewer qui montre les activités du client et du service WCF.

Dans le scénario d'erreur suivant, les suivis d'erreur et d'avertissement au niveau du service et du client sont liés. Une exception est levée d'abord dans le code utilisateur sur le service (activité verte la plus à droite qui inclut un suivi d'avertissement pour l'exception « Le service ne peut pas traiter cette demande dans le code utilisateur »). Lorsque la réponse est envoyée au client, une trace d’avertissement est à nouveau émise pour indiquer le message d’erreur (activité à gauche en rose). Le client ferme ensuite son client WCF (activité jaune en bas à gauche), qui abandonne la connexion au service. Le service génère une erreur (activité rose la plus longue, à droite).

Utilisation de la visionneuse de traces

Corrélation d’erreurs entre le service et le client

L’exemple utilisé pour générer ces traces est une série de requêtes synchrones à l’aide de wsHttpBinding. Il existe des écarts par rapport à ce graphique pour les scénarios sans sécurité ou avec des requêtes asynchrones, où l’activité Action de processus englobe les opérations de début et de fin qui constituent l’appel asynchrone et affiche les transferts vers une activité de rappel. Pour plus d’informations sur des scénarios supplémentaires, consultez Scénarios de suivi de bout en bout.

Résolution des problèmes à l'aide de Service Trace Viewer

Lorsque vous chargez des fichiers de trace dans l’outil Visionneuse de trace de service, vous pouvez sélectionner n’importe quelle activité rouge ou jaune dans le volet gauche pour rechercher la cause d’un problème dans votre application. L'activité 000 a généralement des exceptions non gérées qui remontent jusqu'à l'utilisateur.

L’image suivante montre comment sélectionner une activité rouge ou jaune pour localiser la racine d’un problème. Capture d’écran des activités rouges ou jaunes pour localiser la racine d’un problème.

Dans le volet supérieur droit, vous pouvez examiner les traces de l’activité que vous avez sélectionnée à gauche. Vous pouvez ensuite examiner les traces rouges ou jaunes dans ce panneau et voir comment elles sont corrélées. Dans le graphique précédent, nous voyons des suivis d'avertissement à la fois pour le client et le service dans la même activité Traiter l'action.

Si ces traces ne vous fournissent pas la cause racine de l’erreur, vous pouvez utiliser le graphique en double-cliquant sur l’activité sélectionnée dans le volet gauche (ici action Traiter). Le graphique avec les activités associées s’affiche ensuite. Vous pouvez ensuite développer les activités associées (en cliquant sur les signes « + ») pour rechercher la première trace émise en rouge ou jaune dans une activité associée. Continuez à développer les activités qui se sont produites juste avant la trace rouge ou jaune d’intérêt, en suivant les transferts vers les activités ou les flux de messages connexes entre les points de terminaison, jusqu’à ce que vous suiviez la cause racine du problème.

Utilisation de la visionneuse de traces

Développement d’activités pour suivre la cause racine d’un problème

Si ServiceModel ActivityTracing est désactivé mais que le suivi ServiceModel est activé, vous pouvez voir les traces ServiceModel émises dans l’activité 0000. Toutefois, cela nécessite davantage d’efforts pour comprendre la corrélation de ces traces.

Si la journalisation des messages est activée, vous pouvez utiliser l’onglet Message pour voir quel message est affecté par l’erreur. En double-cliquant sur un message en rouge ou jaune, vous pouvez voir l’affichage graphique des activités associées. Ces activités sont les plus étroitement liées à la demande où une erreur s’est produite.

Capture d’écran de trace Viewer avec journalisation des messages activée.

Pour commencer la résolution des problèmes, vous pouvez également choisir une trace de message rouge ou jaune, puis double-cliquez dessus pour suivre la cause racine.

Voir aussi