The initial monitoring configuration state for resource utilization is fully enabled.
Although all components in the BizTalk infrastructure run under a common process name called 'BTSNTSvc.exe' , AVIcode BizTalk monitoring data correlates the name of the monitored BizTalk host with the corresponding process ID and monitored component in order to identify which host is utilizing which resources. The following are two examples of why it is important to be able to clearly identify which BizTalk component is consuming the resources:
AVIcode BizTalk monitoring provides ability to view the CPU, I/O, Memory, and Application Load utilization for each BizTalk host. The monitored process screen shows the name of the BizTalk host and all corresponding orchestrations, process IDs, process uptime, etc. :
This screen is accessible via:
The 'Trend Reports' tab allows users to look at specific instances and to compare instances between hosts for metrics such as the average request time or CPU:
When you detect that a specific host is utilizing an unusual amount of resources (i.e., high values for CPU , average response time, I/O, etc), enable performance tracing for that host to pinpoint where the resources are being consumed. (see the following section on Performance Tracing). In general, determining what instance is consuming what resource will determine how to resolve the issue. For example, if you see a host with a specific adapter that is utilizing too much resource, you can just move that host to a different physical serve.
The initial monitoring configuration state for failure monitoring is to collect only critical exceptions (which arise from unhandled exceptions) and no data collection for exception tracking of namespaces.
Additional diagnostic data can be collected by:
Please note that both of these actions require a restart of the BizTalk hosts that the action is being applied to. A restart can be applied from the hosts view by performing the 'Stop NT Service' then 'Start NT Service' actions, or by going to the to the BizTalk Server State view and performing the 'Restart All BizTalk Hosts' action. The 'Enable Only Critical Exceptions Monitoring' action will revert to the default state.
Because most BizTalk orchestrations are asynchronous, and can perform an activity and then run for extended periods waiting for an event, there is no natural notion of alerting threshold that is measured in seconds. The management pack can however, monitor 'chunks of work' within an orchestration and provide a notification in the event that the orchestration is consuming too much resource. There are two typical monitoring scenarios:
Out of the box, the SLA threshold for various custom functions in the entry point list is set to a very high value, which effectively disables the feature. As a result, the feature can be enabled by changing the thresholds without having to restart the BizTalk host.
|Action||Entrypoint Function Affected|
|Enable Maps Performance Tracing||
|Enable Orchestrations Performance Tracing||
|Enable Pipelines Performance Tracing||
|Enable Adapters Performance Tracing||
Enabling performance tracing for individual adapters should be done by changing the thresholds through the Intercept MMC Entrypoint Function list. BizTalk hosts can be found in Windows Services section of the MMC.
If your orchestrations call custom .NET code, or if you use your own custom adapters or pipelines, you can trace also the code execution inside your code. To do this, use the 'Enable Performance Diagnostic Data' (which is the equivalent of adding monitoring for all namespaces) from within the MMC.
By default, monitoring is enabled for both BizTalk Host processing and for Soap Adapters (which run under the w3wp process in IIS rather than under the BizTalk service).
Last update: Friday, October 15, 2010 11:46:18 AM