Network & protection
Check bandwidth and diagnose throughput
Separate port speed, traffic volume, packet errors and application throughput, then collect measurements useful for troubleshooting.
On this page
Before you start
- An active server and administrative access to its operating system.
- The interface name carrying production traffic and the expected port tier from the server configuration.
- A precise incident window in UTC, source and destination addresses, protocol, and expected versus observed result.
- Permission to inspect local interface counters without resetting or changing them.
Distinguish the measurements
Port speed is the negotiated or configured link rate. Traffic volume is the number of bytes or packets transferred over time. Throughput is the useful rate achieved by a workload and depends on both endpoints, protocol behavior, disk and CPU limits, packet loss, latency, congestion, and test design. Unmetered means the included service is not billed by a transfer allowance; it does not remove the physical port limit or guarantee every flow will reach line rate.
Servers shows the port tier associated with your configuration. That label is not a traffic measurement. The Network chart does not yet contain live samples, so use your own monitoring for usage, peaks and historical evidence.
| Signal | Question answered | Current source |
|---|---|---|
| Catalogue port tier | What link tier was ordered? | Server summary |
| Interface byte counters | How much traffic crossed this guest interface? | Operating system |
| Error/drop counters | Did the guest or device report packet problems? | Operating system and driver |
| Provider switch counters | What occurred outside the guest? | Operator only |
| Application timing | What performance did the workload experience? | Your application monitoring |
Collect a read-only baseline
Discover the interface name, then inspect its counters twice across a known interval. Replace eth0 with the actual interface. The Linux kernel documents that ip -s -s exposes detailed link statistics and that ethtool can expose standard and driver-defined counters. Counter names and support vary by driver, so preserve the complete output rather than selecting only one field.
- Growing RX or TX error and drop counters are evidence to investigate, not proof of a provider fault.
- A displayed link speed below the expected tier should be reported with the interface and driver details.
- A quiet interface during an application test may indicate that the workload uses another interface, namespace, or path.
- Guest counters cannot reveal every event on the upstream switch or transit path.
ip -brief link
ip -s -s link show dev eth0
ethtool eth0
ethtool -S eth0Design a useful test
- State the question: single-flow throughput, aggregate throughput, packet loss, latency, or interface errors.
- Choose a controlled endpoint you are authorized to use and record its location and capacity.
- Measure during a defined UTC interval while collecting guest counters and application metrics.
- Repeat with one changed variable, such as another destination or time window, instead of changing several settings at once.
- Stop any test that can disrupt production or create abusive traffic.
Expected result and escalation
The expected result is a reproducible observation tied to an interface, two endpoints, a protocol, and a time window—not a screenshot of the placeholder graph. If local counters are healthy but performance is consistently poor to several suitable destinations, send the operator the server, region, address, interface, time window, direction, expected tier, observed rates, error counters, and test method.
Historical traffic charts are not available yet. Keep your own monitoring if historical traffic evidence is operationally important, and agree with the operator on any provider-side data that can be shared.