Docs > Platform Observability > Getting Started with Network Monitoring
Getting Started with Network Monitoring
Overview
This guide introduces AppStatus Network Monitoring and covers:
- Throughput in and out for every host interface
- Connection counts and error rates
- Traffic paths between your services
- Saturation thresholds set against provisioned bandwidth
- Comparison against APM latency to locate the delay
What is Network Monitoring in AppStatus?
Network monitoring graphs what your hosts send and receive, how many connections they hold, and how many packets are dropped or errored — collected by the same agent that reports host metrics, so there is nothing extra to install.
Its main job is to answer one question during an incident: is the request slow because of your application, or because of the link it travels over? Saturation shows up as latency long before it shows up as errors.
Key capabilities:
- Per-interface throughput, with virtual interfaces excluded from alerting
- Connection count and error-rate tracking
- Service-to-service traffic paths ranked by volume
- Saturation thresholds against provisioned, not observed, bandwidth
- Separate thresholds for cross-region paths
What you will see
What the interface view looks like
Scroll the table sideways to see every column.
A one-sided traffic pattern usually means retries, not real load.
Troubleshooting
Throughput graphs are empty
Confirm the agent is running and that the interface is not on the exclusion list. Loopback and virtual interfaces are excluded by default so they do not distort fleet totals.
Saturation alerts fire but the application is fine
Your threshold is probably set against observed peak rather than provisioned bandwidth. Set it against what the link can actually carry, or you will alert every busy hour.
Cross-region calls always look slow
They are, and that is physics. Give cross-region paths their own thresholds — normal latency there is not normal within a region, and one shared threshold makes both useless.
Operational Guidance
- Saturation shows as latency long before it shows as errors.
- A one-sided traffic pattern usually means retries, not real load.
- Cross-region paths deserve their own thresholds — normal latency there is not normal locally.
Step-by-Step Setup
Network data arrives with the agent, so there is no separate install. The work is choosing thresholds that reflect what your links can actually carry, and excluding the interfaces that would otherwise distort every number.
Before you start
- The agent installed and reporting in Infrastructure
- 1
Confirm interfaces report
Open the network view and confirm each host lists its interfaces with throughput in and out.
WhereNetwork → Interfaces - 2
Exclude virtual interfaces
Keep loopback and virtual interfaces out of alerting. They carry real traffic figures that mean nothing at the fleet level and will distort your totals.
WhereNetwork → Settings → Exclusions - 3
Set saturation thresholds
Set thresholds against provisioned bandwidth, not against the peak you have observed. A threshold derived from observed peak alerts on every busy hour.
WhereNetwork → ThresholdsTipGive cross-region paths their own thresholds. Normal latency there is not normal within a region.
- 4
Compare against APM
During your next slow period, read network throughput beside APM latency. If the link is nowhere near saturated, the delay is in your application and the network view has already done its job.
WhereNetwork → Interfaces + APM → Services
Configuration Options
Every option you can set, what each choice means, and what to pick. Use this as a reference while you fill in the form.
Thresholds
| Field | Options | What it does | Recommended |
|---|---|---|---|
| Interface | Physical / virtual | What is measured and alerted on. | Exclude loopback and virtual from alerting. |
| Throughput threshold | Mb/s | When a link counts as saturated. | Set against provisioned bandwidth, not observed peak. |
| Error rate | Packets | Dropped or errored packets. | Any sustained non-zero rate deserves investigation. |
Feature Reference
Every feature, where to find it in the app, and what it does. Use this when you know what you want to do but not where it lives.
| Feature | Where in app | Description |
|---|---|---|
| Interface throughput | Network → Interfaces | In and out per interface, per host. |
| Connection counts | Network → Interfaces | Open connections and error rates. |
| Service paths | Network → Paths | Which service-to-service links carry the most traffic. |
| Fleet totals | Network overview | Aggregate traffic across the estate. |
Next Steps
Continue building your monitoring stack:
