Použití nástroje Service Trace Viewer pro zobrazení korelovaných tras a řešení potíží

Toto téma popisuje formát dat trasování, jejich zobrazení a přístupy, které k řešení potíží s aplikací používají Prohlížeč trasování služeb.

Použití nástroje Service Trace Viewer

Nástroj Windows Communication Foundation (WCF) Service Trace Viewer pomáhá korelovat diagnostické trasování vytvořené naslouchacími procesy WCF za účelem vyhledání původní příčiny chyby. Nástroj vám umožňuje snadno zobrazit, seskupit a filtrovat trasování, abyste mohli diagnostikovat, opravovat a ověřovat problémy se službami WCF. Další informace o použití tohoto nástroje naleznete v tématu Nástroj sledování trasování služby (SvcTraceViewer.exe).

Toto téma obsahuje snímky obrazovky tras vygenerovaných spuštěním ukázky trasování a protokolování zpráv, zobrazených pomocí nástroje Service Trace Viewer (SvcTraceViewer.exe). Toto téma ukazuje, jak porozumět obsahu tras, činnostem a jejich korelaci a jak analyzovat velký počet tras při odstraňování problémů.

Zobrazení obsahu trasování

Událost sledování obsahuje následující nejdůležitější informace:

• Název aktivity při nastavení

• Doba emisí.

• Úroveň trasování.

• Název zdroje trasování

• Název procesu

• ID vlákna.

• Jedinečný identifikátor trasování, což je adresa URL odkazující na technickou referenci microsoftu, která poskytuje další informace týkající se trasování.

Všechny tyto možnosti lze při výběru trasování zobrazit v pravém horním panelu v Prohlížeči trasování služby nebo v části Základní informace ve formátovaném zobrazení pravého dolního panelu.

Poznámka:

Pokud jsou klient a služba na stejném počítači, budou k dispozici záznamy obou aplikací. Můžete je filtrovat pomocí sloupce Název procesu .

Kromě toho formátované zobrazení také obsahuje popis trasování a další podrobné informace, pokud jsou k dispozici. Druhá možnost může zahrnovat typ výjimky a zprávu, zásobníky volání, akci zprávy, pole odesílatele/příjemce a další informace o výjimce.

V zobrazení XML obsahují užitečné značky XML následující:

• <SubType> (úroveň trasování).

• <TimeCreated>.

• <Source> (název zdroje sledování).

• <Correlation> (ID aktivity nastavená při vytváření trasování).

• <Execution> (identifikátor procesu a vlákna).

• <Computer>.

• <ExtendedData>, včetně <Action>, <MessageID> a <ActivityId> nastavených v záhlaví zprávy při odesílání zprávy.

Pokud prozkoumáte trasování 'Odeslání zprávy přes kanál', může se vám zobrazit následující obsah.

<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>

Trasování modelu ServiceModel E2E

Pokud je zdroj trasování nastaven na System.ServiceModel jiný než Vypnuto, a switchValue, WCF vytváří aktivity a přenosy pro zpracování WCF.

Aktivita je logická jednotka zpracování, která shromažďuje všechny stopy související s danou jednotkou zpracování. Můžete například definovat jednu aktivitu pro každý požadavek. Přenosy vytvářejí kauzální vztah mezi aktivitami v rámci koncových bodů. Šíření ID aktivity umožňuje spojit aktivity napříč koncovými body. To lze provést nastavením propagateActivity=true v konfiguraci na každém koncovém bodu. Aktivity, přenosy a šíření umožňují provádět korelaci chyb. Tímto způsobem můžete rychleji najít původní příčinu chyby.

V klientovi se vytvoří jedna aktivita WCF pro každé volání modelu objektu (například Open ChannelFactory, Add, Divide atd.). Každé volání operace se zpracovává v aktivitě Akce procesu.

Na následujícím snímku obrazovky extrahovaný z ukázky trasování a protokolování zpráv na levém panelu se zobrazí seznam aktivit vytvořených v procesu klienta seřazený podle času vytvoření. Následuje chronologický seznam aktivit:

• Byl vytvořen objekt pro vytváření kanálů (ClientBase).

• Otevřel továrnu kanálů.

• Zpracoval akci Přidat.

• Nastavte zabezpečenou relaci (proběhla při prvním požadavku) a zpracujte tři odpovědní zprávy z bezpečnostní infrastruktury: RST, RSTR, SCT (zpracovat zprávy 1, 2, 3).

• Zpracoval požadavky odečítání, násobení a dělení.

• Uzavřela se továrna kanálu, a tím se uzavřela zabezpečená relace a byla zpracována odpověď na zprávu zabezpečení zrušit.

