I really like using argus for this. It is a software package that promiscuously listens on an interface and writes out flow data similar to (net|j)flows. It uses the client/server model, where the server daemon performs the capture and writes the data files, and the client tools are used to read and analyze the data files. The output files are written into a binary format, so some learning curve in the included tools is necessary.
Using a (nearly) default config what follows is an anonymized version of the basic output:
StartTime Proto SrcAddr Sport Dir DstAddr Dport SrcPkts DstPkts SrcBytes DstBytes State
31 Jan 11 23:20:07 icmp 10.8.23.225 -> 10.28.5.232 1 0 60 0 ECO
31 Jan 11 23:48:07 tcp 10.10.238.252.12200 -> 10.28.5.232.27977 1 0 60 0 REQ
01 Feb 11 01:10:59 icmp 10.15.36.226 -> 10.28.5.232 1 0 60 0 ECO
01 Feb 11 01:11:00 icmp 10.15.36.226 -> 10.28.5.232 1 0 60 0 ECO
01 Feb 11 01:13:45 tcp 10.10.238.252.12200 -> 10.28.5.232.27977 1 0 60 0 REQ
01 Feb 11 01:36:13 udp 10.18.16.98.5060 -> 10.28.5.232.5060 1 0 454 0 INT
01 Feb 11 03:22:34 tcp 10.10.238.252.12200 -> 10.28.5.232.27977 1 0 60 0 REQ
01 Feb 11 04:05:51 tcp 10.10.238.252.12200 -> 10.28.5.232.27977 1 0 60 0 REQ
01 Feb 11 04:48:32 tcp 10.10.238.252.12200 -> 10.28.5.232.27977 1 0 60 0 REQ
It is designed to run as a service, however you must figure out the best way to rotate out files depending on your system, storage, and throughput. You should be able to point it at one of your router's interfaces and get all of the information you desire.
As a bonus, tt also comes with a significant number of helper utilities with which you can do fun stuff like traffic graphs, accounting, and other kinds of analysis. See the NSMWiki page for some details on exactly the kind of analysis that can be run.