Hello Ivan (and all),
i've just made available for download a fresh tarball (as usual, it
is a pre-release so pretty no updates to the documentation and, if
you decide to give it a try, upgrade as soon as the final release
is out):
http://www.ba.cnr.it/~paolo/pmacct/pmacct-0.10.0rc2-20060207.tar.gz
A few relevant changes since 0.10.0rc1:
===
* Introduction of the connection tracking (conntrack) engine
- tracking of FTP data channel spawned by the following commands:
PORT/PASV/LPRT/LPSV/EPRT/EPSV
- tracking of RTSP data channels
* SIGUSR1 no more shutdowns sfacctd and nfacctd :-)
* pidfiles are destroyed as soon as the process exits (nicely; if
it dies, eg. kill -9, the pidfile will still lie out there).
* pidfiles are now also created (and destroyed) by plugins.
* SEGV fixed if classificators are specified but 'snaplen' isn't.
===
On Tue, Feb 07, 2006 at 03:39:07PM +0000, Ivan A. Beveridge wrote:
> I believe I've just found what looks to be another bug(let). I have
> added "sfacctd_renormalize: true" to the above and restarted. The sample
> rate I'm currently using is 2048 on all ports and kit (this may well vary).
>
> However, "pmacct -s" reports various PACKETS counters < 2048 (and the
> rest of the packet counters, and the BYTES aren't multiples of this
> sample rate, as would be expected).
Can you please send me a pcap trace of sFlow datagrams that show this
trouble ? Because the renormalization algorithm works by basing upon
few informations carried inside the datagram, such traces would help
and speed up the investigation. I think we can follow-up on this point
privately.
> True. You could allow "sfacct -f -". I would imagine that it would run
> with defaults if you had a zero-length config file (although I haven't
> checked), just as there are default values to all the config keys currently.
Let me think to a possible solution on this. The '-f' with no value is a
possible way to go. The '-' usually means 'read from stdin' and is very
likely to generate confusion. Stay tuned on this.
> Ah ... that's right - I did notice that when reading the first time. I'm
> not sure whether that will help my situation (as I need to write in a
> different RRD file depending on what the mac address is), but thanks for
> the reminder :)
I was imagining something (VERY trivial) like what follows (and in the case
i'm totally missing the point, then feel free to just ignore me :-) ):
control_file:
===
<aggregation data A> | <RRD path A> | <more parameters>
<aggregation data B> | <RRD path B> | <more parameters>
<aggregation data C> | <RRD path C> | <more parameters>
<aggregation data D> | <RRD path D> | <more parameters>
...
===
Then:
shell> cat /path/to/control_file | awk -F "|" '{ print $1 }' > /path/to/tmp.txt
shell> RDDPATHS=`cat /path/to/control_file | awk -F "|" '{ print $2 }'`
shell> COUNTERS=`pmacct -c <primitives> -N "file:/path/to/tmp.txt"`
Then basing on the fact that values in $COUNTERS are in the same order of
those in $RRDPATHS, the job should be just matter of a pair of loops.
Cheers,
Paolo
