Configuring Monitoring
This section describes the tools, cmdlets, and settings that you can use to configure monitoring for WCF and WF services in Windows Server AppFabric.
Configuration Settings
Before you can monitor your WCF and WF services you must first configure and enable monitoring. Configuration can be as simple as initializing a database and then enabling the default Health Monitoring configuration, or you can customize monitoring for your specific requirements. Several predefined configurations are available to support common monitoring scenarios.
Configurable WCF and WF service monitoring settings for AppFabric include the following:
| Configuration Element | Description |
|---|---|
Connection String |
Determines the server and database used to save monitored events. You need to create and initialize a Monitoring database before you can enable monitoring for WCF and WF services. Warning The default ADO.NET timeout for a connection string is 15 seconds. If a Dashboard query takes longer than that, the query will time out and the data will not be returned. The connection string provided by AppFabric Configuration Wizard does not include a timeout setting. So if your Dashboard query takes longer than the default ADO.NET timeout, you will have to manually add a timeout value to the configuration file a. For more information, see SqlCommand. CommandTimeout property. |
Monitoring Level |
Configures the Event Collection service and tracking profile to collect a predefined set of events for a given monitoring scenario. Monitoring must be enabled and the level must be at least Health Monitoring for the Dashboard to display WCF Call History and WF Instance History metrics. Note To display WF Instance (Persisted Service Instances) metrics on the Dashboard you must also enable workflow persistence. For more information, see Configuring Workflow Persistence. |
Tracking Profile |
Determines which workflow events will be emitted, and then saved to a Monitoring database. The default level is Health Monitoring Profile, which is also the minimum level required to populate the metrics visible on the Dashboard. The tracking profile can only be edited or adjusted at the service scope level. |
Diagnostic Tracing and Message Logging |
Enables diagnostics and message logging traces for WCF and WF services to be saved to a file. The diagnostics tracing and message logging support helps isolate problems in your WCF and WF services. It is not intended to be used for routine health monitoring. |
Event Collection service Settings |
Determines certain fundamental behaviors and settings for an instance of the Event Collection service. These are advanced settings, and most users will not need to modify the default values. |
You can configure monitoring for WCF and WF services at several levels, and configuration can be inherited from the level above. The default monitoring configuration for WCF and WF services running on a given server is determined by the settings saved in the server’s root Web.config file. You can override the server settings by configuring monitoring at the site, application, or service level. All monitoring configuration is saved in Web.config files in the IIS 7.0 configuration hierarchy. For a detailed discussion of how Web.config files are used in AppFabric, see Configuration Process in Windows Server AppFabric and General Configuration.
Configuration Tools
AppFabric provides various configuration tools for setup and configuration support. IIS Manager extensions in AppFabric provide a dialog box to enable monitoring, configure the monitoring level, choose a tracking profile, and configure System.Diagnostics message logging and tracing features. All of these tools call AppFabric cmdlets to make changes to the configuration files. This gives you the freedom to automate monitoring configuration or to manage monitoring configuration entirely from the Windows PowerShell console (command line). Outside of IIS Manager there are additional tools that help with both setup and configuration of AppFabric. For more information, refer to Windows Server AppFabric Setup Wizard UI Reference and Windows Server AppFabric Configuration Wizard UI Reference.
To configure most monitoring settings you need to be logged on with an account that is a member of the AS_Administrators group. This account needs to have permission to modify the Web.config files at the level (scope) where you will manage monitoring configuration. You can limit access to the Web.config file so that users can modify only the monitoring configuration at a given level or for a specific application.
Checklist for Configuring Monitoring
Here are some steps to take if monitoring data is not being displayed in the AppFabric Dashboard:
Ensure that the Event Collection service is running, and that it has permissions to read the Web.config files of the applications being monitored. This is the AppFabric Event Collection Service in the Windows Services console.
If you are using a SQL Server edition other than SQL Server Express for the monitoring database try restarting the SQL Server Agent Service. Ensure that the service is in a running state after the restart.
In the configuration dialog box for WCF and WF at the server, site, application, and service level, click the Monitoring tab. Ensure that the following items are configured:
The Write events to database check box in the Application Monitoring (database based) section is selected. At the service level, you will not be able to select this check box, but it will appear if Database Event Collection is enabled.
Monitoring level is set to a setting other than Off.
There is a valid connection string that points to a valid monitoring database.
If the preceding actions do not help, perform additional diagnostics by using the Event Viewer (eventvwr.exe). In the theEvent Viewer, examine the Event Viewer examine Applications and Service Logs -> Microsoft ->Windows -> Application Server-System Services\Admin and Applications and Service Logs -> Microsoft ->Windows -> Application Server-System Services\Debug logs. Make sure these logs are enabled while troubleshooting issues.
If these quick-check items don’t result in monitoring data being displayed in the AppFabric Dashboard, you’ll need to look at the Monitoring database in detail. If you are using SQL Server for the monitoring database here are some suggestions to further assist you in figuring out why data is not being displayed:
Check the ASStagingTable table and ASWcfEvents view in the database. If you see rows in the ASStagingTable table but not in the ASWcfEvents view then you may have the following issue. When the system is working properly, WCF events move from the ASStagingTable table into the ASWcfEvents view. For SQL Express, this will happen using the SQL Broker. Please make sure the broker is enabled. For other SQL Server products, the SQL Agent is responsible for moving the events so ensure that the SQL Agent is running.
Check if the ASStagingTable table contains a number of events that have not been processed. If so, manually run the ASImportEvents stored procedure to populate the events in the AppFabric Dashboard. In SQL Express, a Service Broker job is used to run this stored procedure periodically. In the next step we will determine if this has encountered any errors.
Open the Microsoft SQL Server Management Studio. Locate the Monitoring database, right-click Properties, chose Options, and verify that Service Broker is enabled. If enabled, Broker Enabled is set to true. If it is not, enable it.
In the monitoring database, check in the ASJobsTable table if the last run for the ASImportEvents job was successful. This may give you some insight into why the events are still in the ASStagingTable table. If the last runs were not successful, most of the time this is due to a permissions issue when initializing the database. This scenario is usually due to creating the monitoring database and schema while logged into a domain, and then trying to run the job to move the data from the staging table while disconnected from the domain. The Service Broker jobs are run as the identity of the user that was logged on while initializing the databases. If your scenarios require connect/disconnect from the domain we recommend that you initialize the databases as a local administrative user.