uberAgent

Per-Application Network Monitoring

This feature is supported on: Windows, macOS

What Is Per-Application Network Monitoring

uberAgent network monitoring keeps track of all incoming and outgoing network connections. uberAgent associates every network connection with the application handling it and determines metrics like latency, packet loss, data volume, and more. uberAgent network monitoring also records failed connections that may have been blocked by firewalls, for example.

uberAgent per-application network monitoring does not inspect packets and does not break TLS or other types of encryption.

Use Cases for Per-Application Network Monitoring

By providing insights into network activity per application, uberAgent enables the following use cases:

  • Network availability scoring
  • Network quality monitoring
  • Identification of network issues (jitter, packet loss, blocked ports)
  • Mapping of network targets (who talks to whom)
  • Data volume analytics (how much traffic is going where)

Which Data is Collected by Per-Application Network Monitoring

The data collected as part of uberAgent per-application network monitoring is sent to the backend via the sourcetypes listed in the network metrics documentation.

Name Resolution (IP Address to DNS Name)

Name resolution is supported on: Windows

Network packets contain IP addresses, but not DNS names. In order to be able to associate each network target IP address with the corresponding DNS name, uberAgent also monitors DNS queries. By enriching network monitoring data with DNS query data, uberAgent ensures that each network event has the target’s IP address as well as its DNS name.

Please note that uberAgent does not perform reverse DNS lookups, nor does it send its own DNS queries over the wire. uberAgent only generates network traffic to send the collected data from the endpoint to the backend servers.

Protocol Notes

IPv6

IPv6 is fully supported by uberAgent per-application network monitoring.

UDP

UDP traffic is fully supported by uberAgent per-application network monitoring. However, due to the protocol’s connectionless nature, latency cannot be determined.

TCP

TCP traffic is fully supported by uberAgent per-application network monitoring. Since TCP is a connection-based protocol, latency, jitter, and packet loss can be determined.

Please note that latency detection is limited to send operations because otherwise a cooperating agent at the receiving side would be required.

QUIC

QUIC traffic is treated as UDP by uberAgent per-application network monitoring.

ICMP

ICMP traffic is ignored by uberAgent per-application network monitoring.

Configuration

Enabling or Disabling Per-Application Network Monitoring

uberAgent per-application network monitoring is enabled or disabled via the NetworkTargetPerformanceProcess timer metric in the configuration. In the default configuration, network monitoring is enabled.

Configuration Options for Per-Application Network Monitoring

Certain aspects of per-application network monitoring can be configured via the stanza [NetworkTargetPerformanceProcess_Config].

Key

This setting is supported on: Windows, macOS

Internally, uberAgent records network activity by process instance. However, that level of detail is rarely required. In most cases, it is sufficient to visualize network activity per process name. This is an optimization that reduces the event count in the backend and the data volume. Optionally, the agent can be configured to record network activity by process ID for full granularity by switching to grouping per ID instead of per name.

Setting name: Key
Description: What to group by: process name or ID
Valid values: name | id
Default: name
Required: no
<!--NeedCopy-->

IgnoreLowActivity

This setting is supported on: Windows, macOS

This is another setting targeted at reducing the event count and the data volume. By default, a threshold is applied below which per-application network activity is dropped (not sent to the backend).

Setting name: IgnoreLowActivity
Description: Whether to ignore processes with very low activity during a collection interval
Valid values: true | false
Default: true
Required: no
<!--NeedCopy-->

IgnoreLoopbackTraffic

This setting is supported on: Windows

This setting aims to reduce event count and data volume. By default, uberAgent ignores loopback traffic and doesn’t send its metrics to the backend.

Setting name: IgnoreLoopbackTraffic
Description: Whether to ignore processes with loopback traffic or not
Valid values: true | false
Default: true
Required: no
<!--NeedCopy-->

Remarks: If you set IgnoreLoopbackTraffic = false, you should also set NetworkDriverLegacyAPI = true to view all metrics related to loopback traffic. By default, only network connections are collected without additional traffic details. This restriction stems from the inherent Windows API. To access all loopback traffic metrics, it’s necessary to change the provider as well.

NetworkDriverEnabled

This setting is supported on: Windows

Starting with uberAgent 6.0 (Windows), uberAgent monitors network activity with a kernel driver. This configuration option can be used to switch back to the older network data collection source ETW. ETW network monitoring has several limitations. Most notably, latency cannot be determined accurately.

Setting name: NetworkDriverEnabled
Description: Enables processing all network metrics by a driver instead of ETW.
Valid values: true | false
Default: true
Required: no
<!--NeedCopy-->

NetworkDriverLegacyAPI

This setting is supported on: Windows

This setting is intended for internal use by vast limits. Only enable it if instructed by support.

Setting name: NetworkDriverLegacyAPI
Description: Use legacy WFP API to process packet streams in kernel mode.
Valid values: true | false
Default: false
Required: no
<!--NeedCopy-->

TestCompareNetworkDriverAndETW

This setting is supported on: Windows

This setting is intended for internal use by vast limits. Only enable it if instructed by support.

Setting name: TestCompareNetworkDriverAndETW
Description: Collect network metrics using Windows ETW interfaces and the uberAgent network driver.
             The ProcUser field of the metric NetworkTargetPerformanceProcess is extended by a suffix ETW or DRV to differentiate the type of network event.
             Because of that, the network events are sent two times to the configured backend.
             Use this feature to test unusual behavior in test environments. This is not intended to be used in a production environment.
Valid values: true | false
Default: false
Required: no
<!--NeedCopy-->
Per-Application Network Monitoring