Best Practices for BizTalk360 Alarm Configuration

|  Posted: August 1, 2019  |  Categories: BizTalk360

After the installation of BizTalk360, the implementation phase starts. One of the steps you will want to do is taking benefit of the rich automated monitoring features the product provides. For that, you must set up alarms in BizTalk360. In this article, we intend to give you some best practices around Alarm Configuration. Firstly, however, we’ll shortly explain the different monitoring concepts which are available in BizTalk360.

A short explanation of the supported monitoring types

BizTalk360 has multiple types of monitoring, which are Threshold monitoring, Health Monitoring, and Data Monitoring. Each alarm you create in BizTalk360 can support all types of monitoring, either as separate alarms or as combined alarms.

Threshold-Monitoring

As you can see from the above screen, BizTalk360 enables you to configure an alarm for multiple purposes. So, in case you want the same people to receive the same notifications for both Thresholds as for Health Checks, you only need to create one alarm.

Threshold monitoring 

With this kind of monitoring, you get notified in case a threshold occurs. For example, that can be a Receive Location which was Disabled, while it should be Enabled or any other artefact which is mapped in an alarm and is in an unexpected state. 

At the Alarm creation level, you can configure the following:

  • Name – each alarm needs to be given a name. The more descriptive the name, the easier it is for identifying the purpose of the alarm
  • Description – optionally, you can provide a detailed description of the purpose of the alarm
  • Email Ids – each alarm can send notifications to multiple recipients
  • High Priority – in case you want specific notifications (for example when anything goes wrong with the BizTalk platform) to jump out in your email box, you can enable the High Priority switch
  • Violation persistence – to configure after how much time and with which interval you want to be notified of exceptions
  • Limit the number of notifications per exception – to prevent you from being bombarded with notifications and lose the overview as a result
  • Back to Normal notification – receive a notification when the alarm no more contains artifacts in the wrong state
  • Alert reset – start receiving notifications again after a specific time in case you have received the maximum number of notifications
  • Alert schedule – configure when the alarm should perform monitoring. Handy when you know that specific artifacts are not available all the time, due to, for example, maintenance

Health monitoring 

It can be helpful if you receive a report with the actual status of the monitored artifacts, for example at 9AM every business day. For such scenarios, you can configure alarms for Health monitoring.

BizTalk360 Health Monitoring alarms allow you to easily configure when you want to receive these status reports via an intuitive interface.

Below screenshot shows the screen where you can select when you want to receive these status reports.

health-monitor

This alarm has not only been configured to send a report at the beginning of each working day but also towards the end of the business day. This helps in being aware of the status of your environment before you leave home.

Data Monitoring

A detailed explanation of Data Monitoring falls outside the scope of this article, therefore we provide a somewhat better overview of its capabilities here.

The concept of Data Monitoring allows you to set up monitoring of your data flows. As an example, your BizTalk platform and applications might be in perfectly good health, but when a misconfigured firewall prevents messages from arriving in BizTalk, no processing will be taking place. This interrupts your business processes, with maybe bad consequences for your company. Data Monitoring can be used to monitor this kind of scenarios.

Data Monitoring provides monitoring at the following levels:

  • Process Monitoring – monitor whether your processes run as expected
  • MessageBox Monitoring – monitor the active processes and (optionally) take automated actions
  • Tracking Data Monitoring – monitor completed processes
  • BAM Monitoring – monitor your deployed BAM Views and Activities
  • EDI Data Monitoring – monitor your EDI processes
  • ESB Data Monitoring – monitor your ESB Exceptions and resubmissions
  • Logic Apps Monitoring – monitor tens of metrics about the processing of your Azure Logic Apps
  • Event Log Monitoring – monitor your consolidated Event Log entries of your BizTalk and/or SQL servers

After selecting which kind of Data Monitoring you want to set up, it now comes down to configure what exactly you want to monitor and when monitoring needs to be done.

Below screenshot gives an example of Process Monitoring.

process-monitoring

