There are several behaviours that may indicate duplicate agent topologies such as:
If you suspect that there might be duplicate agent topologies, you can run the below script in the Tooling - Script Console.
It will print out a list of the duplicate topologies found.
For Oracle Agents please run the attached script: DBO_check_duplicates_0.groovy
For SQL Server Agents please run the attached script: DBSS_check_duplicates_0.groovy
If nothing is printed out, then no duplicates would exist; however, if output is generated, you would have to fix the duplicates using the steps below.
In the DBSS and DBO database cartridges, there is a NSLOOKUP hardcoded in the database discovery process. As the discovery process was completing, an nslookup would run against the server name and whatever was register in the DNS was associated with the database agent.
In circumstances where the servername and the DNS entry may have differed, this could cause duplicate topologies in the Foglight system. Two separate sets of Foglight data were being captured and stored by the system. The system would then have difficulty reconciling which topology was the correct one.
Starting from version 220.127.116.112+ the NSLOOKUP is replaced with hostname.
If these issues exist, you would have to first upgrade to a cartridge version with this fix and then follow the steps below to fix the agents in question.
Newly created agents 5.6.4 and on should, by default, not use the NSLOOKUP any longer.
This can be fixed by deleting the duplicate topologies and disabling the NSLOOKUP.
The process for this, after confirming that the duplicate topologies are indeed present, is:
The scripts attached for this solution is only for Agent_Model, in order to check which type, check the value under the Data Type column.
There can be two types (Cluster_Model or Agent_Model).
Please, go to Configuration | Data | Management Server | All Data | DBSS_Data_Model or DBO_Data_Model | Clusters | please create a screenshot illustrating the Data type column with the duplicated hostnames.
If it's Cluster_Model type, create a case for support with the FGLAM support bundle
and screenshot in order to investigate. If it's Agent_Model the user just needs to run the attached scripts on this solution.
Please note, that in order to disable the NSLOOKUP using the script above, you would have to be at version 18.104.22.1682 or newer.
Otherwise, you would recieve error's similar to the below when running the script:
ERROR:Failed to update agent <agentname> for the following reason: Field monHostUseNslookup is not found
The script does the following:
The script does not support the following configuration: two DB agents monitoring instances on the same host, while in their ASP the monitored host names are different. For example: israix07, israix07.prod.quest.corp, or its IP address.
The customer should take the following steps: