|
<system.diagnostics> element
Diagnostic traces provide you with information that shows what is happening throughout the application's operation. In case of WCF (Windows Communication Foundation) services hosted by Smartsite iXperion you should enable WCF tracing whenever there is problem in starting the services or when you encounter problems trying to connect to one of the services.
WCF traces are written to the source named System.ServiceModel. The tracing level is controlled by the switchValue setting. The available tracing levels are described in the following table.
| Trace level | Description |
|---|---|
| Critical | Logs all unhandled exceptions. The following are some examples of when you might use the Critical level: - The AppDomain went down because of an unhandled exception. - The service(s) fail to start. |
| Error | Logs all exceptions. You can use the Error level in the following situations: - A "failed to create endpoint" exception is causing the service to fail on startup. - Serialization errors occur, preventing the messages from being processed. |
| Warning | A condition exists that may subsequently result in an error or critical failure. You can use this level in the following situations: - The application is receiving more requests than its throttling settings allows. - Timeout has exceeded. - Credentials are rejected. - The receiving queue is near its maximum configured capacity. |
| Information | Messages helpful for monitoring and diagnosing system status, measuring performance, or profiling are generated. Type of messages: - Channels are created. - Endpoint listeners are created. - Message enters/leaves transport. - Security token is retrieved. |
| Verbose | Debug-level tracing for both user code and servicing Set this level when: - You are not sure which method in your code was called when the failure occurred. - You have an incorrect endpoint configured and the service failed to start because the entry in the reservation store is locked. |
| ActivityTracing | Flow events between processing activities and components. This level allows administrators and developers to correlate applications in the same application domain. |
| All | All the events mentioned above. |
The levels from Verbose to Critical are stacked on top of each other, that is, each trace level includes all levels above it. For example, a listener listening at the Warning level receives Critical, Error and Warning traces. The All level includes events from Verbose to Critical and ActivityTracing events.
Caution: The Information, Verbose, and ActivityTracing levels generate a vast amount of trace messages, which may negatively impact on message throughput if you have used up all available resources on the machine. Also, when a tracelistener is used which emits the trace to a file, the file can become quite large (several GB).
In the example configuration shown below a listener named traceListener is added to the system.ServiceModel source. The listener itself is configured within the sharedListeners element. In this case it uses the standard .NET framework trace listener (System.Diagnostics.XmlWriterTraceListener), which emits the trace messages to a xml file.
You can add any number of trace listeners for each source. If the trace listener emits the trace to a file, you must specify the output file location and name of the file by setting the initializeData attribute.
Message logging
To enhance debugging, you could also add an additional trace source (System.ServiceModel.MessageLogging) to the configuration to enable message logging. Notice that the switchValue attribute has no impact on this trace source.
Besides adding the additional source, you also need to add an additional diagnostics section within the system.serviceModel, as shown here:
| XML |
Copy Code
|
|---|---|
<configuration> <system.serviceModel> <diagnostics wmiProviderEnabled="true"> <messageLogging logEntireMessage="true" logMalformedMessages="true" logMessagesAtServiceLevel="true" logMessagesAtTransportLevel="true" maxMessagesToLog="3000" /> </diagnostics> </system.serviceModel> <system.diagnostics> <trace autoflush="true" /> <sources> <source name="System.ServiceModel" switchValue="Information, ActivityTracing"> <listeners> <add name="traceListener" /> </listeners> </source> <source name="System.ServiceModel.MessageLogging"> <listeners> <add name="traceListener"/> </listeners> </source> </sources> <sharedListeners> <add name="traceListener" type="System.Diagnostics.XmlWriterTraceListener" initializeData="D:\WCFLogs\Test6.svclog" /> </sharedListeners> </system.diagnostics> </configuration> |
|
Recommended settings
For a production environment, if you are using WCF trace sources, set the switchValue to Warning. For a deployment or debugging environment, choose Information or Verbose, along with ActivityTracing, when you encounter problems with one of the services. You also might want to enable the above mentioned message logging feature within a debugging environment.
Viewing Trace Content
A trace event contains the following most significant information:
- Activity name when set.
- Emission time.
- Trace level.
- Trace source name.
- Process name.
- Thread id.
- A unique trace identifier, which is a URL that points to a destination in the online MSDN library, from which you can obtain more information related to the trace.
All this information is included within a E2ETraceEvent xml element per trace event, along with extended application data in the ApplicationData childnode. When an exception occurs, the complete exception including the stack trace, will be included in the ApplicationData node.
Although each trace message is in xml format, the trace file generated by the XmlWriterTraceListener is not a valid xml file since it lacks an enclosing root node. The XmlWriterTraceListener simply appends each trace message to the end of the file, which would not have been possible if the file did contain a root node.
The best tool to view a trace file is the Microsoft Service Trace Viewer (SvcTraceViewer.exe).