The default data center is, "The classification for any server that has not been assigned to an explicit site." This means that once you add those servers to a site, it should be associated with a more meaningful name.
Here is the information you are looking for, sometimes links are marked as internal and that could be why you didn't find them.
You should be able to access the site information from the Admin console:
server_IP_addressis the CAS IP address.
Here is the video link: https://university.dynatrace.com/videos/10571
Here are some notes in the documentation: https://community.dynatrace.com/community/display/DCRUMDOC/Site+definitions
Thanks. The University link is to a page that shows how to intellectually define a site, not how to use DCRUM to define it. The documentation link does not contain any other links to show step-by-step how to define it. I was having trouble with the IP address range (as there is no adequate documentation); trying subnet mask, CIDR notation, etc. Finally the "-" in between the start and end IP address worked, but only when I removed all spaces between the start and end IP's. Proper documentation would have helped.
As another issue with sites. I've created 5 sites for different IP ranges in our DC. However, in the Server Name of a new DMI report I still see "Server from 10.35.15.0/24" even though I have a site with the IP address range 10.35.0.0-10.36.255.255 defined.
Just as an FYI. I am having multiple issues with re-transmissions and have created a report to show which servers are "supposedly" having this issue. I say supposedly because it appears to be an issue with the "wrong" duplicates being eliminated by are de-dup process in the network packet broker. The NPB receives SPAN traffic from numerous Vlans and we are seeing numerous duplicates. I believe the wrong duplicates are being removed (i.e., packet 4 that is only .1 ms timestamp from packets 3 & 5 is removed; while packet 4 that is 100 ms timestamp difference is saved). The AMD notices this difference and treats packet 4 as packet loss and a re-transmission. We know that the volume of re-transmissions indicated in the reports is not valid because our users would be beating our doors down if they were truly experiencing 30%-80% (or more) two-way packet loss.
Thanks for your assistance thus far. Any ideas on the packet loss?
Thanks and God bless,