by Saranya Ramakrishnan | Jan 6, 2020 | BizTalk Community Blogs via Syndication
In BizTalk360, we have a practice of releasing new versions with significant features in every quarter. In 2019, we have released 4 major versions. In this blog, you can get to know about the top 10 stimulating features we have shipped in 2019.
1. Send Port Group Operations and Monitoring
You can completely manage and monitor your Send Port Groups from BizTalk360.
Operations – Send Port Groups can be Start/Stop/Enlist/Unenlist from BizTalk360. With this capability, it is possible to manage the operation of BizTalk applications (Start & Stop) for all the artifacts of each application in BizTalk360.
Monitoring – Create an alarm, map the Send Port Groups for monitoring by setting up the expected state. If any threshold violation occurs, you will be notified. You can also setup auto-healing for this monitoring; once the Send Port Group goes down, then BizTalk360 will try to auto-heal it to the expected state.
This implementation makes life easier for the BizTalk support engineers without context switching between the BizTalk admin console and BizTalk360.
2. Database Size Monitoring
Database Size monitoring helps to monitor the Data and log file size of the BizTalk and BizTalk360 databases, by simply configuring the error and warning threshold values for the database and log file sizes.
Below are the BizTalk databases that can be monitor using BizTalk360:
- BizTalkDTADb
- BizTalkMgmtDb
- BizTalkMsgBoxDb
- BizTalkRuleEngineDb
- BAM databases (BAMPrimaryImport, BAMAlertsApplication, BAMArchive, BAMStarSchema)
- SSODB
3. SQL Server Cluster Monitoring
Cluster SQL Server can be monitored by configuring the SQL Server Network name. BizTalk360 will start monitoring the currently active node. In case of a failover, BizTalk360 will automatically take the active server for monitoring.
The following resources can be monitored by configuring the SQL Server:
- CPU & Memory
- NT Services
- Disks (available disk space)
- Event Logs
4. Host Instance Monitoring
BizTalk Host Instances(clustered/non clustered ) can be monitored by setting the Expected State as started/stopped/AtleastoneActive. An alert will get triggered if there is a mismatch between the expected and current state of the host instance.
The state AtleastOneActive will guarantee that at least one host instance is running and no downtime happened for that host/server.
You can also enable AutoCorrect for Clustered and Non-Clustered host instances monitoring.
5. Configurable Polling Interval for Monitoring
By default, the BizTalk360 monitoring service checks the status of all configured artifacts every 1 min. However, BizTalk360 provides an option for the user to configure the polling interval. Based on the configured polling interval, the monitoring service will determine the monitor status of the endpoints.
6. SMTP Notification Channel
The SMTP Notification Channel provides an ability to create email distribution lists by grouping email ids based on the business needs.
Easily using the same email recipients for multiple alarms was not possible in earlier versions; the recipient’s details need to be entered for each alarm. To overcome this, we have introduced the SMTP Notification channel, through which the user can configure email distribution lists under one channel and can be mapped to multiple alarms. In addition to this, we have added email grouping for Up Alert and AutoCorrect Alert. With this, the user can configure different email ids to receive Up and AutoCorrect alerts.
7. BizTalk Group Dashboard
In BizTalk360’s Monitoring dashboard it was not possible to view the status of all the mapped artifacts in a single view; the user needed to change the alarm each and every time to view the status of the mapped artifacts of each alarm.
To overcome this challenge, we have introduced the BizTalk Group Dashboard which gives a consolidated view of the status of all the artifacts which are mapped to all the alarms in an environment.
The “BizTalk Group Dashboard” will automatically pick up all the artifacts (which are mapped to any of the BizTalk360 alarms) and displays the status of the artifacts in a graphical manner. Also, the error/warning details of the displayed artifacts are shown in a grid view.
8. Subscriptions (Message Box)
In addition, to retrieve the service instance and message details, BizTalk360 allows users to execute queries to retrieve the details of the subscription from the message box database. The subscription details such as Name, Service Name, state, subscription type, service instance id will be retrieved on message box query execution.
9. APM Integration
BizTalk360 is a one-stop tool for operations, monitoring and application performance management (APM) of BizTalk environments.
We get to see a few of our customers utilizing modern SaaS-based Application Monitoring/Analytics platforms like New Relic, AppDynamics, Dynatrace, etc., for their global enterprise analytics/monitoring requirements.
To support that we have integrated the following tools in BizTalk360.
- NewRelic
- AppDynamic (new)
- Dynatrace (new)
BizTalk360 Analytics service will start pushing the BizTalk performance data to your environment. With this, you can see the BizTalk server related performance metrics such as BizTalk/SQL Server health, Host Performance, BizTalk Messaging Performance, Throttling Performance, etc., in AppDynamics and DynaTrace environment.
10. Analytics Data Collection Optimization
We have fine-tuned the performance in analytics data collection. To improve the performance and tracking data collection we are providing an option for the user to select the required performance counters on each type. This way, BizTalk360 will start collecting data only for the selected counters.
Reporting Improvements
BizTalk360 provides the option for users to be able to generate PDF documents of critical performance metrics at specific time periods depending on the business.
In BizTalk Reporting, we have introduced an additive widget called Custom SQL Query widget through which SQL queries can be mapped to get the top 100 query result as a report based on the scheduled configuration.
In addition to this, we have extended our support for Analytics custom widget. With this, you can retrieve performance metrics of the BizTalk environment such as Messaging Performance, Message Transmission failure rate, Server performance, etc., and the SQL Query results as a report. Based on the configured schedule you can receive that report in your email box.
Conclusion
Considering the feedback from our customers, BizTalk360 will continue to provide more useful features. Why not give BizTalk360 a try! It takes about 10 minutes to install on your BizTalk environments and you can witness and check the security and productivity of your own BizTalk Environments.
The post Top 10 Features of BizTalk360 Released in 2019 appeared first on BizTalk360.
by Sowmiya Subramanian | Oct 22, 2019 | BizTalk Community Blogs via Syndication
From the upcoming BizTalk360 version 9.0 phase 3 on, we extend our support to monitor SQL Server clusters. By configuring the SQL Server Network Name for monitoring, BizTalk360 will start monitoring the current active node and in case of failover scenario, BizTalk360 will automatically take the active server for monitoring.
It’s important to make sure the physical infrastructure of your SQL servers like disks, CPU, memory, etc., are healthy for proper functioning. BizTalk360 made this simpler by having the SQL Server Monitoring capability.
BizTalk360 will alert to the user when the configured disk space, CPU, memory usage exceeds the set percentage.
Challenge
In existing BizTalk SQL Monitoring, we came across a few challenges on monitoring the clustered SQL Server
- The user could not find the active node while monitoring the clustered SQL Server.
- When the Failover happens, the disk monitoring could not identify the disks of the failover node and an error message was displayed as below.
Scenario 1 (Active/Active): As the same as the previous version of BizTalk360, you can monitor the Clustered SQL Server (Active/Active) or a non-clustered SQL Server, by simply adding the SQL Server physical node in the “Add SQL Server For Monitoring”.
Scenario 2 (Active/Passive): In BizTalk360, you can monitor the Clustered SQL Server (Active/Passive), by adding the common “SQL Server Network Name” for the physical node into the “Add SQL Server For Monitoring”. It will automatically pick up the active server node for monitoring and then it will start monitoring the active node. If a Failover happens, then it will automatically switch to the failover node (Active Node).
Let’s take a quick look at how you can monitor Non-Clustered/Clustered SQL Server (Active/Passive) using BizTalk360.
Non-Clustered SQL Server
The BizTalk server database will be pointed to one SQL server Instance as below.
Failover Clustered SQL Server
Windows Failover Clustering is a high-availability option which is designed to increase the uptime of SQL Server instances. A SQL Server cluster includes two or more physical servers, called nodes. One is identified as the active node, on which a SQL Server instance is running the production workload, and the other is a passive node, on which SQL Server is installed but not processing the workload. If the SQL Server instance on the active node fails, the passive node becomes the active node and begins to run the SQL Server production workload with some minimal failover downtime.
The SQL Server Network Name is used to identify a failover cluster (active node) on the network. This was known as the virtual SQL Server name.
The virtual SQL Server will automatically connect to the currently active node. You can find the SQL Server Network Name as below in the Failover Manager.
Prerequisites or Permissions required to monitor the Non-Clustered/Clustered SQL Server in BizTalk360
- MSDTC should be enabled in the BizTalk360 server and SQL Server. In the case of Clustered SQL Server, MSDTC should be enabled in all the SQL Servers which belong to the cluster. Follow the link to enable the MDTC.
- If BizTalk360 is installed using the service account, then the service account should get added to the Administrator group in the SQL Server node. In the case of a Clustered SQL Server, the service account should get added to both physical SQL Server Nodes(active & passive node).
How the (Non-Clustered) SQL Server is monitored in BizTalk360
Let’s have a detailed look at how you can monitor a non-clustered SQL server using BizTalk360.
By adding the Physical SQL server name for Monitoring, you can monitor the disks, CPU, memory, etc. You can add the SQL Server name under BizTalk360->Settings ->Monitoring and Notification ->Add SQL Server for monitoring.
Note: For non-clustered SQL servers you must add the physical SQL Server name for monitoring.
Once the above configuration is done, the added SQL servers will get available for monitoring as below.
The configured server will be listed for monitoring under BizTalk360->Monitoring ->Manage Mapping->SQL Servers. By clicking on the Server name you can configure Disks, System Resources (CPU, memory), Event Logs and NT Services of the specific SQL server for monitoring.
Disk Monitoring
A click on the Disks tab, will automatically pick up all the disks in the configured SQL server and show a graphical view of the disk properties with total and available disk space. To monitor the disk, you can simply set the appropriate warning and error threshold level for each disk in percentage (%), as shown below. For more detailed information, follow the article link.
Note: The system reserved and the unpartitioned disk will not be available for monitoring.
System Resource Monitoring
Click on the System resource tab to monitor the CPU usage and Memory consumption. Next, configure the appropriate warning and error thresholds for CPU and memory. The system will start alerting if the system condition hits the configured warning/error level for the persisted duration, which you can see below. For more detailed information about the CPU and Memory, follow the article link.
By default, warning and error thresholds for CPU and memory will be in 30% and 10%, but you are free to reconfigure these thresholds depending on your own requirements
Event Log Monitoring
You can monitor for various event log entry conditions using BizTalk360. You can have multiple combinations of event log monitoring, for example, certain sources, certain event ids, certain text in the message, with configured threshold conditions as below.
Note that you can also set up Event Log monitoring in the Data Monitoring section. Setting it up there helps in correlating event log entries across multiple servers. For more detailed information about the Event Log monitoring, follow the article link.
NT Service Monitoring
You may want to keep an eye on certain NT services that are running in SQL Server. BizTalk360 gives you the opportunity to automatically monitor the NT services by just setting the expected state. BizTalk360 will alert you when the configured expected state is not equal to the current state. For more detailed information about the NT Services monitoring, follow the article link.
How a SQL Clustered node is monitored in BizTalk360
Now, let us have a quick look at how we can use BizTalk360 to monitor a clustered SQL server.
Configuring a Cluster SQL Server for monitoring
If you want to monitor a Clustered SQL Server, all you need to do is, specify the name of the Virtual SQL Server (SQL Server Network Name). When you connect to SQL Server using this SQL Server Network Name, BizTalk360 will automatically connect to the currently active node.
Note: It is is enough to add just the SQL Server Network Name for monitoring the SQL Cluster, it is not required to add the actual physical SQL cluster nodes.
Once the above configuration is done, then the added clustered SQL Server Name will get listed for monitoring as shown below.
It will automatically pick the active node and the state of the (clustered) server.
Disk Monitoring
In clustered SQL Server monitoring, it will show the currently active monitoring Node, and also it will automatically pick up all the disks in the currently active node.
By Default, warning and error thresholds for each disk will be in 20% and 10%. You can also change the warning and error percentage as per your need and save it. Then, the currently active node will get monitored by the BizTalk360. If the disk space exceeds the set percentage, BizTalk360 will send the alert to the respective user.
If the “Failover” happens for the monitored disk, then the configured disk will automatically switch to the active server(Failover server).
Consider a scenario if Node 1 has disk A and disk B which are configured for monitoring (error and warning condition as 50 %). Let say, Node 1 went down, then BizTalk360 will automatically pick up the currently active node 2 for monitoring. But what happens if node 2 has Disk B and Disk C?
In the above scenario, the default monitoring configuration i.e error and warning condition 20% is set to the Disk C. Disk A, which is available in node 1 but not in node 2 will be moved to the orphaned state.
As in the above screenshot, the “STR-Disk1 (F:)” disk is newly added after failover with the default warning and error conditions. The other two disks are “STR-Disk2 (E:)”, which is a shared volume, and the (C:) drive is a common volume, which is also configured with the existing warning and error percentages.
System Resource Monitoring
As the same as disk monitoring, you can set up appropriate warning and error thresholds for CPU and memory as per your business needs. For a Clustered SQL Server, it will show the current active monitoring Node. It will automatically pick up the CPU usage and the memory for the currently active node.
In the case of a Failover, the CPU and the memory will automatically get updated for the active node (failover node) with the existing warning and error conditions.
Event Log Monitoring
In a Clustered SQL Server, BizTalk360 monitors the Event Log based on the active node. You can have multiple combinations of event log monitoring, for example, certain sources, certain event ids, certain text in the message, with configured threshold conditions.
Once after Failover, then BizTalk360 automatically starts monitoring the existing event log conditions based on the currently active node (Failover node).
NT Service Monitoring
In a Clustered SQL Server, current monitoring will be based on the active server. It will pick up the NT services from the active server for monitoring as you can below.
Once after Failover, the configured NT service will automatically switch to the failover node and start monitoring.
Conclusion
Our objective with the monitoring aspect of BizTalk360 is to make it simple to configure, manage and use it on a day to day basis. The above SQL Server Monitoring will do that, and it will also do the automatic way of monitoring when a failover happens. There is plenty to consider when planning on clustering SQL Server, but we trust that we came up with the best solution. For any suggestion or feedback, post it in the feedback portal.
The post SQL Server Monitoring in BizTalk360 appeared first on BizTalk360.
by Vignesh Sukumar | Jul 25, 2017 | BizTalk Community Blogs via Syndication
BizTalk360, being a Middleware monitoring tool, it must deal with a lot of message transfer between different systems of BizTalk Server. In a typical enterprise level scenarios, the cluster of systems plays an important role in high availability. The Communication between different server systems happens from Server to a network and then to another system via ports/protocols.
In a typical StandAlone (or) High-Availability monitoring scenarios where BizTalk360 is installed on a server different from actual BizTalk server. This enables the BizTalk Server to be monitored on 24×7 without any downtime on monitoring. Even if the BizTalk physical server goes down, BizTalk360 can send the down alert. This blog summarizes the basic ports/protocols that need to be granted an access to receive or send a message across the interconnected systems.
As this is the best practice to install the BizTalk360, we need to make sure the BizTalk360 running servers should be enabled with below protocols/port number in the Windows Firewall to communicate with the BizTalk Server/Azure/any external services at runtime. Below is the list of basic ports/protocols utilized for all the features/services.
SQL Server:
As BizTalk Server Relies on the SQL server databases, connection to the SQL server is critical to fetch the Artifacts/any results via direct query or through BizTalk ExplorerOM. This SQL connectivity is responsible for a majority of the below functionalities.
Database responsible for the above functionalities includes the below BizTalk databases and also BizTalk360 database.
DTC/WMI Port
BizTalk360 communicates with other windows services with the help of Windows Management Instrumentation. MSDTC- Microsoft Distribution Coordinator is responsible for moving the transaction from one system to another system. Make sure the Network DTC is also switched on to communicate with other remote servers and MSMQ. Also make sure MSDTC, WMI and RPC windows services are up and running.
Useful Microsoft Links
As the BizTalk360 server requires the same level of permissions like BizTalk server and the usage of the ports/protocols are pertinent to the Business architecture of every client, the below Microsoft links provides the port level segregation for different features that must be enabled on the Firewall to make BizTalk360 monitoring work seamlessly
Random/Custom Ports:
At run time, TCP ports are randomly picked up by the server, make sure the dynamically allocated ports are also being unblocked by the firewall. Also, make sure if custom ports are utilized for any service, unblock that as well from the firewall for the seamless working. Please refer Microsoft article for guidance. For firewall security recommendations please visit this msdn-link.
Summary
BizTalk360 provides continuous support and suggestions to make the monitoring at your ease. This blog was one such effort to make sure our BizTalk360 users seamlessly follow best practices to make BizTalk monitoring an easier one.
Author: Vignesh Sukumar
Vignesh, A Senior BizTalk Developer @BizTalk360 has crossed half a decade of BizTalk Experience. He is passionate about evolving Integration Technologies. Vignesh has worked for several BizTalk Projects on various Integration Patterns and has an expertise on BAM. His Hobbies includes Training, Mentoring and Travelling View all posts by Vignesh Sukumar
