Host Instances

Setting up monitoring for Host Instances

1. Log in to the BizTalk360 application
2. On the Environment page select Manage Environment which will redirect to the respective environment
3. Navigate to Monitoring -> Manage Mapping->BizTalk Environment->Host Instance 
4. Select the Alarm name (see Manage Alarms) from the drop-down for which you would like to associate the alerts
5. Select the checkboxes against the Host Instances that you wish to monitor
6. Set the value of 'Expected State' by selecting a value from the drop-down. For instance, if you want the state of the host instances to be Started, you need to set the value in the drop-down to 'Started'. In case the host instance is no longer in the Expected state, this will trigger a notification to the configured id.

Monitoring Clustered Host Instances

To achieve high availability for adapters that cannot have multiple host instances running at one point in time, BizTalk allows you to cluster hosts using Windows Failover Clustering. This will make only one host instance running for the clustered host and in case of any failure, it will failover by running the host instance in a different server.

BizTalk360 has the capability of monitoring clustered host instances. Setting up monitoring for clustered instances is the same as monitoring all other artifacts in a BizTalk Server environment. You need to create an alarm and associate the alarm with the artifacts, in order to be able to monitor the host instances. In this case, configuring monitoring for clustered host instances happens in the same place as normal host instances, under BizTalk Environment.

The clustered host instance is indicated with color code and clustered node symbol. Select the clustered nodes and set the expected state as either Exactly one Active to avoid downtime.  

Exactly One Active - The clustered host instance is monitored to make sure it remains running only on the active server. The user will be notified if the host instance running on the Active server is stopped.

If the Autocorrect is enabled for any of the clustered host instances then the BizTalk360 system will start the Active host instance automatically if it is stopped.

Monitoring Non-Clustered Host Instances

BizTalk360 also allows you to monitor non-clustered hosts in the same way as clustered host instances. To make use of clustered host instance monitoring with non-clustered hosts, the hostname should be the same.

Set Up Monitoring for clustered and non-clustered Host Instances:

1. Log in to the BizTalk360 application
2. On the Environment page select Manage Environment which will redirect to the respective environment
3. Navigate to Monitoring -> Manage Mapping->BizTalk Environment->Host Instance 
4. Select the Alarm name (see Manage Alarms) from the drop-down for which you would like to associate the alerts
5. Select the checkboxes against the host instances configured in High Availability Server (Active-Active), that you wish to monitor
6. Set the value of Expected State as 'AtleastOneActive' by selecting from the values from the drop-down. 

At least one Active -Monitor the host instance configured in High Availablity Server(Active-Active), ensuring that at least one host instance must be up and running always. The user will be notified if both the host instances are stopped.

When auto-correct is enabled for any non-clustered host instance, the system will automatically start any one of the host instances if both are stopped.

Auto-Correction

With the Auto-Correct functionality, administrators can set up monitoring on any State-based artifact and let the monitoring service try to automatically heal the artifact any time when there is a mismatch between the Expected State and the Current State. For instance, administrators can set up monitoring on the Host Instances and additionally set up the auto-correct functionality for the Expected State of the artifact (which should be 'Started'). Whenever the host instance gets stopped, there will be a mismatch in the state and the auto-correct will try to bring the artifact back to the expected state. If the operation is successful, the artifact will come back to the Expected State within the next monitoring service cycle (60 seconds).