We often get asked about the breadth and depth of Foglight when it comes to its monitoring scope.  Whether it support for a multitude of relational, open source and NoSQL database platforms or providing the depth needed to identify the root cause of performance issues, you are looking in the right place with Foglight.  For SQL Server in particular, one reassurance we can give our customers is a full complement of monitoring support for the entire ecosystem including the Database Engine, Services, High Availability, Disaster Recovery and Business Intelligence.  This includes the capability to monitor AlwaysOn Availability Groups.

AlwaysOn Availability Groups has become a tried and trusted feature since SQL 2012 and 2014 and the adoption has grown by leaps and bounds as it provides a powerful combination of database mirroring and failover clustering ensuring high availability and disaster recovery.  As our customers embark on modifying existing and/or rolling out new SQL Server deployments, more often than not many of the critical data now resides within an Always On Availability Group. 

For those of you that are not familiar with AlwaysOn or would like a quick refresher, I thought this link would be handy:

https://docs.microsoft.com/en-us/sql/database-engine/availability-groups/windows/overview-of-always-on-availability-groups-sql-server?view=sql-server-2017

From a monitoring perspective, what is important to any DBA is being able to assess the existing state and health of the Availability Groups (AG) while also remaining proactive.  DBA’s need to know if the AG is online, synchronizing, healthy and available. 

In the illustration above, Foglight is keeping track of the Estimated Recovery Time and Estimated Data Loss.  Estimated Recovery time indicates the time it takes to re-do the catch-up time.  The catch-up time is the amount of time it takes for the secondary replica to harden the logs and be in synch with the primary replica.  The Estimated Data Loss metric indicates the delta in time when comparing the last transaction log record in both the primary and secondary replica.  If the primary replica goes down, the transaction log records in that time window will be lost.   In environments that are highly transactional and have little or no tolerance to loss of data, these metrics are vitally important.

It is also important to stay proactive with alerting and Foglight has several out-of-the-box rules that can be configured to notify the DBA when something is amiss in the AlwaysOn environment.  Here is the complete list:

  • Availability Group Listener IP is not online
  • OS Cluster – Node is offline
  • Availability Replica is not online
  • Availability Group Database is not failover ready
  • Availability Replica is not synchronizing
  • Availability Group Database is not synchronizing
  • Availability Group Replica is disconnected
  • Availability Group performed a failover

For those of you that are looking to implement a comprehensive approach to SQL Server performance monitoring which includes capabilities for AlwaysOn Availability Groups, Foglight can help you remain proactive and ensure your system is healthy.

Anonymous
Related Content