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