Skip to end of metadata
Go to start of metadata

On this page:

Your Rating:
1 Star2 Star3 Star4 Star5 Star
20 rates


Why are there no connection metrics for a tier, node, or network link?

 Click here to expand...

Network Agents do not collect connection metrics by default.  The recommended workflow is to identify the link with the network issue and configure the relevant agents to collect metrics for the relevant connections. See Dynamic Monitoring Mode and Network Visibility.

The Network Agent cannot register with the Controller. What should I do?

 Click here to expand...

If a Network Agent cannot register with the Controller, do the following:

  • Check that the user account has a Network Visibility product license. 
  • If the user account has license rules defined, make sure these have the correct number of license units allocated. To change the number of allocated units in a rule:
    • Go to Controller Settings (gear icon) > License > Rules.
    • Edit the License Rule of interest. (There might be only one License Rule, named Default.)
    • In the General tab, set the Allocated Units field for the Network Visibility license and apply the change.

In some cases, I see that an application flow for a JMS queue goes in one direction but a TCP connection used by that queue goes in the opposite direction. Why is this?

 Click here to expand...

In most cases, the network links and TCP connections used by an application flow have the same direction (source –>  destination) as the flow itself. You might see different directions, however, if two tiers transfer data via a JMS queue. In some JMS implementations, the individual nodes in each tier initiate the TCP connection to the queue, so the direction is always:  

       node (source) –> queue (destination

Some of these connections might be used by an application flow in the opposite direction:
       queue (source) –> tier (destination

How do I change the Network Agent communications port?

 Click here to expand...

When you start the agent, the appd_netmon process spawns the appd-agent process. These two processes communicate over TCP port 3892 by default. If this port is already in use, you should see a log message about this in one or both files. To configure the agent to use a different port, do the following:

  1.  Use the netstat command to verify that the new port is not in use.
  2.  Update the Network Agent:
    1. Open the following file in a text editor: <network_agent_home>/conf/agent_config.lua
    2. Set the port option to the new TCP port number (under webserver_config). 

      webserver_config = {
         port = <new-port-number>,
         request_timeout = 10000,
         threads = 2,
    3. Save the file and restart the Network Agent.
  3. Update the App Agent:
    1. Open the following file in a text editor: <app_agent_home>/<version-number>/external-services/netviz/
    2. Set the netviz.agent.api.service.port option to the new TCP port number. 
    3. Save the file and restart the App Agent.

The Application I want to Monitor uses TCP Port 32768 or Higher. How do I configure the Network Agent to Monitor this Port?

 Click here to expand...
  1. Open the following file in a text editor: <network_agent_home>/conf/agent_config.lua

  2. If you plan to monitor any application or service that uses any TCP ports higher than 32767, uncomment the application_service_ports block and specify these ports as a comma-separated list in the ports option:


    application_service_ports = {
    ports = "",


    application_service_ports = {
    ports = "40000, 41000",

How can I replace the AppDynamicsNetMQ.dll with another version of NetMQ?

 Click here to expand...

1. Download the NetMQ.dll version and its dependencies.
2. ILMerge them into one dll file named AppDynamicsNetMQ.dll.
3. Include the AppDynamicsNETMQ.dll file in the .NET Agent home directory, such as C:\Program Files\AppDynamics\AppDynamics .NET Agent.

4. Restart the monitored application.

Why does running dynamic service increase DNS resolution time of the application?

 Click here to expand...

If you specify FQDN/hostname as a value to define the Network Visibility property in the file, dynamic service resolves the FQDN/hostname to respective IP address frequently, resulting in increased resolution time. 

To resolve this problem, use IP address as a value to define the Network Visibility property Alternately, you can also increase the value of networkaddress.cache.ttl depending on your application requirements.


How do I resolve the error, "ERROR MsgZmq::Bind: zmq_bind failed: File name too long"?

 Click here to expand...

 This error occurs when the file name is too long. The complete path to the file is considered as the file name. To resolve this error, move the Network Agent to a smaller absolute path.

Why do I see the error, "ERROR cw_flowgroup_uri_cb: Failed to write data on connection"?

 Click here to expand...

 This error occurs when Network Agent supports a large number of AppServer Agents. If you notice the error frequently, restart the agent with increased number of thread counts in webserver_config in agent_config.lua config file.

Why do I see the error, "ERROR ip_flowgrp_lookup: flowgrp alloc failed"?

 Click here to expand...

 Connections (Source IP : Source Port : Destination IP : Destination Port) in Network Agent are represented as flows. Aggregating these connections on a source port gives flow group, represented as (Source IP : Destination IP : Destination Port). The Network Agent can monitor only a certain number of flow groups. This error occurs when maximum number of flow groups is reached and the Network Agent cannot monitor any new incoming flow groups.

Why do I see the error, "DEBUG adns_resolve: ip resolve error: Name or service not known"?

 Click here to expand...

 AppDynamics resolves IPs to provide fully qualified domain name (FQDN) information to the controller for the IPs that are seen in the system. This error occurs when some IP addresses are not resolved.

  • No labels