Compare logs, flows, packets and DNS as network data sources: what each shows, what it costs, and why logs plus flows cover most office usage reporting.
The short version
- Every usage-monitoring technique traces back to one of four data sources.
- For day-to-day usage reporting across an office, logs and flows together cover most of what you need.
01The Four Sources
Every usage-monitoring technique traces back to one of four data sources. Pick the wrong one and you'll either drown in data you can't use, or miss the visibility you actually need. Here's what each gives you — and what it costs.
Proxy and access logs are the original bandwidth-accounting tool. When traffic passes through a proxy, gateway, or web filter, it writes a record for each request: who made it, when, which URL, how many bytes transferred. Internet Access Monitor built its entire workflow on this: parse the IIS or Squid log, aggregate by user and domain, report. The visibility is rich — you can see that a specific user visited a specific site and pulled down a specific volume at a specific time — but the proxy itself is the prerequisite. If traffic bypasses it (mobile data, split-tunnelling VPN, direct HTTPS to an IP), the log sees nothing. Access logs also tend to be HTTP-era in their structure; modern TLS means many logs record the SNI hostname rather than the full URL, which is still useful but less granular than the old days of clear-text proxying.
NetFlow, sFlow and IPFIX answer a different question: who talked to whom, and how much? Your router or switch exports flow records — each one a summary of a conversation: source IP, destination IP, ports, byte count, packet count, start and end time. No payload, ever. This is the natural data source for bandwidth accounting across your whole network, not just web traffic. You see the top talkers on a link, which internal hosts are hammering cloud storage, whether your backup job is saturating the WAN at 9 a.m., and who opened an unexpected connection to an unfamiliar IP block. Collectors like ntopng, ElastiFlow, or the flow analysis in PRTG ingest these records and turn them into dashboards and alerts. The trade-off: flow data tells you volume and direction but not which application or user, unless you correlate the IP against your DHCP/AD logs — a step most serious deployments do, but it requires wiring the systems together.
Packet capture is the nuclear option. Tools like Wireshark or a purpose-built tap record every byte at the wire level. For diagnosing a specific problem — an unexplained connection, a protocol misbehaving, a device sending strange traffic — nothing beats it. But full captures are storage-hungry, operationally heavy, and carry real privacy obligations: you're recording the metadata and (for unencrypted traffic) the content of every conversation on the segment. Run it for investigation, not routine reporting. Where continuous packet analysis is used at scale — intrusion detection, DLP — it's typically implemented as a dedicated appliance with purpose-built controls, not an open-ended tcpdump session.
DNS logs are quietly the most underused source in small and mid-market shops. Before any device connects to anything on the internet, it resolves a name. Log those lookups and you have a lightweight, content-free record of every service every device tried to reach — cloud apps, update servers, social media, shadow IT — without capturing a single byte of payload. DNS-level visibility is cheap: Pi-hole, NextDNS and Cisco Umbrella all operate on this principle. The limitation is resolution: you see "device queried slack.com" but not which user, which workspace, or how much data moved. Pair DNS logs with flow data and you close most of that gap.
02Choosing the Right Tool for the Job
For day-to-day usage reporting across an office, logs and flows together cover most of what you need. Proxy or gateway logs give you per-user, per-site web history; flow records give you bandwidth accounting for everything else, including non-HTTP traffic. Invest in DHCP correlation early — IP-to-user mapping transforms raw flow data from a list of addresses into a legible story.
Add DNS logging as the cheapest possible layer of shadow-IT and asset visibility. It costs almost nothing to run a local resolver that logs queries, and the signal-to-noise ratio is excellent.
Reach for packet capture only when a specific anomaly needs forensic-level investigation. Define what you're capturing and why, time-box it, and delete the data when the investigation closes.
The four sources aren't in competition — they're complementary. The skill is knowing which question each one answers.