Once you have set up Data Monitoring, the output of all the different monitor runs will be shown in a consolidated Data Monitoring dashboard. This dashboard helps in answering the questions from your business/functional users whether a specific process has taken place.

data-monitoring-dashboard

You can refer to the Data Monitoring section in the Documentation portal for a more detailed explanation of this way of monitoring in BizTalk360.

Some more information about BizTalk360 Alarms can be found here.

BizTalk platform versus BizTalk application monitoring 

When setting up monitoring in BizTalk360, it is handy to make a difference between monitoring the actual BizTalk platform and the BizTalk applications which are deployed on it. Making this distinction gives several advantages, like:

  • Notifying different people, depending on their role and needs
  • Use different monitoring settings like:
    • The monitoring interval for early notifications in case of important issues
    • The number of notifications you want to receive per exception
    • Receive a ‘back to normal’ notification in case everything is healthy again
    • Set the High Priority flag to easily spot important notifications in your email box
    • Run PowerShell scripts for immediate actions

Even within platform monitoring, you can make segregations for different administrators. For example, a SQL Server DBA has different needs than a System (Windows) Administrator, so other artefacts need to be monitored. BizTalk360 enables you to set up different Alarms for different needs.

What to setup for Platform monitoring 

When you are creating an alarm for platform monitoring, you want to be notified of unexpected situations which might occur on your BizTalk platform. For this purpose, you will create a Threshold Monitoring Alarm. If you also want to receive a daily status report at say every business day at 8:00 AM, you can configure an alarm for Health Check Notification.

See below for a list of artefacts you could consider for monitoring BizTalk platform health:

  • Host Instances (clustered and non-clustered)
  • Host Throttling
  • BizTalk Server availability
  • SQL Server Jobs
  • Windows NT Services
    • Enterprise Single Sign-On service
    • Internet Information Services
  • BizTalk Health Monitor output
  • Eventlog entries
    • BizTalk Criticals, Errors, and Warnings
    • SQL Server Criticals, Errors, and Warnings
    • ESSO Criticals, Errors and Warnings
    • Internet Information Services Criticals, Errors, and Warnings
    • Server restarts
    • Certificate expiration
  • BizTalk and SQL related stuff
    • Disk space
    • CPU/Memory usage
    • Windows NT Services

Below screen shows the Monitoring Dashboard for a Platform alarm.

monitor-dashboard

What to setup for BizTalk Application monitoring 

Before we move to discuss which artifacts to monitor from BizTalk Application alarms, let’s firstly discuss how to organize your BizTalk Application-oriented alarms. Basically, there are two ways you can set up your BizTalk Application alarms.

The Alarm equals Application approach

When deploying BizTalk applications, it is often handy to create an alarm per BizTalk application for Threshold Monitoring and/or Health Check Notification. The main motivation for this is, that a BizTalk Application is the unit which you will deploy, so setting up alarms around them will help in keeping the overview. For easy reference, you could give the alarms the same name as the BizTalk application it will be monitoring. This can be considered as a bit more technical approach for your monitoring.

The Alarm equals Interface approach

Another approach to set up your BizTalk Application-oriented alarms is around the interfaces which are being processed by BizTalk. Say, your BizTalk environment contains multiple applications of which several their contained artifacts together are part of a Purchase Order. To keep the overview of such an interface, it makes sense to monitor all artifacts related to that interface. This is totally fine and BizTalk360 allows you to set up your alarm in such a way. Ideally, you can give the alarm the name of the interface. This approach is a bit more business-wise way of monitoring and can be helpful if you need to notify your business/functional users in case of any issues.

However, there is a downside to monitoring your BizTalk artifacts around interfaces. Because artifacts from multiple BizTalk Applications need to be monitored, it might be a bit harder, especially when many artifacts are involved, to keep the overview and be sure that you are really monitoring all the relevant artifacts.

No ‘Always Right’ way