Kvůli wsHttpBinding vidíme zprávy z bezpečnostní infrastruktury.

Poznámka:

Ve WCF zobrazujeme zprávy odpovědí zpracovávané zpočátku v samostatné aktivitě (zpráva procesu) předtím, než je korelujeme s odpovídající aktivitou akce procesu, která zahrnuje zprávu požadavku prostřednictvím přenosu. K tomu dochází u zpráv infrastruktury a asynchronních požadavků a je příčinou faktu, že musíme zprávu zkontrolovat, přečíst hlavičku activityId a identifikovat existující aktivitu akce procesu s tímto ID, aby se s ní daly korelovat. U synchronních požadavků blokujeme odpověď, a proto víme, ke které akci procesu se odpověď vztahuje.

Následující obrázek znázorňuje aktivity klientů WCF uvedené podle času vytvoření (levého panelu) a jejich vnořených aktivit a trasování (pravý horní panel):

Když vybereme aktivitu na levém panelu, uvidíme na pravém horním panelu vnořené aktivity a stopy. Proto je to redukované hierarchické zobrazení seznamu aktivit vlevo podle vybrané nadřazené aktivity. Vzhledem k tomu, že vybraná procesní akce Přidat je první požadavek, obsahuje tato aktivita aktivitu Nastavit zabezpečenou relaci (přenášení do, přenášení zpět) a trasování pro provádění akce Přidat.

Pokud dvakrát klikneme na akci Proces Přidat aktivitu na levém panelu, můžeme vidět grafické znázornění aktivit WCF klienta souvisejících s přidáním. První aktivita vlevo je kořenová aktivita (0000), což je výchozí aktivita. WCF se odpojí od kontextu aktivity. Pokud není definováno, WCF přenese z 0000. Zde, druhá aktivita, Akce Přidat ze procesu, dochází k přenosu z 0. Pak uvidíme nastavení zabezpečené relace.

Následující obrázek znázorňuje grafické zobrazení aktivit klienta WCF, konkrétně Ambient Activity (zde 0), akce procesu a nastavení bezpečné relace.

Na pravém horním panelu vidíme všechno trasování související s aktivitou Přidání akce procesu. Konkrétně jsme odeslali zprávu požadavku ("Odeslali jsme zprávu přes kanál") a obdrželi odpověď ("Přijali jsme zprávu přes kanál") v rámci stejné činnosti. To je znázorněno v následujícím grafu. Pro přehlednost je v grafu skrytá aktivita Nastavení zabezpečeného sezení.

Následující obrázek ukazuje seznam protokolů činnosti Procesní akce. Požadavek odešleme a obdržíme odpověď ve stejné aktivitě.

Zde načítáme pouze trasování klienta kvůli jasnosti, ale trasování služeb (přijatá zpráva požadavku a odeslaná zpráva odpovědi) se zobrazí ve stejné aktivitě, pokud jsou také načteny v nástroji a propagateActivity je nastaveno na true.. To je ukázáno na pozdějším obrázku.

V této službě se model aktivit mapuje na koncepty WCF následujícím způsobem:

1. Vytvoříme a otevřeme ServiceHost (v případě zabezpečení může například vytvořit několik aktivit souvisejících s hostitelem).

2. Vytvoříme aktivitu Listen At pro každého posluchače v ServiceHost (s přenosy do a z otevřeného ServiceHost).

3. Když naslouchací proces zjistí komunikační požadavek iniciovaný klientem, přenese se do aktivity "Příjem bajtů", ve které se zpracovávají všechny bajty odeslané z klienta. V této aktivitě vidíme všechny chyby připojení, ke kterým došlo během interakce mezi klientem a službou.

4. Pro každou sadu bajtů přijatých, která odpovídá zprávě, zpracováváme tyto bajty v aktivitě "Zpráva procesu", kde vytvoříme objekt zprávy WCF. V této aktivitě vidíme chyby související s chybnou obálkou nebo chybnou zprávou.

5. Po vytvoření zprávy přejdeme do činnosti procesní akce. Pokud je propagateActivity nastavena na true jak na klientovi, tak na službě, má tato aktivita stejné ID jako to, které bylo definováno v klientovi a popsáno dříve. V této fázi začneme využívat přímou korelaci napříč koncovými body, protože všechny sledování generované ve WCF, které souvisí s požadavkem, jsou ve stejné aktivitě, včetně zpracování odpovědní zprávy.

6. Pro akci mimo proces vytvoříme aktivitu Execute user code (Spustit uživatelský kód), která izoluje trasování vygenerovaná v uživatelském kódu od trasování vygenerovaných ve WCF. V předchozím příkladu je trasování "Service sends Add response" emitováno v aktivitě "Execute User code," nikoli v aktivitě šířené klientem, pokud je to možné.

