AppFabric: Items to Check When Configuring AppFabric Monitoring

AppFabric: Items to Check When Configuring AppFabric Monitoring

At times you may not get the proper data displayed in the AppFabric Dashboard, even though your NET applications using WCF/WF servcies appears to be running fine. If you have that problem, here are some troubleshooting 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. For the procedure, see How to check the ASStagingTable below.
·         Check if the ASStagingTable table contains a number of events that have not been processed. If so, manually run the ASImportEvents or ASImportWCFEvents 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. For the procedure, see How To Run the ASImportWcfEvents Stored Procedure below.

·         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.

 How to check the ASStagingTable
1. Open Microsoft SQL Server Management Studio
2. Connect to the DB where AppFabic is storing the data (either SQL Express or SQL Server).
3. Expand the Databases node and expand the AppFabricMonitoring node.
4. Look for db.ASStagingTable.
5. Right-click the node and click Select Top 1000 Rows.

How To Run the ASImportWcfEvents Stored Procedure
1. Open Microsoft SQL Server Management Studio
2. Connect to the DB where AppFabic is storing the data (either SQL Express or SQL Server).
3. Expand the Databases node and expand the Programmability node.
4. Right-click dbo.ASImportWcfEvents and click Execute Stored Procedure.
5. In the Execute Procedure dialog, enter a value (e.g. 100) for the batch size.

Sort by: Published Date | Most Recent | Most Useful
Comments
  • Ensure monitoring is registered in the root web.config file.

    •Open the  [Configure AppFabric] program from the start menu.

    •Click next; at "Hosting Services" do the following for both monitoring and persistence if you (want to) use them:

    •Check the box, complete the two inputs, and click configure.

    •MAKE SURE TO CHECK THE "Register AppFabric [monitoring | persistence] store in root web.config".  (This is what I missed when first running the config.)

    •If the store has not already been initialized, check that box and fill in the connection string info.

    •Finish out and close the configure dialogs/program.

    Refresh the AppFabric dashboard . . . it may take a minute for the events, if there are any, to catch up.  Regardless, the error icon/text should be visible at the top under "Services" if there are no other issues.  

  • When running SQL Server (not Express), be sure to check the next run date in SQL Server Management Studio->Your Server->Sql Server Agent->Job Activity Monitor. When changing system date to an earlier date would cause that job to suspend until next run (which stays last run+10secs)

Page 1 of 1 (2 items)