Is it possible to monitor SQL Server AlwaysOn Availability Groups using the listener address with the Foglight SQL Server agent?
Monitoring Availability Groups via the listener is not supported in Foglight due to several technical and operational limitations. Listener addresses can redirect to whichever node is primary but do not provide direct access to all nodes and their individual health. This results in major drawbacks for failover awareness and metric accuracy.
Foglight does not support monitoring SQL AlwaysOn Availability Groups via the listener address.
Instead, configure monitoring for each SQL Server instance (node) individually, using their explicit host or IP address.
Why monitoring by listener is not supported:
Failover alarms won’t work correctly
Listener monitoring cannot reliably detect which instance is currently primary or secondary. Accurate failover alerts require monitoring individual instances.
Confusing and Inaccurate Topology Data
Data collected through the listener might combine metrics from different physical hosts over time. This makes historical performance and root cause analysis unreliable.
OS and Database metrics mismatch
Example: After a failover, database metrics from the new primary will not match OS-level metrics from the original host, leading to data inconsistencies.
Completed AG Membership
An instance may be primary in one Availability Group and secondary in another at the same time. Listener monitoring cannot disambiguate these roles.
Not All Databases are AlwaysOn Members
Some databases in an instance may not participate in any Availability Group. Monitoring via listener omits essential local metrics for those databases.
Recommendation
Always configure monitoring at the instance node level:
Note
Listener-based discovery is technically convenient for clients, but not for database monitoring solutions that require reliable, host-by-host health and topology tracing—especially in audited, production environments.
