2010-11-19 6 views
4

Ich möchte Ablaufverfolgungsinformationen in .svclog-Dateien speichern, aber nur für fehlgeschlagene Anforderungen. Ist das möglich? Wenn ja, wie genau?WCF Tracing von NUR fehlgeschlagenen Anfragen?

Ich habe einen WCF-Dienst, der Hunderte von Malen pro Minute aufgerufen wird. In seltenen Fällen erhalten Clients einen Fehler 500, der außerhalb der Grenzen meines Codes auftritt, der in WCF ausgeführt wird (normalerweise Sicherheitsprobleme). Ich würde gerne genau wissen, warum diese Fehler passieren und was sie verursacht.

Ich würde auch gerne das Trace-Viewer-Tool verwenden, um die .svclog-Dateien zu untersuchen.

Soweit ich das beurteilen kann, habe ich zwei Möglichkeiten: 1) Instrument FERB Tracing durch Protokollierung fehlgeschlagener Anfragen über system.webServer \ Tracing-Einstellungen. Leider gefällt mir die Oberfläche des IE-Trace-Viewers nicht, und ich bekomme auch nicht genügend Informationen aus den Trace-Protokollen, um herauszufinden, warum ein Fehler außerhalb meines Codes aufgetreten ist.

2) aktivieren Sie die globale Ablaufverfolgung unter system.diagnostics \ trace Abschnitt. Dieser Abschnitt erstellt großartige Trace-Logs mit allem, was ich jemals haben möchte. Ich finde jedoch keine Möglichkeit, die Informationen nur für fehlgeschlagene Anfragen zu erfassen. In diesem Abschnitt werden Ablaufverfolgungsinformationen für ALLE Anforderungen erfasst. Meine Ablaufverfolgungsprotokolle füllen sich schnell!

Meine Fehler 500 sind intermittierend und selten. Letztendlich möchte ich meine .svclog-Ablaufverfolgung immer aktiviert haben, aber nur dann, wenn fehlgeschlagene Anforderungen auftreten.

Bitte beraten Sie, wenn das möglich ist?

Vielen Dank!

Edit:

Graham, Ich habe Ihren Rat befolgt und ich sehe nicht die Protokolle ich erwarte. Hier sind relevante Abschnitte aus der web.config:

<system.diagnostics> 
    <trace> 
     <listeners> 
      <add type="Microsoft.WindowsAzure.Diagnostics.DiagnosticMonitorTraceListener, Microsoft.WindowsAzure.Diagnostics, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" name="AzureDiagnostics"> 
       <filter type="" /> 
      </add> 
     </listeners> 
    </trace> 

    <sources> 
     <source name="System.ServiceModel" switchValue="Error"> 
      <listeners> 
       <add name="wcfTracing" 
         type="System.Diagnostics.XmlWriterTraceListener" 
         initializeData="Traces1.svclog"/> 
       <add name="log4netTracing" 
         type="AzureWatch.Model.Service.Log4netTraceListener,AzureWatch.Model.Service"/> 
      </listeners> 
     </source> 
     <source name="System.ServiceModel.MessageLogging" switchValue="Error"> 
      <listeners> 
       <add name="wcfTracing" 
         type="System.Diagnostics.XmlWriterTraceListener" 
         initializeData="Traces2.svclog"/> 
       <!--<add name="log4netTracing" 
         type="AzureWatch.Model.Service.Log4netTraceListener,AzureWatch.Model.Service"/>--> 
      </listeners> 
     </source> 
    </sources> 
    </system.diagnostics> 

<!-- ... --> 

     <diagnostics wmiProviderEnabled="true"> 

     <messageLogging 
      logEntireMessage="true" 
      logMalformedMessages="true" 
      logMessagesAtServiceLevel="true" 
      logMessagesAtTransportLevel="true" 
      maxSizeOfMessageToLog="1000000" 
      maxMessagesToLog="-1" /> 
    </diagnostics> 

Hier ist der Client-Fehler des WCF:

<Exception> 
    <Type>System.Net.Sockets.SocketException</Type> 
    <Message>An existing connection was forcibly closed by the remote host</Message> 
    <StackTrace> 
     <Frame>at System.Net.Sockets.NetworkStream.Read(Byte[] buffer, Int32 offset, Int32 size)</Frame> 
    </StackTrace> 
    </Exception> 

Leider gibt es nichts, das durch eine der Trace-Hörer angemeldet ist. Anforderungsfehler-Protokoll enthält diese:

-GENERAL_READ_ENTITY_END 
    BytesReceived 0 
    ErrorCode 2147943395 
    ErrorCode The I/O operation has been aborted because of either a thread exit or an application request. (0x800703e3) 
    Warning 
-MODULE_SET_RESPONSE_ERROR_STATUS 
    ModuleName ManagedPipelineHandler 
    Notification 128 
    HttpStatus 400 
    HttpReason Bad Request 
    HttpSubStatus 0 
    ErrorCode 0 
    ConfigExceptionInfo 
    Notification EXECUTE_REQUEST_HANDLER 
    ErrorCode The operation completed successfully. (0x0) 
    0 msInformational 

Antwort

6

Ich habe versucht, für meine WCF-Dienst in der folgenden Konfiguration setzen, und drücken Sie den Dienst mit gültigen und ungültigen Anmeldeinformationen. Nur die Anforderungen mit ungültigen Anmeldeinformationen führten dazu, dass in der Service-Trace-Datei etwas angezeigt wurde. Mein Dienst verwendet eine benutzerdefinierte UserNamePasswordValidator Klasse, und das war in der Stack-Ablaufverfolgung vorhanden. Die wichtigen Teile sind das switchValue="Error" und propagateActivity="false" im <source> Element. Nicht sicher, ob dies ist genau das, was Sie wollen, aber es scheint zumindest schließen ...

<system.diagnostics> 
    <sources> 
    <source name="System.ServiceModel" switchValue="Error" 
      propagateActivity="false"> 
     <listeners> 
     <add type="System.Diagnostics.DefaultTraceListener" name="Default"> 
      <filter type="" /> 
     </add> 
     <add name="ServiceModelTraceListener"> 
      <filter type="" /> 
     </add> 
     </listeners> 
    </source> 
    </sources> 
    <sharedListeners> 
    <add initializeData="C:\Path-to-log-file\Web_tracelog.svclog" 
     type="System.Diagnostics.XmlWriterTraceListener, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" 
     name="ServiceModelTraceListener" 
     traceOutputOptions="DateTime, Timestamp, Callstack"> 
     <filter type="" /> 
    </add> 
    </sharedListeners> 
    <trace autoflush="true" /> 
</system.diagnostics> 
+0

angeben würde ich vorschlagen, Warnstufe zu verwenden, zumindest zunächst, bis Sie den Fehler genagelt haben. – softveda

+0

@ Pratik- klingt fair genug - was würde eine Warnung auslösen? Ich kann sehen, dass das Auslösen einer Ausnahme einen Fehler bedeutet ... –

+1

Manchmal können Warnungsereignisse vor dem eigentlichen Fehler auftreten und zusätzliche Einblicke in den Fehler geben. – softveda

1

Alternativ ist es möglich, Eventtypefilter als Zuhörers filter

<listeners> 
    <add name="console" 
     type="System.Diagnostics.ConsoleTraceListener" > 
     <filter type="System.Diagnostics.EventTypeFilter" 
     initializeData="Error" /> 
    </add> 
    </listeners>