Network monitoring that connects traffic to services

What is network monitoring?

Network monitoring is the continuous measurement of the availability, performance and traffic of the networks your applications depend on. Traditionally that meant polling routers and switches for interface status. Today the network also includes cloud VPCs, Kubernetes overlay networks, service meshes, load balancers, DNS and the public internet between your users and your services.

Modern network monitoring therefore combines several data sources: device metrics, flow records that describe who talks to whom, connection-level metrics from hosts and containers, and synthetic tests that measure paths from the outside. The aim is not just to know that a link is up, but to understand how network behavior affects the services running over it.

Why network monitoring matters

When an application slows down, the network is often the first suspect and the hardest to clear. Packet loss on a single node, an overloaded NAT gateway, DNS timeouts or a misconfigured network policy can all look like application latency. Without data, network and application teams spend incident time arguing instead of fixing.

Distributed architectures make this more important. Microservices turn function calls into network calls, and each additional hop adds latency and failure modes. Cross-zone and cross-region traffic also carries a real cost on every major cloud. Network monitoring makes these dependencies, risks and costs visible.

Security benefits as well. Rejected flows, unexpected outbound connections and sudden traffic spikes are often the first sign of misconfiguration or abuse, and network data gives security and platform teams a shared record of what actually happened on the wire.

Key network metrics

Metric	What it tells you
Latency and round-trip time	How long packets take between two endpoints; rising RTT points to congestion or routing changes.
Packet loss and retransmits	Lost packets force TCP retransmissions and directly increase request latency.
Throughput and bandwidth utilization	Whether links, interfaces or gateways are close to saturation.
Connection errors and resets	Refused or reset connections often indicate failing services, exhausted ports or policy blocks.
DNS resolution time and failures	Slow or failing lookups delay every request that depends on them.
Rejected flows	Traffic blocked by security groups, firewalls or network policies.

How Obseria handles network monitoring

The Obseria Agent, installed once per host or as a DaemonSet in Kubernetes, captures connection-level metrics such as round-trip time, retransmits and resets for every process and container. Cloud flow logs from AWS, Azure and Google Cloud are ingested and enriched through Obseria Pipeline, and network devices report via SNMP or streaming telemetry. Synthetic checks from 50+ locations add the outside-in view of DNS, TLS and HTTP performance.

Obseria TopoGraph maps all of this to services and workloads. Instead of reading IP addresses, you see that the checkout service has elevated retransmits to the payments database in one availability zone. Obseria Intelligence correlates network anomalies with application traces and deployments, so an investigation can conclude, with evidence, whether the root cause is the network or not.

Flow data can be large. Obseria Pipeline aggregates, samples or drops low-value flows at ingest, and filtered data costs only ingestion. You can query everything with OQL:

fetch flows
| filter action == "REJECT"
| summarize count(), by:{src.service, dst.port}

Network monitoring best practices

1. Map flows to services. Traffic labeled with service and team names is far easier to act on than raw IPs.
2. Baseline normal behavior. Latency and traffic vary by time of day; use anomaly detection rather than static thresholds.
3. Monitor DNS explicitly. DNS failures are a frequent and underestimated cause of outages.
4. Combine inside and outside views. Pair internal connection metrics with synthetic checks from user regions.
5. Track cross-zone traffic. It affects both latency and your cloud bill.
6. Record changes as events. Routing, firewall and network policy changes should appear on the same timeline as your metrics.