Network Throughput Metrics Explained

Network traffic monitoring is essential for understanding your server's communication patterns, identifying bottlenecks, and planning capacity. Server Scout's agent collects comprehensive network throughput metrics from your primary network interface, providing both real-time rates and interface identity information.

How Network Metrics Are Collected

Server Scout monitors network activity through the Medium tier collection process, which runs every 30 seconds. The agent reads directly from /proc/net/dev, a virtual filesystem that provides kernel-level network interface statistics without any disk I/O or external command execution.

The agent focuses on your server's primary network interface — the one carrying the default route. This approach keeps monitoring lightweight whilst capturing the vast majority of network activity on typical servers. For most configurations, this primary interface handles nearly all inbound and outbound traffic.

Network Throughput Metrics

Server Scout tracks two fundamental throughput counters that form the backbone of network monitoring:

MetricDescriptionCollection TierData Source
net_rx_bytesCumulative bytes received on primary interfaceMedium (30s)/proc/net/dev
net_tx_bytesCumulative bytes transmitted on primary interfaceMedium (30s)/proc/net/dev

These metrics represent cumulative counters — they continuously increase as your server processes network traffic. The raw values show total bytes transferred since the interface was brought up, but the dashboard transforms these into meaningful rate information.

Understanding Rate Calculations

When viewing network charts in the Server Scout dashboard, you're seeing rates (bytes per second), not the raw cumulative totals. The dashboard calculates these rates by computing deltas between consecutive measurement points:

Rate = (Current Reading - Previous Reading) / Time Interval

For example, if net_tx_bytes increases from 1,000,000 to 1,500,000 bytes over a 30-second interval, the transmission rate is 16,667 bytes/second (approximately 16.7 KB/s).

This rate-based presentation makes network charts immediately useful — you can see traffic spikes, sustained transfer periods, and baseline activity levels at a glance.

Network Identity Metrics

Understanding which interface is being monitored and its configuration details helps interpret throughput data in context:

MetricDescriptionExample Values
net_interfacePrimary interface nameeth0, ens3, eno1, enp0s3
net_ipPrivate IP address192.168.1.100, 10.0.0.50
net_macHardware MAC address52:54:00:12:34:56

These identity metrics help you correlate Server Scout data with other network monitoring tools and verify that you're monitoring the expected interface.

Reading Network Charts Effectively

Network throughput charts reveal patterns that help diagnose performance issues and understand application behaviour:

Traffic Direction Analysis

Examining RX (receive) versus TX (transmit) patterns provides insights into server roles:

  • Web servers typically show higher TX than RX — they receive small HTTP requests but transmit larger responses containing HTML, images, and assets
  • Database servers may show balanced bidirectional traffic during interactive queries, or TX-heavy patterns when serving read-heavy workloads
  • Backup clients demonstrate RX-heavy patterns when receiving data, TX-heavy when uploading to remote storage

Temporal Patterns

Network charts often reveal predictable patterns:

  • Business hours peaks indicate user-driven traffic
  • Overnight spikes suggest batch processing, backups, or maintenance windows
  • Regular intervals might indicate scheduled synchronisation or monitoring checks

Identifying Anomalies

Sudden changes in network patterns can indicate:

  • Traffic spikes from viral content, DDoS attacks, or application errors
  • Sustained high usage during data migrations or system synchronisation
  • Unexpected silence potentially indicating connectivity issues or service failures

Bandwidth Context and Capacity Planning

Interpreting throughput metrics requires understanding your network infrastructure's capacity:

Link SpeedTheoretical MaximumRealistic Sustained
100 Mbps~12.5 MB/s~10 MB/s
1 Gbps~125 MB/s~100 MB/s
10 Gbps~1.25 GB/s~1 GB/s

Real-world throughput typically falls below theoretical maximums due to protocol overhead, network congestion, and hardware limitations. When your charts show sustained usage approaching these limits, consider:

  • Capacity planning — upgrading network links before saturation impacts performance
  • Traffic optimisation — implementing compression, caching, or content delivery networks
  • Load balancing — distributing traffic across multiple servers or interfaces

Protocol Overhead Considerations

Server Scout's network metrics capture layer-2 byte counters, including all protocol overhead. This means the reported throughput includes:

  • Ethernet frame headers and checksums
  • IP packet headers
  • TCP/UDP headers
  • Application protocol overhead (HTTP headers, database protocol framing)

