We've been using AppMon in our data center for over a year, across a large number of Java agents. Most recently, we added a new instance of an existing application, where the only difference between it and its peers is that the host's static hostname was defined as a fully qualified domain name, rather than a simple host. When we started up the application, AppMon saw the agent and the host, but it didn't collect any data. The Host Information dashlet contained the host information at the top, but it received no CPU, memory, networking, or disk data. Similarly, the process was there and showed no errors, but it didn't send over any PurePath or PureStack data.
The only way we got past this problem was by changing the agentpath line to include an overridehostname attribute, where we removed the domain from the host name. That worked, but it's a poor option for us since we want to use a common startup configuration for all of our application instances.
Is there any reason why agent data doesn't get transmitted if the agent host uses a FQDN? Is there a more generic setting we can change to allow this without having a custom agentpath for every agent?
Have you logged into the collector and made sure that the collector host can reach the FQDN?
It seems like a case where the communication is one way only (agent to collector).
You could check the Deployed Sensors tab on the Agents Overview dashlet also to see if there are any sensors deployed. My theory being there will be none deployed because the collector cannot communicate to the agent.
The collector log should also give clues if this is the case.
Hey, Dave! Long time no speak!
I logged in to the collector and was able to SSH to the agent box using both the FQDN and the simple server name. They're in the same subnet with no intermediate firewall, so there shouldn't be a connectivity problem.
I did notice a bunch of other problems in the collector log, though, related to support ticket we're trying to work through. Between a barrage of warnings with the ClusterTimeProvider (Exception synchronizing cluster time: COMMUNICATION_ERROR) and some issues with Proxy classes being instrumented for some reason, the FQDN may end up being a red herring. We're going to keep working on the support ticket before trying to reconnect the agent with its FQDN.