When attempting to add multiple Azure SQL databases with identical names but hosted on different logical servers in separate regions, Foglight reports that the database is already being monitored or the message "agent configuration failed" appears in a popup. This occurs even though the databases reside on different hosts with unique IP addresses and server names.
Example:
Primary: sql-primary-server.database.windows.net, database: myapp_db
Secondary: sql-secondary-server.database.windows.net, database: myapp_db (geo-replicated)
Attempts to add a monitoring agent for the secondary result in a duplication error or are blocked.
CAUSE 1
Azure SQL Database geo-replication creates read-only secondary databases that are logically linked to their primary counterparts. These secondary replicas share a number of identifiers with the primary. As a result, it does not support monitoring secondary databases independently when they are part of a geo-replication topology.
CAUSE 2
Overriding the display name when creating the monitoring agent and using common names between multiple database agents
Some users have been successful at monitoring secondary replication databases however the Azure SQL agent currently does not support independent monitoring of geo-replicated secondary Azure SQL Databases. Monitoring the primary database is sufficient for capturing performance metrics and health indicators relevant to the database instance.
The recommended approach is:
Configure monitoring agents only for the primary Azure SQL databases.
Do not attempt to monitor the geo-replicated secondaries separately, as they are read-only and not treated as distinct entities in Foglight's discovery and monitoring logic.
Users who still however attempt to create agents for secondary database monitoring are recommended not to override the display name when creating the database agent.
Secondary replicas are read-only and receive data asynchronously from the primary.
Metrics from secondaries are generally not critical for performance monitoring as no user workload is executed on them.
For disaster recovery planning or failover validation, the primary database monitoring should provide sufficient insight into replication health (e.g., using sys.dm_geo_replication_link_status).
