BizTalk360 Monitoring – Approaches for creating alarms

I have been helping a few different clients recently with configuring the monitoring for their interfaces and thought I would document some of the approaches I have gathered so far. These clients all happen to use BizTalk 360 and thankfully it is very flexible when it comes to configuring the monitoring of interfaces.

 

One creates something called an “alarm” that is configured with all the components of a solution that one wishes to monitor. The alarms can be as granular or as "coarse grained" as you like. For example: On one end of the spectrum, an alarm could include everything that solution consists of; all the applications and components (including elements of the platform like, disk, memory, etc.) all the way to the other end of the spectrum where a dedicated alarms could just monitor one component, like just a send port.

 

So how should you setup your alarms for your environment? The answer is, as always, "it depends…"

 

Some of the factors that influence how one creates an alarm are the following:

  • 1)  The structure of your solution - How are the components organised/grouped? One application or multiple applications. Are any of the applications shared (referenced by others)?
  • 2)  The size of your solution - How many interfaces does it consist of (how many external systems/endpoints does it interact with)?
  • 3)  The recipients of the alerts (notification emails) generated by each alarm - Who should be notified when an alert is raised for a particular alarm? More than one email address (and/or email distribution list) could be configured for each alarm.

 

I am sure that are other factors as well but let’s just cover these three factors in this post. I would be grateful to hear your thoughts on other factors and how they influence your decisions when setting up your alarms. BizTalk 360 doesn’t mind how the solution is structured and support a number of different configurations. Let’s take a look at a couple of scenarios to help explain the factors above.

 

I am sure anyone reading this, and who is familiar with BizTalk, will appreciate that solutions can take a number of different shapes and forms. One scenario could be where the entire solution, all components (BizTalk artefacts), are combined into one BizTalk Application. Another would be where the solution is divided up into on-ramps, off-ramps and common (shared) components and a separate BizTalk Application is created for each of these “groups” of components. Another would be where a separate BizTalk Application is created for each endpoint/system that BizTalk interfaces with. And so on.

 

Scenario 1: Single Application

 

An application could look something like in the diagram below. (Receive ports/locations are represented by the blue bits on the left, send port represented by the green/orange bits on the right and can you guess what represents the orchestrations?)

CGM BTS 360 1

With everything crammed into one BizTalk Application you could setup one alarm that monitors everything as shown in the following diagram.

 CGM BTS 360 2

The alarm, and its scope, is represented by the pink coloured blob covering/surrounding all the components (Think Venn diagram). Setting up an alarms in this could makes sense if there is only one team responsible for managing the interfaces in that application, and only one recipient (or single distribution list) is setup for that alarm. But it causes issues when multiple recipients are getting spammed with alerts for components of interfaces they don’t manage or support. So separate alarms are typically created that only contain the components or interfaces relevant to the team receiving the alert.

 

Scenario 2: Applications by logical groupings (on/off-ramp, etc.)

 

In the next scenario, a solution could consist of a number of BizTalk Applications where each application contains one off-ramp, process layer or off-ramp (and all the components that make up the on/off-ramp)

 CGM BTS 360 3

In the diagram above I have 3 discrete interfaces, namely: “A”, “B” and “C”. Each interface consists of an on-ramp, a process layer and an off-ramp. One could setup three different alarms for each individual interface end-to-end as shown in the diagram below. By “end-to-end” I meant that the alarms span applications and monitor everything that makes up that interface.

 CGM BTS 360 4

You can see that, if one interface goes down, only the alarm for the affected interface will be raised so you will know exactly which interface is down. Only the relevant team that needs to know about the state of their interfaces will be notified as well.

 

Scenario 3:  Applications for each external system/endpoint.

 

Suppose you have a BizTalk Application per system and some shared applications as shown in the diagram below. All messages from System A are routed through (and transformed in) some shared components before being “fanned out” to three separate subscribing off-ramps.

 CGM BTS 360 5

One approach could be to setup a separate alarms for each application as shown in the diagram below.

 

CGM BTS 360 7The above approach could work in scenarios where a different team need to be notified for each application when an interface runs into issues, and where some recipients don’t want to (or shouldn’t) be notified about issues with other applications that they don’t manage or support.

 

So, for example: System A’s support team don’t want to be spammed with alerts about issues in System D. Or System C might be an external supplier/partner and you don’t want them to know about issues in the System B interface, etc.

 

On limitation to this approach is that you can’t immediately tell which interfaces are affected by a component going down. The alarm will tell you which component is down but you will have to work out which interfaces are affected.

 

Another approach could be to setup alarms as shown in the diagram below.

 CGM BTS 360 6

Notice how the alarms all duplicate monitoring of the shared application (and/or components).

 

This approach helps in that if the shared components are “down” you can immediately tell which interfaces are affected because you will get four alerts (one for each interface). But if only one of the off-ramps is “down” you only get one alarm for that one system affected.

 

Hopefully the above examples have given you some scenarios to think about and approaches and factors to consider when configuring BizTalk 360 to monitor your environment. As I mentioned before, I would love to hear your thoughts and ideas on other factors and how they influence your decisions when setting up your alarms.

Written by Carlo Garcia-Mier at 00:00

Categories :

0 Comments :

Comment

Comments closed