Geeks With Blogs
BizTalk Monitoring
Part 1: BizTalk Monitoring Engine Overview
There are a few products on the market today that provide monitoring capabilities for BizTalk Server. So, in a market that provides seemingly abundant choices, what makes Minotaur special? What differentiates Minotaur from its competition? This post delves into the details of what makes Minotaur the leading choice for monitoring BizTalk Server enterprise solutions.
Agent-less deployment
Minotaur was designed to perform its monitoring services from a central service. The product does not require agents to be installed on the servers to be monitored. This is for ease of deployment and to reduce the number of dependencies for the software.
No BizTalk API dependency
Minotaur is not dependent on the BizTalk API; therefore you do not have to install the product on a server that has the administration console installed. Minotaur uses a combination of WMI, operating system functions and direct communication with the BizTalk databases to provide its monitoring services. All communication with the BizTalk databases is non-intrusive and is done via safe interfaces.
Not just a BizTalk monitoring tool
Minotaur is not just a BizTalk monitoring tool. It is also a server, service and application monitoring product. One of the key objectives of Minotaur and what makes it so powerful is the fact that once you registered your BizTalk group, you can configure Minotaur to also monitor other applications and services that your BizTalk application depends on or is dependent on.
Let us for example say that you have an external service which provides some sort of a proprietary business function. The service writes to the application event log and must be in the started state for your BizTalk application to function. The service is also dependant on an operational database. You can configure Minotaur to monitor the application event log on the server the service run on, you can also monitor the service state, the disk space the service and the operational database runs on (servers running out of disk space is a contributor to service and application downtime!) and the operational database as to ensure that the database is accessible and that there are no lingering locks that can cause problems. In other terms, you can monitor all metrics around the service as to ensure it stays available and does not impact your BizTalk applications.
Persistent data store
Minotaur has its own persistent data store, where it saves the metrics that it gathers. Minotaur is not dependent on any of your BizTalk operational agent job settings. If your BizTalk environment is configured to only keep data for a specific amount of time, you would not be able to report on that data outside of the specified time. Minotaur allows you to report and draw analytical graphs on all historic monitoring data.
Proactive and reactive monitoring
Minotaur will not only notify the administrators and operators that has subscribed to events of failures, it will also issue notifications on thresholds. This will ensure that your operational team can stay in control of your end to end solution by ensuring that they are notified when certain thresholds are violated. For instance, Minotaur’s performance (perfmon) monitor will issue a notification if your server CPUs operates at 100%. An operator can then investigate this phenomenon, as this can cause the operating system to deny any connections to the server.
The disk monitor will ensure that your operators are notified when a server’s disk space drops below a certain threshold. If a server runs out of disk space, it will cause your database server to run out of space for TempDb, causing the database to become unavailable. On an application server no available disk space would surely mean application or service unavailability as there is no space to write to logs or for the page file to grow.
 The health monitor feature on BizTalk objects also allows your operators to see when last that specific BizTalk object processed any kind of message. In an application where a specific receive port should receive at least 1 message every 30 minutes, this monitor could highlight a problem with a trading partner if no message has been received for an hour.
The SQL agent job monitor will ensure that all the required SQL agent jobs are running regularly. A failing SQL agent job can cause havoc on any BizTalk solution after a certain amount of time. Minotaur will issue a notification if it finds any disabled, stopped or failing SQL jobs associated to the BizTalk environment.
All in all, Minotaur has the following monitors:
·        Suspended queue monitor
·        Orchestrations
·        Receive Locations
·        Send Ports
·        Activity / Health Monitor
·        Host Instances / Services
·        Database Read
·        Database File Size
·        Database Locks
·        SQL Agent Jobs
·        Disk Space
·        Performance Monitors
·        Event Logs
I will venture into the details of each of these monitors in subsequent posts.
Ability to configure more monitoring
Along with the standard out of the box monitoring, Minotaur allows you to configure any additional monitoring using the existing monitors as long as it is within the licensing parameters. You are not constrained to the monitoring provided with the product. Using the event log, performance monitors your custom application can plug right into the monitoring capabilities that Minotaur provides.
Notifications Engine
Minotaur’s supports notifications via a subscription-based engine, whereas subscribers are notified via email of any failures or threshold violations. But in addition to that the product also supports positive notifications, whereas Minotaur keeps monitoring a failed item and will notify the subscriber when the item becomes available once again. The positive monitor is only available on certain types of monitors.
Dashboard
Minotaur has an ITIL-style dashboard, with a real-time view of the entire monitored environment. The dashboard is green-yellow-red light based where green means “all-ok”, yellow means a threshold has been violated and red indicates a failure. The operators can then click on the light in question to obtain detailed information.
 In part 2 of this blog post series, I will delve deeper into each monitor and discuss the intricacies surrounding the monitors.

 EMail: sales@ragingbulltech.com

Web: http://www.ragingbulltech.com

 

Posted on Monday, December 7, 2009 12:21 PM | Back to top

Copyright © BizTalkMonitoring | Powered by: GeeksWithBlogs.net