April 11, 2012 at 9:46 AM

SCOM (System Center Operations Manager) 2007 R2 comes with a very handy utility to create reports.
In this blogpost I will explain how you can create a detailed report concerning the CPU usage for a particular BizTalk Host Instance.

So let's get started!

The first thing you need to do is open the Operations Console.
Navigate to "Reporting > Microsoft Generic Report Library" in the left navigation bar. There you can double-click the report "Performance":

 

A new window will appear where you can enter some criteria. Here you can enter the timespan of the performance details you want to have. Let's say we want the stats starting from a week ago. To do this you need to modify the "From" date.

The next step you need to do is select the objects you want to visualize in your chart. You will notice a button named "Change" in the upper right corner. If you click on that button a window will appear where you can modify the settings of the chart.

 

To create a new chart, simply hit the button "New Chart". You can give the chart a meaningful name by setting this in the details pane.
After that you need to set the different series (these are the different objects inside your chart). Click on the button "New Series".

 

In the series, you can add a group/object. In our case this would be the particular server for which we want to see the CPU usage. Click on "Add Group.." and another window will appear. In the search pane, type a part of the computername and hit the search button. Select the computer you want to add.

Once that object is added, you still need to define the performance counter. You can define this in the "Rule" section. Click the browse button.
In the search pane type "CPU" and select the counter "BizTalk: CPU Usage Server Processes".

In the rule section you will see that you can choose a specific host instance (or all host instances) to which the rule will be applied. 

 

Now here's the tricky part. The UI only shows the Process name, not the actual host instance name. To know the actual host instance name you need to execute the steps below:

Go to the server that you have added in the object menu (so the server of which you want to see the performance details).
In the server, press start > Run > perfmon, this will open the built-in performance monitor of that server.
Navigate to "Monitoring Tools  > Performance Monitor" and right click in the window > "Add Counters".

Search for the counter "Process > ID Process" and select the process name of which you want to know the actual host instance name (in our case "BTSNTSvc").
Switch the current view to the "Report" view. In this view you can see the current "Process ID" of that host instance.

To link the Process ID to the host instance name, you have to execute following command in the cmd utility of windows:

TASKLIST /SVC /FI "IMAGENAME eq btsnt*"

This will give you a list of all the BizTalk host instances and their Process ID. Be aware that whenever you restart a host instance, the Process ID will change!
Now simply search for the Process ID that you retrieved from the performance monitor and you know which host instance you selected in the SCOM rule (in our case the host instance "CIPGW_ReceiveHost").

 

When everything is configured simply press the "Run" button at the top left of the window and SCOM will generate a nice chart. You can export the chart as pdf, excel,.. If you like to run this performance report again, you can save all your settings by clicking "File > Publish". This will allow you to save all the settings and run the report at a later time. The report will be available in the section "Authored Reports".

Here is a screenshot of such a report:

 

I had some trouble with linking the host instance name with the process name, so that's the main reason why I wrote this blog item.

I hope this saves you a lot of trouble :)

Posted in: BizTalk | Monitoring | SCOM

Tags:


January 6, 2012 at 12:25 PM

Recently, we've encountered some problems with SCOM 2007 R2 monitoring of a BizTalk 2010 environment. The SQL Agent Job "Backup BizTalk Server (BizTalkMgmtDb)" failed, but we didn’t receive any SCOM alert about that.  The first reflex was to look at the BizTalk Management Pack.

 

BizTalk Server Management Pack

The BizTalk Server Management Pack contains a rule, called “CRITICAL ERROR: A SQL Server agent job failed - Backup BizTalk Server”, which is responsible for alerting us in case of troubles.  The rule is disabled by default, but we had already enabled the rule with an override.

 

Why didn’t we receive an alert?  We had a closer look at the default rule and discovered that this is the way of identifying the backup job failure:

-    It’s a rule that subscribes on the event log [TypeID="Windows!Microsoft.Windows.EventProvider"]
-    It looks for event log entries with ID = 208 [EventDisplayNumber equals 208] in the Application log
-    The computer name is set to $Target/Property[Type="Microsoft.BizTalk.Server.2010.ServerRole"]/ComputerName$

 

When the error occurred, we indeed discovered event log entries with ID 208 on the SQL server.  But this rule is subscribing on the event log of the BizTalk server.  Conclusion: the default rule will only work on a single box installation (SQL server and BizTalk server have the same event log).

 

To solve this issue, we’ve created a custom rule, based on the default one.  The custom rule had exactly the same configuration, except for the computer name that we’ve changed to:
-    “$Target/Property[Type="Microsoft.BizTalk.Server.2010.BizTalkGroup"]/MgmtDbServerName$”

Now the rule was subscribing on the event log of the SQL Server (running the ManagementDb), and we received an alert when the backup job failed.  This worked fine, until we deployed this rule against a multi-server BizTalk environment, containing a SQL Server cluster.  Suddenly we’ve received SCOM errors, complaining that the SCOM Agent couldn’t access the event log of the MgmtDbServer.  The cause of this is that the BizTalk Management Pack actually discovers the virtual SQL Server Cluster name.  As this is not a physical server name, it’s normal that the SCOM Agent can’t access the event log.

 

To overcome this issue, we could have created a new custom rule, which uses the discovered MgmtDbServer and performs a query on the [msdb].[dbo].[sysjobhistory] system table.  The sysjob tables contain all needed information to detect SQL Agent Job failures.  As this is too complex, we decided to have a look at the SQL Server Management Pack.

 

SQL Server Management Pack

As it is actually a SQL process that fails, the SQL Server Management Pack should be responsible for alerting us.  But why didn’t that happen?  There are actually two reasons for this:

-    The discovery of SQL Agent Jobs is disabled by default.
-    The alerting for SQL Agent Job Failures is disabled by default.

We enabled the discovery and alerting, tested the solution and everything went smooth.

 

Conclusion

SQL Agent Jobs should be monitored by the SQL Server Management Pack.  This Management Pack should always be installed in a BizTalk environment, as SQL Server is the core of BizTalk.  Please, keep in mind that the alerting of SQL Agent Jobs is disabled by default.

 

It’s actually a strange approach of Microsoft to try to include the monitoring of the SQL Agent Jobs in the BizTalk Server Management Pack.  Certainly because the default implementation only works for a single box installation.  On MSDN you can find a vague description on this subject.

Toon Vanhoutte