Skip to main content
The question: which processes and destinations drive outbound traffic, and how does that change over time? Filetrace separates two kinds of egress that byte counters usually merge: bytes a socket sent and bytes that came from a file. For cost and capacity, both matter, and the difference tells you whether the traffic is user-facing content or application traffic.

​
Rank destinations

--protocol tcp narrows it to one transport. The PROCESSES column shows how concentrated each destination is: one process is easy to explain, many processes means shared infrastructure.

​
Merge flows by a key

--group-by answers “by whom”, “to where”, “on which port” and “over which protocol” without changing the underlying records. --direction inbound|outbound|both chooses which side ranks the groups.

​
Separate content from application traffic

top files ranks what you actually serve or upload. transfers also lists FILE unknown rows: bytes sent with no file behind them, such as generated responses, proxied traffic or database results. If cost is driven by unknown rows, the lever is in the application, not in storage.

​
Track it in Prometheus

The counters are cumulative, so rate and increase answer cost questions over any window:
No metric carries an address or a port, by design: those labels would grow without bound. For per-destination accounting, aggregate the file_transfer log records in your collector, where the address is an attribute.
A monthly projection from the daily total:

​
Split by protocol and direction

UDP egress is often DNS, metrics or logs; if it is large, the cause is usually a misconfigured exporter or a retry storm.

​
Capacity planning

  • Sustained rate. FiletraceEgressSpike in the recipes alerts above a chosen threshold; set it from your link capacity, not a round number.
  • Peak versus average. max_over_time(sum(rate(filetrace_network_io_bytes_total{network_io_direction="transmit"}[5m]))[1h:1m]) shows the peak the link must absorb.
  • Files sent, not bytes. rate(filetrace_transfers_started_total[5m]) is operation rate, which matters when the bottleneck is connections rather than bandwidth.
  • Inbound. The same counters with network_io_direction="receive" show what the host pulls in.

​
Where the answer can mislead

  • Bytes are counted at the local socket, before the network. They include protocol overhead the kernel adds later and exclude retransmissions, so they are close to, but not the same as, bytes billed by a provider.
  • Loopback traffic is counted. An agent, a proxy or a service talking to itself over 127.0.0.1 adds to the totals. --remote 127.0.0.0/8 isolates it.
  • A file can be sent more than once, so file.sent totals are not storage totals.
  • The agent’s own traffic to a collector counts too; exclude it with [filters] exclude_processes = ["filetrace-agent"].