On this page:

 

Your Rating:
Results:
PatheticBadOKGoodOutstanding!
15 rates


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

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.

How do I troubleshoot the Network Agent?

Network Agent Logs

If you notice any performance issues related to the agent, do the following:

  1. Stop the network agent:
    1. For ZIP packages:
      1. Identify the agent process: ps ef | grep \ appd-netagent
        The output provides the process ID (PID) of the Network Agent process.
      2. kill <network_agent_PID>
    2. For RPM and DEB packages: sudo service appd-netviz stop
  2. Check the following log files under <network-agent-install>/logs:
    1. appd-netmon.log
    2. appd-netagent.log.log

Network Agent Health Rule

The following default Health Rule is also useful for troubleshooting Network Agents: 
     Network-Host: Packet drops too high
This rule triggers an alert when packets get dropped between a Network Agent and the host interface. A high rate of packet drops on the host can result in inaccurate metrics.

 

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

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?

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?

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/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?

  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:

    Original:

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

    Edited:

    application_service_ports = {
    ports = "40000, 41000",
    }
     

  • No labels