Appearance
Network View
The Network View shows the current and recent network activity observed across the fleet. All data originates from sensor heartbeat payloads: active TCP connections are read from /proc/net/tcp and /proc/net/tcp6 on each sensor host at heartbeat time, listening sockets from /proc/net/tcp LISTEN state entries, and completed flows from the sensor's in-memory flow tracker. Network events (connections, accepted inbound, DNS queries) are also stored in ClickHouse and queryable through the Events view.
Data sources
| Data type | How collected | Latency |
|---|---|---|
| Active TCP connections | /proc/net/tcp snapshot in each heartbeat | Updated every 15 seconds |
| Listening services (TCP) | /proc/net/tcp LISTEN state in each heartbeat | Updated every 15 seconds |
| UDP listeners | /proc/net/udp snapshot in each heartbeat | Updated every 15 seconds |
| Network flows (completed) | Sensor flow tracker records on tcp_close | Available after connection closes |
| DNS events | dns_query, dns_lookup, dns_resolution event kinds in ClickHouse | Near real-time via heartbeat |
| Network events | network_connect, network_accept, network_listen in ClickHouse | Near real-time via heartbeat |
Active connection records include process attribution (binary name and PID resolved from /proc/{pid}/fd inode mapping). Connections that predate the sensor show duration_secs: null.
Active connections
In the Console, navigate to Network > Connections to see all active TCP connections across the fleet. Use the Sensor filter to scope to a specific node.
Filter parameters: sensor_id (optional), page (default 1), page_size (1–500, default 100).
The view includes connections, flows, total, page_count, current_page, and page_size.
Listening services
In the Console, navigate to Network > Listening Services to see all TCP listening services across the fleet. Use the Sensor filter to scope to a specific node. Each record includes the local address and port, PID, and binary path resolved from /proc/{pid}/fd.
UDP listeners
UDP listeners are reported separately from TCP because they come from a different proc file. In the Console, navigate to Network > Listening Services and switch to the UDP tab to see UDP listeners for a selected sensor. This is especially relevant for telecom sensors monitoring GTP-U (port 2152), PFCP (port 8805), RADIUS (ports 1812/1813), and SCTP-over-UDP.
Network flows
Active flows are tracked by the sensor's in-memory flow tracker from tcp_connect until tcp_close. Each flow record includes the binary, source and destination address/port, protocol, duration, bytes sent, and final state (established, refused, half-closed, stale).
In the Console, navigate to Network > Flows to see all active flows across the fleet.
Fleet connection summary
In the Console, navigate to Network > Summary to see a per-sensor summary of active connection counts, useful for dashboard-level fleet-wide anomaly detection.
Network event kinds in ClickHouse
The following event kinds are stored in ClickHouse and available through the Events query interface:
| Event kind | Description |
|---|---|
network_connect | Outbound TCP or UDP connection attempt |
network_accept | Inbound TCP connection accepted by a listening service |
network_listen | Process placed a socket in LISTEN state |
network_flow | Completed TCP flow with duration, bytes, and final state |
dns_query | DNS query sent to port 53 (UDP), 853 (DoT), or 5353 (mDNS) |
dns_lookup | Hostname resolution via getaddrinfo at the application layer |
dns_resolution | Correlated hostname-to-IP mapping (from getaddrinfo + tcp_connect) |
lsm_net_connect | Network connect event at the LSM security hook (when available) |
To query network events for a specific sensor, navigate to Investigate in the Console, filter by sensor and event kind (e.g. network_connect), and set the time window to the desired lookback period.
Limitations
- Active connection records are a snapshot taken at heartbeat time (every 15 seconds). Short-lived connections that open and close between heartbeats appear only as
network_flowevents if the sensor's flow tracker captured them. - Process attribution requires that the PID is still running at the time of the heartbeat snapshot. PIDs from connections that predated the sensor will have
nullduration. - UDP listeners are reported from the heartbeat snapshot. SCTP associations are tracked separately in the sensor's telecom monitoring modules (telecom flavor only).
- The v1 flow and listening endpoints return all data without pagination. For large fleets use
sensor_idfiltering or the v2 cursor-based endpoints.