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.

Network Agent Health Rule

The following default Health Rule is also useful for troubleshooting Network Agents: Network-Host: Packet drops too highThis 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_netmonprocess 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:

Use the netstat command to verify that the new port is not in use.

Update the Network Agent:

Open the following file in a text editor: <network_agent_home>/conf/agent_config.lua

Set the port option to the new TCP port number (under webserver_config).

Open the following file in a text editor: <app_agent_home>/<version-number>/external-services/netviz/netviz-service.properties

Set the netviz.agent.api.service.port option to the new TCP port number.

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?

Open the following file in a text editor: <network_agent_home>/conf/agent_config.lua

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: