1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Diagnostics in WCF

Discussion in 'ASP.NET' started by MinalS, Nov 17, 2014.

  1. MinalS

    MinalS New Member

    Joined:
    Jul 8, 2014
    Messages:
    138
    Likes Received:
    30
    Trophy Points:
    0
    WCF has several tools and built in features for diagnosing the cause of issues. User does not need to enable the configuration files. The tracing facilities allows user to capture the events and logging to capture the exchanged message details.

    Tracing



    The core diagnostics capabilities of WCF are build on the existing facilities of the .NET framework. The System.Diagnostics features the tracing capabilities for the trace sources and trace listeners. The TraceSource class is configured using the System.Diagnostics.TraceSource class. It enables the applications to delete the details of data and events.

    The trace listeners classes are derived from the abstract base class System.Diagnostics.TraceListener. The WCF uses the features for removing the details about the action during the service calls and the responses. User does not need to create any custom code. The configuration file is useful to enable the source and listener.

    End – to – End Tracing

    The feature for monitoring the WCF applications is known as end to end ( E2E ) tracing. The System.Diagnostics features pass between various entities of the distributed application and they are correlated into the logical flow. It is possible for the users to follow the sequence of actions for the service and machine boundaries.

    Activities and Correlation

    A WCF activity is a logical subset of functionality for grouping the traces and ease for monitoring. The activities are independently useful for the users, effectively monitoring is useful.

    Correlation is the concept of associating the multiple activities for creating a logical sequence of flow for the distributed applications. It is used for linking activities within an endpoint, linking activities across endpoints and propagation.

    The activity ID is an identifier used for correlating the activity. The System.Diagnostics.CorrelationManager is used for generating GUID identifier. The static property System.Diagnostics.Trace.CorrelationManager is useful for retrieving the GUID. There are two methods as StartLogicalOperation() and StopLogicalOperation() for linking the associated actions into a logical unit.

    Enabling Tracing

    Tracing is disabled by default in any system. User needs to enable it by configuring the trace source. The final trace details are saved by the tracing.

    The following code shows the enable tracing in configuration files.
    Code:
    <configuration>
    	<system.serviceModel />
    	<system.diagnostics>
    	<sources>
    		<source name=”System.ServiceModel” propogateActivity=”true” 
    		switchValue=”Warning,ActivityTracing” >
    		<listeners>
    		<add type=” System.Diagnostics.DefaultTraceListener” name=”Default” >
    		< filter type=”” />
    		</add>
    		< add initializeData=”app_tracelog.svclog”   type=”System.Diagnostics.XmlWriterTraceListener” name=”tracelog” traceOutputOptions=”Timestamp” >
    		< filter type=”” />
    		</add>
    		<.listeners>
    		</source>
    	</sources>
    	</system.diagnostics>
    </configuration>
    
    In the above code, the <source> node refers to the System.ServiceModel trace source. The <listeners> node is used to add and remove the listeners. The type property is used to invoke class. The initializeData consists of the arguments for the listener.

    The trace source contains a property as switchValue. It is used to specify the level of detail possible for capturing the data. The values that can be added are as mentioned below:
    1. Critical: It is used to track the serious applications and failures of the environment.
    2. Off: It is used to disable the trace source
    3. Error: It is used for issues with the application logic
    4. Warning: It provides the conditions that can cause an exception or failures
    5. Information: It provides the information about the system events used for debugging and auditing

    Message Logging



    The use of tracing is to record the actions performed by the applications. Message Logging is used to record the contents of the messages from the client and services. The messages can be captured at service level, transport level, and malformed messages. These messages are used for creating the audit trails or diagnostics.

    The messages logging is in the System.Diagnostics namespace. User can enable the message logging by adding the trace listener for message processing in the System.ServiceModel.MessageLogging source.

    The code to be added for creating the message logging is as shown below:
    Code:
    <configuration>
    	<system.serviceModel>
    		<services/>
    		<behaviors/>
    		<diagnostics>
    		   <messageLogging logEntireMessage=”true” 
    		     logMessageAtServiceLevel =”true”
    		     maxMessageToLog=”2000” />
    		</diagnostics>
    	</system.serviceModel>
    	
    	<system.diagnostics>
    		<sources>
    		<source name=”System.ServiceModel.MessageLogging” >
    		<listeners>
    		   <add name=”messages” type=”System.Diagnostics.XmlWriterTraceLitener” initializeData=”messages.svclog” />
    		</listeners>
    		</source>
    		</sources>
    	</system.diagnostics>
    </configuration>
    
    
    The <system.diagnostics> section is similar to the tracing. The System.ServiceModel.MessageLogging is used to add the source. The messages are evaluated and the XmlWriterTraceListener class is used for tracing the data.

    There are several messageLogging options available for the user. The list is as mentioned below:
    1. maxmessagesToLog: It is used to state the number of messages after which the logging is suspended
    2. logEntireMessage: It is a Boolean value. It is true, if both the message header and the body are logged. If the value is false, the message header is logged.
    3. logMalformedMessage: It is used to log the incorrectly formatted messages.
    4. logMessagesAtServiceLevel: It is used to log the messages sent or received by the service.
    5. logMessagesAtTransportLevel: It is used to log the messages sent just before encoding or directly after received by the transport
    6. maxSizeOfMessageToLog: It is the maximum size that will be logged.

    Configuration Options



    There are several options for configuring the WCF application. Some of them are explained as follows.

    1) Shared Listeners

    In the earlier examples, we learned about the listeners specified for a source. User can select to configure a shared listener by assigning multiple sources and adding the output in a single file.
    Code:
    <system.diagnostics>
    	<sources>
    		<source name=”System.ServiceModel” propogateActivity=”true” 
    		switchValue=”Warning.ActivityTracing” >
    		<listeners>
    			<add name=”diagnostics” />
    		</listeners>
    		</source>
    		<source name=”System.ServiceModel.MessageLogging” >
    		<listeners>
    			<add name=”diagnostics” />
    		</listeners>
    		</source>
    	</sources>
    	<sharedListeners>
    		< add name=”diagnostics” type=”System.Diagnostics.XmlWriterTraceListener” initializeData=”diagnostics.svclog” />
    	</sharedListeners>
    </system.diagnostics>
    
    In the above code, the add listener to the name matching the shared listeners. Here, user is matching the diagnostics listener that will write the traces and messages in the diagnostics.svclog file.

    2) Message Filters

    The messages are used for the appropriate level specified in the <messageLogging> element. To reduce the logging overhead and decrease the file size, user must include the messages that match the rules configured by the user.

    Message filters are XPath expressions that are satisfied before the message is logged by the user. The non matching messages are excluded. The malformed messages are not affected by the filters.

    The following code shows the Filter used for the message logging.
    Code:
    <configuration>
    	<system.serviceModel>
    	<diagnostics>
    		<messageLogging logMalformedMessages=”true” 
    		logMessageAtTransportLevel=”true” >
    			<filters>
    			<add nodeQuota=”1500” xmlns:s12=”http://www.w3.org/2003/05/soap-envolope” 
    xmlns:was10=”http://www.w3.org/2005/07/addressing”>
    /s12:Envolope/s12:Header/wsa10:Action[ starts – with ( text(), ‘http://Microsoft.ServiceModel.Samples/IStudent’ ) ]
    			</add>
    			</filters>
    		</messageLogging>
    	</diagnostics>
    	</system.serviceModel>
    </configuration>
    
    In the above example, the namespace is defined is used by the XPath expression. They are used for the SOAP envelope and the schema.

    3) Trace Source Auto Flashing

    When the user wants all the message operation to be completed automatically, the <trace> element is enabled in the <system.diagnostics> configuration node.

    The following code demonstrates the enabling of the element.
    Code:
    <configuration>
    	<system.serviceModel…./>
    	<system.diagnostics>
    		<sources/>
    		<trace autoflush=”true” />
    	</system.diagnostics>
    </configuration>
    
    The trace auto flash property is off by default. User must ensure about enabling the property as it can create the performance overhead.

    4) Performance Counters

    The performance counters are installed in the .NET framework. The counters are present in the ServiceModelService, ServiceModelOperation and ServiceModelEndpoint.
    The following code snippet demonstrates the enabling of the performance counters.
    Code:
    <configuration>
    	<system.serviceModel>
    	<diagnostics peformanceCounters=”ServiceOnly” >
    	<messageLogging logMalformedMessages=”true” 
    	logMessagesAtTransportLevel=”true” />
    	</diagnostics>
    	</system.ServiceModel>
    </configuration>
    
    The performancecounters attribute is added to enable them in the code. The settings options available are Off, SerivceOnly and All. If user uses the All option, it will create an cost overhead. The ServiceOnly is used for the normal operations. The Off option is the default for the performance counters.

    Service Configuration Editor

    Until now we have been adding the manual XML based methods of the configuration files for tracing and message logging. The following can be achieved by using the SDK tool, Service Configuration Editor. In Visual Studio application, user can launch the editor by right clicking the configuration file and selecting the Edit WCF Configuration’ option.

    The App.config file is present in the WCF application. Right click on the project’s App.config file, click Edit WCF Configuration option, select the Diagnostics node form the left pane.

    [​IMG]

    The following configuration window is displayed to the user.

    [​IMG]

    The listeners and the sources are displayed in the left pane. User can use the appropriate sections by clicking the hyperlinks present in the window.

    Tracing Options

    When the tracing is enabled, user can navigate to all the available options by clicking the Trace Level tab.

    Logging Options

    Click the link next to the Log Level label next to the MessageLogging section. Three types of messages can be logged by the user. Malformed messages, messages sent and received at the service level, and the messages sent and received at the transport level.

    When the user clicks on the Message Logging item in the Diagnostics node of the left panel, the advanced settings are displayed.

    [​IMG]

    Configuring Sources

    The Service Configuration Editor will automatically configure the System.ServiceModel and System.ServiceModel.MessageLogging trace sources. User can expand and navigate the Diagnostics/Sources node in the configuration pane.

    [​IMG]

    User can view and change the activity tracing and propagation to be used. The activity tracing and propagation are only for the tracing listeners and not valid for the message logging listeners.
     
    shabbir likes this.

Share This Page