Activities and Correlation
A WCF activity
is a logical subset of functionality used to group traces for ease of identification and monitoring. An example is the processing of a call into a service endpoint. Although activities are independently useful, effective monitoring requires a mechanism to track flow between multiple activities.
is the concept of associating multiple activities to create a logical sequence of flow in a distributed application. Correlation is performed via transfers
, linking activities within an endpoint, and propagation
, linking activities across multiple endpoints.
Activities are correlated by the interchange of an identifier called the activity ID
. This identifier, a GUID, is generated by the System.Diagnostics.CorrelationManager class. CorrelationManager is associated with a trace and can be retrieved via the static property System.Diagnostics.Trace.CorrelationManager. It has two primary methods, StartLogicalOperation()
, used to link associated actions into a logical unit for tracing purposes.
Tracing is disabled by default and can be enabled by configuring a trace source to emit information and trace listeners to process and save the final trace details.
Here are the relevant portions of the SelfHost App.config
file configured for tracing:
<system.serviceModel ... />
<filter type="" />
<filter type="" />
In the preceding code, the <source>
node references the System.ServiceModel
trace source, which is the source used by WCF to emit tracing details. In the <listeners>
node, we can add one or more trace listeners to process those details. The type
property indicates the listener class to invoke and the initializeData
contains arguments to that listener, such as a file location. An XmlWriterTraceListener is configured to write details to the app_tracelog.svlog
|Author's Note: Service Configuration Editor—To avoid having abstractions hide the mechanics of WCF diagnostics, we're enabling tracing and message logging by manually specifying settings in the respective App.config files. Later in this chapter, we'll show how to use the Service Configuration Editor to quickly and accurately make such changes without editing the configuration files directly. The trace source has a switchValue property that is used to specify the level of detail that should be captured. Table 1 shows the possible values for the switchValue property when configuring the trace source.
Table 1: Tracing Source switchValue Attribute Options
||Disables the trace source.
||Tracks the most serious application and environmental failures, such as a service failing, or a service being unable to start.
||Issues with application logic or the environment—for example, an unrecoverable exception.
||Scenarios that may result in an exception or failure in the future, or notifications that the application recovered from an exception.
||Details about system events that may be helpful for debugging, simple auditing, and overall monitoring.
||Full information at each processing step. Useful for pinpointing sources of issues.
||Uses correlation to track flow between logically connected components of the distributed application.
Note that ActivityTracing
can be combined with a verbosity selector (for example, switchValue="Warning, ActivityTracing"
Using the more verbose options for tracing can quickly lead to large amounts of traced information, which can add to system overhead and increase the challenge of separating the relevant data from extraneous data. When diagnosing an issue, we recommend that you begin tracing at the Warning
When operating under normal production conditions, consider leaving tracing off or at Critical
until conditions require further information for diagnostics or monitoring.
Tracing is used to record the flow and individual actions of the various components of a distributed application. Another feature, message logging, is used to record the contents of the messages from or to clients and services. Message logging can be configured to capture messages at the service level, the transport level, and to record messages that are malformed. The data captured via message logging can be useful for a variety of situations, from diagnostics to creating audit trails of service utilization.
Enabling Message Logging
Like tracing, message logging is based on System.Diagnostics and is disabled by default. It can be enabled first by adding a trace listener (for example, XMLWriterTraceListener) to process messages from the System.ServiceModel.MessageLogging trace source.
Here's the SelfHost
application configuration, configured for message logging:
<services ... />
<behaviors ... />
section looks similar to that used for enabling tracing. We have added a source using System.ServiceModel.MessageLogging, the mechanism through which messages are emitted for logging, and are processing that source with the same listener class, XmlWriterTraceListener, used earlier for tracing.
Unlike tracing, however, the format and verbosity of messages emitted by the MessageLogging source is specified in a <messageLogging>
element added to the <system.serviceModel><diagnostics>
configuration node. Table 2 shows the messageLogging
options along with descriptions of their purposes. Any number of these options may be specified in configuration, and those that are not will use the default values shown in Table 2.
Table 9.2: messageLogging Element Attributes and Values
||If true, both the message header and body are logged. If false, only the message header will be logged.
||Logs incorrectly formatted messages.
||Logs messages as received or sent by the service itself.
||Logs messages either just before encoding for transport or directly after being received from transport.
||Number of logged messages after which further logging will be suspended.
||Maximum message size, in bytes, that will be logged. If a message exceeds this limit, it will be ignored and a warning trace will be emitted.
Note that messages logged at the transport level may be encrypted, depending on the binding or configuration options you have selected.