Summarizing, there is no ‘always right’ way to set up your BizTalk Application monitoring. Even a ‘hybrid’ setup, which follows both just mentioned practices, of your monitoring is totally fine and not uncommon. In the end, it all depends on what works the best for you and your organization. BizTalk360 gives you all the freedom you need.

Artifacts to be monitored

When setting up monitoring for your BizTalk Applications, you will set it up for your ports and orchestrations of your BizTalk Applications. However, you can also consider the following artefacts for monitoring: 

  • State of Services Instances
    • Suspended (Resumable/Not Resumable)
    • Active
    • Dehydrated
    • Ready to Run
    • Scheduled
  • Endpoints of your Receive/Send ports
    • Web Endpoints
    • Queues (MSMQ, IBM MQ, Azure Service Bus)
    • File shares
    • FTP sites
    • API Apps
    • Logic Apps

Tip: To be able to find out if files/messages are being picked up, you can monitor your File shares, FTP sites, and Queues. Below screen shows an example of monitoring a File share.

file-monitoring-configuration

As a side note, BizTalk Server Best Practices suggest that you have a proper Host configuration in place, where separation takes place based on receiving/sending messages, processing of orchestrations and tracking of processed messages/service instances. However, sometimes Host configuration has been set up for a specific process or BizTalk application. In that case, it is valid to monitor your Host Instance(s) in your BizTalk application-oriented alarm, instead (or on top) of your BizTalk platform alarm.

Advanced Monitoring setup

Besides deciding on how to setup your alarms and which artifacts to monitor, there are a couple of other topics you could consider take benefit of. You can think of:

  • Auto-Correct – the ability to automatically recover artifacts
  • Notification Channels – inform people not just via email but also via different channels
  • Customized Notification Templates – provide additional information or brand the templates

Using such features not just makes your life as an administrator easier, it will also help you in making the best of your investment in BizTalk360. Let’s have a better look at all these options.

Auto-Correct

For state-related artefacts like BizTalk Ports and Orchestrations, Host Instances and SQL Server jobs, you could consider using the Auto-Correct feature, which, after a threshold situation has been met, tries to get the artifacts back to the expected state.

Tip: You can use this feature to automatically Enable your Receive Locations, in case they failed to connect to their endpoints due to a temporary failure!

You can read more about the Auto-Correct feature in this article.

Below screen shows that BizTalk360 will try to automatically try to recover the Host Instances once they are no more in the Started state.

BizTalk360-host-instance

Notification Channels

The default way of BizTalk360 for sending notifications is via email. However, sending notifications does not end there. The product has a number of so-called Notification Channels you can use. Examples are:

  • Slack – send notifications to a Slack channel
  • ServiceNow – have tickets created, directly in ServiceNow
  • Microsoft Teams – send notifications to a Teams channel
  • PowerShell – trigger a PowerShell script to perform an action
  • SMTP – have more control over the way notifications are being sent
  • Webhook – connect to an already existing REST API

Besides this rich set of notification channels, there is also an easy to use API at your convenience. By implementing the API, you can, for example, connect to your ticketing system or other important backend systems.

Below screen shows the information you can provide when using the ServiceNow Notification channel.

ServiceNow

More information about all the Notification channels can be found here.

Customized Notification Templates

BizTalk360 allows you to customize the notifications it sends. This allows you for example to provide some additional information/instructions for the people who receive the notifications. However, it can also be used for branding purposes.

Although some notification information can simply be provided via text input fields, the actual templates are based on XSLT, so some skills with editing such files will be helpful.

More information about customizing the notification templates can be found here.

Conclusion

With this article, we intended to provide you some help and guidelines with setting up your alarms. Both the Documentation portal and our Blog contain many articles on monitoring your BizTalk environment with BizTalk360. However, if you feel you need some more support with setting up your monitoring, feel free to reach out. We are here to help you!

Author: Lex Hegt

Lex Hegt works in the IT sector for more than 30 years, mainly in roles as developer and administrator. He works with BizTalk since BizTalk Server 2004. Currently, he is a Technical Lead at BizTalk360.

Back to Top