Network Monitoring

Host CPU is normal but communication is failing - the blind spot network monitoring fills

A common dead end in incident investigation is that the app's error rate is rising while every host's CPU, memory, and disk are at normal values. When the cause is not "inside the host" but "between hosts," the standard metrics of Infrastructure Monitoring show nothing abnormal. Datadog's network monitoring is the group of features that fills this blind spot, and it divides broadly into two pillars. The first is Cloud Network Monitoring (CNM), which collects connection information on hosts with the Agent installed at the level of IP / port / process and aggregates it into dependencies at the level of arbitrary tags such as service, container, or availability zone. The second is Network Device Monitoring (NDM), which monitors routers / switches / firewalls where the Agent cannot run, using device-oriented protocols such as SNMP (as of September 2026, sources: Cloud Network Monitoring, Network Device Monitoring). The official documentation lists 4 uses for CNM: discovering unexpected (or slow) service dependencies, optimizing costly cross-region or multi-cloud communication, identifying cloud provider region outages and external service outages, and separating client-side from server-side DNS problems. All of these are the kind of failure that "does not appear in the app's logs and does not appear in the host's graphs," and without this, investigation tends to drift into guesswork restarts.

CNM looks at 3 things: service-to-service flows, DNS, and paths

CNM's coverage is easier to organize when viewed as 3 layers. Layer 1 is flows (connections): which client sends and receives how much to which server, and how TCP retransmits, latency, and jitter are trending, filtered by tag. Collection is handled by eBPF on Linux and a network kernel driver on Windows, and it starts when you enable network_config in system-probe.yaml on Agent v6.14 or later (as of September 2026, source: CNM Setup). Layer 2 is DNS: given Agent 7.33 or later and CNM enabled, you can see which Pods or services are querying which DNS servers, spikes in response time, and the occurrence rate per error type (source: DNS Monitoring).

Layer 3 is paths: Network Path runs traceroute on the host and draws per-hop latency from source to destination. You can choose both fixed source-destination pairs written in the Agent configuration (scheduled tests) and pairs auto-generated from real traffic observed by CNM (dynamic tests), giving you material to tell whether a problem is inside your own network or on the ISP side (source: Network Path).

NDM looks inside routers and switches via SNMP

NDM handles monitoring of devices where the Agent cannot be installed. The targets are routers / switches / firewalls in on-premises and virtual environments; it auto-discovers devices on the network and collects bandwidth utilization, bytes sent, and device and interface up / down status via SNMP. How each device is read is determined by a definition file called a profile; devices with a vendor-specific profile can be started with dashboards already in place, and even for devices not on the list, the generic profile picks up basic TCP / UDP / IP and interface metrics (as of September 2026, source: NDM Supported Devices). Collection is not limited to SNMP polling. There are SNMP traps sent from the device side to the Agent (source: SNMP Traps), and NetFlow Monitoring, which receives NetFlow / jFlow / sFlow / IPFIX flow information; for the latter, on Agent 7.45 or later you specify netflow5 / netflow9 / ipfix / sflow5 in flow_type and open a receiving port (source: NetFlow Monitoring). Once you have flows, "which interface on which device is eating bandwidth" and "who are the top talkers" become visible per device, and the host-to-host flows CNM sees can be cross-checked against the on-path flows the devices see on the same Datadog screen. Having on-premises core switches and cloud services lined up under the same tag scheme is the practical benefit of choosing NDM in a mixed environment.

How the Network Map differs from the Host Map

The first screen you will open in CNM is the Network Map. Whereas the Host Map is a screen that lines up "the state of each individual machine" as colored hexagons, the Network Map is a directional map that draws "who is talking to whom and how much" as a diagram with arrows. You choose the tag used for nodes (such as service or availability-zone) with the selector at the top, and choose the metric shown on the edges from 7 kinds: sent throughput / received throughput / TCP retransmits / TCP latency / TCP jitter / established connections / closed connections. When there are too many nodes, they are automatically grouped by a second tag, and you can filter by environment or namespace and hide traffic outside a specified percentile range. If CNM is enabled in the Agent, no additional configuration is needed; the map is drawn automatically from the collected data (as of September 2026, source: Network Map). The trick to reading it is to memorize its normal shape once. During an incident, the work of looking for "a thick arrow that should not be there" or "an edge turned red by retransmits" is nothing other than looking for the difference from normal. If tag design is not consistent, nodes become "unknown" or a list of IP addresses and the map loses its meaning, so the order of aligning the service tag and env tag across all hosts before introducing CNM pays off.

Billing splits into per-host (CNM) and per-device (NDM)

The cost of network monitoring is counted differently depending on whether the target is "a host with the Agent installed" or "a device seen via SNMP." CNM is a per-host SKU billed monthly per host, and the unit price differs between annual contract and on-demand (SKU breakdown as of August 2026; source: Datadog Pricing). Since it is added on top of Infrastructure Monitoring's host billing, for a host with CNM added, estimate "the Infrastructure Monitoring host unit price plus the CNM host unit price" as the monthly base charge. NDM, on the other hand, is a separate per-device SKU, counted per router or switch, and is not included in host billing. For Network Path as well, tests run from the Synthetic Monitoring side have a separate SKU counted per test run. For the actual unit prices of all of these, check Datadog's official pricing page.

In estimation practice, "do not put CNM on every host" is the first line of defense. Failures that happen inside a host are covered by Infrastructure Monitoring, so start CNM only on communication chokepoints, for example the API gateway, the tier in front of the DB, and hosts handling cross-region traffic, and expand only where the benefit is visible. How to read the overall pricing structure is covered in the pricing guide.

Narrow down suspects in the order app, host, network

Once you introduce network monitoring, a period comes when you want to blame the network for everything. In practice, however, the efficient order for narrowing down is app (which service's which operation is slow, per APM traces), host (whether CPU or I/O is saturated, per Infrastructure Monitoring), then network (whether retransmits or DNS are disturbed on that segment, per CNM). The reason is simple: frequency of occurrence and speed of fixing differ. App bugs and host resource shortages can be fixed by your own team, whereas network-side problems pass into the hands of paths, devices, and sometimes the ISP, so saying "the network looks suspicious" without evidence stalls the investigation. Part of CNM's value is that, at the end of this order, it can deny "it is not the network" with numbers, and if that is denied, the remaining suspects are narrowed to the app or the host. Take a mixed environment where an on-premises data center and the cloud are connected by a leased line or VPN. Here, if you divide responsibilities as "CNM for host-to-host on the cloud side, NDM for switches and perimeter firewalls on the on-premises side, and Network Path for the route in between," you can follow on one screen which segment added the latency.

5 items to check before enabling

For both CNM and NDM, the points that cause trouble after enabling are largely predictable. If you fill in the 5 items of supported environment, permissions, tags, device-side configuration, and billing scope first, backtracking is almost eliminated.

Once these are filled in, enabling itself takes 1 line in system-probe.yaml.

network_config:
  enabled: true

After configuring, check in this order: look at the Agent status output to see whether system-probe is running, then wait a few minutes until your host appears on the Network Map. At the stage of turning anomalies into notifications, the standard approach is to watch the retransmit rate and DNS error rate with monitors, and the official documentation also has an explanation of the CNM-specific monitor type (as of September 2026, source: Cloud Networking Monitor).