For capacity planning, remember that application payload represents only a portion of measured throughput. A file transfer showing 100 MB/s throughput might deliver approximately 90-95 MB/s of actual file data.

Common Network Patterns by Server Type

Different server roles exhibit characteristic network patterns:

Web Application Servers

  • Asymmetric traffic with TX typically 3-10x higher than RX
  • Bursty patterns corresponding to user activity
  • Cache hit ratios visible as reduced backend communication during high frontend activity

Database Servers

  • Query response patterns with RX spikes (queries) followed by TX spikes (results)
  • Replication traffic showing steady TX to replica servers
  • Backup windows with sustained high TX during database dumps

File Servers

  • Highly variable patterns depending on user access
  • Large transfer events during bulk file operations
  • Symmetric traffic during two-way synchronisation

Container Hosts

  • Overlay network overhead may inflate reported throughput
  • Inter-container communication appears as loopback or overlay traffic
  • Ingress patterns concentrated on host interfaces despite distributed container services

Monitoring Single Interface Strategy

Server Scout's focus on the primary network interface offers several advantages:

Performance Efficiency: Monitoring one interface keeps the agent lightweight, consuming minimal system resources whilst providing comprehensive visibility into most network activity.

Simplified Analysis: Single-interface monitoring eliminates the complexity of aggregating multiple interface statistics, making charts clearer and more actionable.

Adequate Coverage: On typical servers, the primary interface handles 95%+ of network traffic. Secondary interfaces often carry only management traffic or specialised protocols.

For servers with significant multi-interface traffic (such as network appliances or servers with dedicated backup networks), consider the primary interface metrics as the foundation whilst supplementing with interface-specific monitoring tools for comprehensive coverage.

Troubleshooting with Network Metrics

Network throughput data supports various troubleshooting scenarios:

Performance Degradation

When applications report slow network performance:

  1. Check if throughput charts show saturation near link capacity
  2. Compare current patterns with historical baselines
  3. Correlate network spikes with CPU or memory pressure
  4. Examine error counters (available in Server Scout's network error metrics)

Capacity Planning

For infrastructure scaling decisions:

  1. Identify peak usage periods and sustained high-throughput intervals
  2. Calculate growth trends over weeks or months
  3. Plan upgrades before sustained usage exceeds 70-80% of link capacity
  4. Consider both average and peak usage patterns

Security Monitoring

Network metrics can indicate security events:

  • Unusual outbound traffic might suggest compromised systems
  • Unexpected traffic patterns could indicate reconnaissance or data exfiltration
  • Sustained high usage during off-hours might warrant investigation

Server Scout's network monitoring provides the foundation for understanding your server's communication patterns. Combined with CPU, memory, and disk metrics, network throughput data enables comprehensive server performance analysis and proactive infrastructure management.

Back to Complete Reference Index

Frequently Asked Questions

What is the difference between RX and TX bytes?

RX (receive) bytes measure data coming into the server from the network, while TX (transmit) bytes measure data sent from the server. Both are cumulative counters from /proc/net/dev. The dashboard converts these to per-second throughput rates. High RX typically indicates incoming traffic (requests, downloads to server), while high TX indicates outgoing traffic (responses, uploads from server).

Why do network byte counters keep increasing?

Network byte counters (net_rx_bytes, net_tx_bytes) are cumulative counters that continuously increase from system boot. The Server Scout dashboard automatically calculates per-second rates by computing the difference between consecutive readings divided by the time interval. You see meaningful throughput rates in charts, not raw counter values. Counters reset to zero only on system reboot.

How do I identify which interface Server Scout monitors?

Server Scout reports the primary network interface in the net_interface metric, along with its IP address (net_ip) and MAC address (net_mac). The agent automatically selects the primary interface based on the default route. These identity metrics are collected every 30 seconds along with the throughput counters.

What network throughput is normal for my server?

Normal throughput depends entirely on your server role. A web server might see asymmetric traffic with much higher TX than RX. A backup server sees high RX during backup windows. Database servers typically have moderate, steady traffic. Establish your baseline over a week, then set alerts for sustained deviations from normal patterns rather than absolute values.

Was this article helpful?