Contents tagged with Workflow
-
endpoint.tv - Troubleshooting with AppFabric
Troubleshooting applications in production is always a challenge. With AppFabric monitoring your workflows and services, you get great information about exactly what is happening, including notices about unhandled exceptions. In this episode, Michael McKeown will show you more about how you can use these features to troubleshoot problems with your applications.
Be sure to check out the AppFabric Wiki for more great tips, and to share yours as well. -
endpoint.tv - Ten Tips for Troubleshooting with the Windows Server AppFabric Dashboard
When you write the product documentation you learn all kinds of cool inside tips about how to use it. In this episode, Michael McKeown shares 10 tips for troubleshooting using the dashboard.
Be sure to check out the AppFabric Wiki for more great tips, and to share yours as well. -
Windows Server AppFabric Beta 2 Refresh for Visual Studio 2010/.NET 4 RTM
Today we are pleased to announce a Beta 2 Refresh for Windows Server AppFabric. This build supports the recently released .NET Framework 4 and Visual Studio 2010 RTM versions—a request we’ve had from a number of you. Organizations wanting to use Windows Server AppFabric with the final RTM versions of .NET 4 and Visual Studio 2010 are encouraged to download the Beta 2 Refresh today. Please click here for an installation guide on installing the Beta 2 Refresh. We encourage developers and IT professionals building ASP.NET applications or applications that use WCF or WF and run on IIS to download the Beta 2 Refresh and provide feedback at http://connect.microsoft.com/dublin/feedback or via our forum at http://social.msdn.microsoft.com/Forums/en-US/dublin/threads/.
-
Today on http://endpoint.tv – AppFabric Dashboard Overview
AppFabric has this great new Dashboard that gives you insight into what is happening with your services and workflows. In this video, Senior Programming Writer Michael McKeown shows you what the Dashboard can do for you.
-
Windows Server AppFabric Architecture
A long time ago, applications running on Windows Server were simply EXEs, where developers wrote a lot of custom code on top of the Operating System (OS) to interact with clients and other applications over the network. COM+ and Microsoft Transaction Server (MTS) were added to make it easier to write and host server-side applications and Internet Information Server (IIS) was added to make it easier to write and host Web applications. Application logic was typically written in native code and/or in scripts (CGI, ASP) back then.
-
Uninstalling Windows Server AppFabric Beta1 after VS 10 Beta2/.Net Framework 4 Beta2 has been uninstalled or post VS 10 RC install
When VS 10 RC/.Net Framework 4 RC is installed, the previous version of VS 10 Beta2/.Net Framework 4 Beta2 is uninstalled. If you have Windows Server AppFabric Beta1 installed (Shows up as “Application Server Extensions for .NET4” on the machine that it has been installed), ideally you would uninstall AppFabric Beta1 before uninstalling VS 10 Beta2/.Net Framework 4 Beta2.
-
Windows Server AppFabric Beta 2 is Available!
Read all about the new features here or just download it here.
-
Troubleshooting Applications using Windows Server AppFabric
In our previous post, we discussed the topic of Monitoring Applications using Windows Server AppFabric. In this post, we will show how to use the same tools in more advanced ways to troubleshoot problems in your applications.
Introduction
The previous post introduced the AppFabric Dashboard (pictured below). As you can see, it does a good job of giving you a quick view of the state of your WCF and WF services while highlighting potential problems. The AppFabric Dashboard is the starting point for many paths that you can take while troubleshooting. We’ll explore a few of the more common paths to get you familiar with the toolset.
Tracked Events
Most troubleshooting scenarios will require users to examine event data that was captured from the problematic service at the time the problem manifested itself. The dashboard provides several ways to drill down into the relevant event data quickly.
How to Drilldown
AppFabric provides a Tracked Events View that displays event data within IIS manager. This view lets users customize the query that is sent to the monitoring database using common filters. From the dashboard, you can use the Tracked Events Action to see the latest events that have been tracked, and then customize your query. Alternatively, you can click on any of the metrics displayed in the WCF Call History and WF Instance History sections, and a pre-created query will be used to save you time. For example, you could click the Exceptions metric and the resulting query would just show event data that contains exception information.
Using the Main Event List Pane
The main pane within the Tracked Events View displays a table of events that match the current query. The sortable columns in the table provide a high level summary of what the events mean. You can also right click rows in the table to get a context menu that provides useful tasks such as relating an event to a tracked Workflow instance. This is useful when you want to get events from an operation that spanned multiple services, maybe even different machines, as long as they are sharing the same monitoring database.
Using the Details Pane
When an event is selected in the main pane, the Details Pane at the bottom of the view displays information that was captured with the selected event. This includes custom event properties, environment information, tracked variables (for Workflow Services), and Error details (if applicable).
Using the Query Summary
As mentioned earlier, the query that is used to retrieve event data from the monitoring database can be customized. You would do this using the Query Summary control at the top of the Tracked Events View. Using this control, you can filter by several common criteria such as Emit Time, Event Type, End To End Activity Id, and Tracked Variables (Workflow only).
Monitoring Configuration
AppFabric provides a default monitoring configuration that is sufficient for common health monitoring and basic troubleshooting tasks. Sometimes, a more granular level of event data is required to troubleshoot a problem. AppFabric provides a UI tool that lets you modify the monitoring configuration that is stored in web.config files.
Changing the Monitoring Level
From any scope in the IIS hierarchy (Server, Web Site, Application), select the Configure action from within the .NET 4 WCF and WF Action section and then select the Monitoring tab. You can then choose from one of the 5 predefined monitoring levels.
· Off* – No event data is collected
-
Workflow Persistence in the Windows Server AppFabric
What does the persistence subsystem do?
-
Monitoring Applications using Windows Server AppFabric
This post aims to provide you with an introduction into monitoring the health and activity of your WCF- and WF-based applications with Windows Server AppFabric. More specifically, the post will outline the AppFabric tooling features that are built into IIS Manager as well as outline some basic strategies in using these features to monitor your applications.
Introduction
At the center of AppFabric’s monitoring tools is the Dashboard, which provides a centralized gateway to view the health of WCF and WF services deployed locally or to a server farm. It exposes real-time data for durable WF services and historic data for both WCF and WF services. The Dashboard is designed to provide a holistic summary of all positive and negative metrics on your services in a hierarchical form, starting from a high level and allowing you to drill down incrementally to an atomic level via one of our query-able enumeration pages. Consistent with other IIS Manager features, the Dashboard can be viewed from the server, site or application scopes via the tree view in the Connections Pane on the left hand side of the IIS Manager UI.
Before I explain further, it is important to note that the Dashboard sources data from one or more persistence and monitoring databases. In order for metrics of a particular service to be surfaced on the dashboard, it needs to be configured to utilize persistence (storage of persistence data in one or more Persistence databases) and/or configured to utilize event collection (storage of events in one or more Monitoring databases).
Dashboard Structure and Navigation Flow
The Dashboard is divided into three primary sections: Persisted WF Instances, WCF Call History, and WF Instance History. Each section provides a summary of a particular data pivot and drilling down within each section will lead you to the section’s own respective enumeration page. The first section (Persisted WF Instances) presents ‘live’ data while the subsequent sections provide historic metrics that are constrained to a particular time period. The time period can be modified via the ‘Time Period’ drop-down on the Dashboard menu with both predefined and custom options available.
Each section within the Dashboard can be collapsed or expanded. The collapsed view only allows the section’s summary bar to be visible, providing users with aggregate counts of all positive and negative metrics associated with the subject area (e.g. WCF Call History). Expanding the section will display a series of metrics that breakdown the aggregate counts shown on the section’s summary bar into key contributing factors/sources. For example, expanding the WF Instance History section will display a breakdown of activations and failures by the top 5 services as well as a count of the number of instance failures that have been recovered versus unrecovered. All metrics on the Dashboard are clickable, allowing you to drill-down into the counts to see details on each enumerated item via each section’s respective query page.
Monitoring the health of WCF Services
The AppFabric in this release only support persistence on WF services. As such, monitoring of the health of WCF services will be enabled by AppFabric’s event collection capabilities. With event collection enabled the Dashboard provides visibility into WCF calls and service exceptions via the WCF Call History section.
The summary bar of the WCF Call History section within the Dashboard is aimed at providing an aggregate count of all successfully completed calls and WCF service exceptions over a given period of time. Expanding the section provides some key breakdowns that allow you to:
1. Identify services in high demand: The first column lists the top 5 services (when applicable) with the highest number of completed calls over a given period.
2. Identify top exception-causing services: The center column lists the top 5 services (when applicable) that have encountered the highest number of WCF service exceptions over a given period.
3. Gain breakdown of key causes of WCF service exceptions: The purpose of the third column is to provide a numeric breakdown on the key causes of service exceptions: faulted calls and failed calls. It is important to note that service exceptions can also be caused by issues other than failed or faulted calls, such as service activation errors.
All metrics within the WCF Call History section can be clicked on, allowing you to drill-down into the aggregate count to view an enumerated list via the Tracked Events enumeration page. Depending on the metric you selected, the Tracked Events enumeration page will display the corresponding items via running a prepopulated query.
Monitoring the health of WF Services
The Dashboard provides varying levels of monitoring capabilities for WF services. All WF services regardless of durability can be configured to utilize AppFabric’s event collection capabilities, allowing data at varying verbosity to be collected for monitoring and troubleshooting purposes. This data is surfaced on the Dashboard via the WCF Call History and WF Instance History sections. Durable WF services can also utilize AppFabric’s persistence infrastructure which will allow the Dashboard to also provide live visibility into the health of persisted workflow instances. This feature is provided by the Dashboard’s Persisted WF Instances section.
Using historic data for Health Monitoring
Any WF-based service that is configured to utilize Dublin’s event collection capabilities set at ‘Health Monitoring’ level or above will be able to make visible on all historic metrics on the Dashboard. Since WF-based services also use WCF for communication, the WCF Call History section will also expose monitoring data on these services. For the purpose of this sub-topic, I will focus on discussing the WF Instance History section as the WCF Call History section has already been discussed earlier.
The purpose of the WF Instance History section is to provide a historic overview of all workflow instance activations, failures and completions over a given period. These three key metrics are presented in the summary bar of the section. Expanding the section provides some key breakdowns that allow you to:
1. Identify WF services in high demand: The first column lists the top 5 services (when applicable) with the highest number of instance activations over a given period.
2. Identify WF services with most instance failures: The center column lists the top 5 services (when applicable) that have experienced the greatest number of instance failures over a given period.
3. Understand recovered versus unrecovered instances: The purpose of the third column is to put in context the aggregate failure count in terms of what items are potentially still actionable.
All metrics within the WF Instance History section can be clicked on, allowing you to drill down and view an enumerated list via the Tracked WF Instances page. In addition to the instance information available on the page, you are also able to navigate or view all tracked events for a given instance, assuming that event collection is enabled for the parent service.
Using Persistence data for Health Monitoring
For durable WF services that are configured to utilize AppFabric’s persistence capabilities, the Dashboard provides live visibility into running and suspended persisted instances via the Persisted WF Instances section. Sourced by one or more persistence databases, the section offers an overview of what is happening with your durable workflows.
The summary bar of the Persisted WF Instances section contains a numeric breakdown of all running (Active or Idle) and suspended instances currently associated with your environment. When further context is required, expanding the section provides some key breakdowns that allow you to:
1. Identify durable WF services with highest current demand: The first column lists the top 5 services (when applicable) that currently have the most number of active or idle instances.
2. Identify services with most suspended instances: The center column lists the top 5 services (when applicable) that currently have the most number of suspended instances.
Again, like other sections, all metrics within the Persisted WF Instances section can be clicked on, allowing you to drill down and view an enumerated list via the Persisted WF Instances page. The enumeration page not only provides details on each persisted WF instance that satisfy the query conditions, but also supports instance control operations (i.e. Resuming a suspended instance). Similar to the Tracked WF Instances page, you can also navigate to and view all tracked events for a given persisted instance, assuming that event collection is enabled for the parent service.
Summary and Additional Resources
AppFabric’s monitoring tooling is predominantly delivered via four features within IIS Manager: Dashboard, Persisted WF Instances enumeration, Tracked WF Instances enumeration and Tracked Events enumeration. Starting from the Dashboard, AppFabric’s feature set is aimed to surface the health of WCF and WF services and provide incremental drill-downs via query-able enumeration pages to assist in investigation and problem-diagnosis activities.
Next week’s post will focus in more detail on using AppFabric tools to troubleshoot applications. Also for more information on AppFabric monitoring and troubleshooting tools in general, view the endpoint.tv episode with demonstration here.