Na následujícím obrázku je první aktivita vlevo kořenovou aktivitou (0000), což je výchozí aktivita. Další tři aktivity slouží k otevření ServiceHost. Aktivita ve sloupci 5 je naslouchací proces a zbývající aktivity (6 až 8) popisují zpracování zprávy WCF od zpracování bajtů až po aktivaci uživatelského kódu.

Následující obrázek znázorňuje zobrazení grafu aktivit služeb WCF:

Následující snímek obrazovky ukazuje aktivity pro klienta i službu a zvýrazňuje aktivitu Procesní akce Přidání napříč procesy (oranžová). Šipky se vztahují k žádostem a odpovědím odeslaným a přijatým klientem a službou. Stopy akce procesu jsou rozděleny mezi procesy v grafu, ale zobrazují se jako součást téže aktivity v pravém horním panelu. Na tomto panelu vidíme trasování klientů pro odeslané zprávy následované trasováním služby pro přijaté a zpracovávané zprávy.

Následující obrázky znázorňují zobrazení grafu aktivit klienta WCF i služeb.

V následujícím chybovém scénáři souvisí trasování chyb a upozornění ve službě a klientovi. V uživatelském kódu na službě je nejprve vyvolána výjimka (nejvíce vpravo umístěná zelená aktivita, která obsahuje trasování upozornění na výjimku "Služba nemůže zpracovat tento požadavek v uživatelském kódu."). Při odeslání odpovědi klientovi se znovu vygeneruje trasování upozornění, aby byla označena chybová zpráva (růžová aktivita vlevo). Klient pak zavře klienta WCF (žlutá aktivita na levé dolní straně), která přeruší připojení ke službě. Služba vyvolá chybu (nejdelší růžová aktivita vpravo).

Použití

Korelace chyb napříč službou a klientem

Ukázkový vzorek, který byl použit k vytvoření těchto tras, je řada synchronních požadavků pomocí "wsHttpBinding". Existují odchylky od tohoto grafu pro scénáře bez zabezpečení nebo s asynchronními požadavky, kde aktivita akce procesu zahrnuje počáteční a koncové operace, které tvoří asynchronní volání, a ukazuje přenosy do aktivity zpětného volání. Další informace odalšíchch To-End ch

Řešení potíží s využitím Prohlížeče sledování služeb

Při načítání trasovacích souborů v nástroji Service Trace Viewer můžete vybrat libovolnou červenou nebo žlutou aktivitu na levém panelu a zjistit příčinu problému v aplikaci. Aktivita 000 obvykle obsahuje neošetřené výjimky, které se dostanou až k uživateli.

Následující obrázek ukazuje, jak vybrat červenou nebo žlutou aktivitu pro vyhledání kořene problému.

Na pravém horním panelu můžete prozkoumat stopy aktivity, kterou jste vybrali vlevo. Pak můžete na tomto panelu prozkoumat červené nebo žluté stopy a zjistit, jak spolu souvisejí. V předchozím grafu vidíme varovné stopy pro klienta i službu ve stejné procesní akci.

Pokud vám tyto trasování neposkytnou původní příčinu chyby, můžete graf využít dvojitým kliknutím na vybranou aktivitu na levém panelu (zde proces akce). Zobrazí se graf se souvisejícími aktivitami. Potom můžete rozbalit související aktivity (kliknutím na znaménka +) a najít první vygenerované trasování červeně nebo žlutě v související aktivitě. Stále rozšiřujte aktivity, ke kterým došlo těsně před červenou nebo žlutou trasou zájmu, následováním přechodů k souvisejícím aktivitám nebo tokům zpráv napříč koncovými body, dokud nenajdete původní příčinu problému.

Použití

Rozšíření aktivit pro sledování původní příčiny problému

Pokud je serviceModel ActivityTracing vypnutý, ale trasování ServiceModel je zapnuté, můžete zobrazit trasování ServiceModel generované v aktivitě 0000. To ale vyžaduje větší úsilí, aby bylo možné porozumět korelaci těchto stop.

Pokud je protokolování zpráv povolené, můžete pomocí karty Zpráva zjistit, která zpráva je ovlivněna chybou. Poklikáním na zprávu červeně nebo žlutě zobrazíte zobrazení grafu souvisejících aktivit. Tyto aktivity nejvíce souvisejí s požadavkem, ve kterém došlo k chybě.

Pokud chcete začít řešit potíže, můžete také vybrat červené nebo žluté trasování zpráv a poklikáním na ni sledovat původní příčinu.

Viz také

• Koncové scénáře trasováníTo-End
• Nástroj Service Trace Viewer (SvcTraceViewer.exe)
• trasování