AppDynamics switched from Semantic Versioning to Calendar Versioning starting in February 2020 for some agents and March 2020 for the entire product suite.


    Skip to end of metadata
    Go to start of metadata

    General

    • Why are there no connection metrics for a tier, node, or network link?
     Click here to expand...

    By default, Network Agents do not collect connection metrics. 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:

    • Check that the user account has a Network Visibility product license. 
    • If the user account has license rules defined, verify that the correct number of license units have been allocated.
    • To change the number of allocated units in a rule:
      • Go to Controller Settings > License > Rules.
      • Edit the License Rule of interest. (There may be only one License Rule, named Default.)
      • In General, 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 that?
     Click here to expand...

    Typically, the network links and TCP connections used by an application flow have the same direction (source → destination) as the flow itself. You may notice different directions, however, if two tiers transfer data through 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 may be used by an application flow in the opposite direction: queue (source) → tier (destination).

    TCP Connections

    • How do I change the Network Agent communications port?
     Click here to expand...

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

    1.  Use the netstat command to verify that the new port is not in use.
    2.  Update the Network Agent:
      1. Use a text editor to open this file: <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. Use a text editor to open this file: <app_agent_home>/<version-number>/external-services/netviz/netviz-service.properties.
      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. Use a text editor to open this file: <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:

      Original:

      --[[
      application_service_ports = {
      ports = "",
      }
      --]]

      Edited:

      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 the DNS resolution time of the application?
     Click here to expand...

    If you specify FQDN/hostname as a value to define the Network Visibility property netviz.agent.host.address in the netviz-service.properties file, dynamic service resolves the FQDN/hostname to its 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 netviz.agent.host.address. Alternately, you can also increase the value of networkaddress.cache.ttl depending on your application requirements.

    Logs

    • 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 included in the file name.

    To resolve this error, move the Network Agent to a smaller absolute path.

    1. Create a soft (symbolic) link for the longer directory name: $ ln -s /long/dir/name /short/dir/name.
    2. Go to the short directory: $ cd /short/dir/name.
    3. Run the install.sh script: $ sudo ./install.sh.
    4. Change the LD_PRELOAD parameter in application to use the library from the short directory name: $ LD_PRELOAD=/short/dir/name/lib/appd-netlib.so <command to start app>.
    • 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 the Network Agent supports a large number of AppServer Agents. If this error occurs frequently, restart the Agent using an 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 provides 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 the 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 IP addresses to provide fully qualified domain name (FQDN) information to the Controller for the IP addresses visible in the system. This error occurs when some IP addresses cannot be resolved.

    • No labels