-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/02/2006 00:57, Paolo Lucente wrote: > On Mon, Feb 06, 2006 at 05:01:44PM +0000, Ivan A. Beveridge wrote: > >> This is my current logfile: >> >> ============================= >> daemonize: true >> pidfile: /var/run/sfacctd.pid >> sfacctd_port: 6500 >> sfacctd_ip: 127.0.0.1 >> plugins: memory[fdrypeer] >> aggregate[fdrypeer]: src_mac, dst_mac >> imt_path[fdrypeer]: /var/run/sfacct_fdrypeer.pipe >> syslog[fdrypeer]: local4 >> imt_mem_pools_size: 65536 >> ============================= >> >> * kill -USR1 on the core process seems to kill it (rather than dump >> stats to console/log) > > Messy SIGNALS documentation, my fault; the ChangeLog tells the truth: > SIGUSR1 is handled (nicely) just by pmacctd and it returns a pair of > counters from libpcap. sfacctd and nfacctd actually don't support it > (however they should either ignore the signal or handle it gracefully > now on). In future, i think it's a good idea to add a kind of global > counters and a bare summary screen (like: x Net/sFlow packet received, > y errors encountered, z bad seq numbers, j missed datagrams, etc.)
Cool - I'll leave it as a suggestion (being able to get status like this would be useful .. to make sure things are working as expected). Stopping USR1 killing the process would be good, though :) >> * Nothing seems to get written to syslog (it would be nice to get at >> least a startup/shutdown message as confirmation it works). > > This is because you attached the syslog directive to the 'fdrypeer' > plugin (which is a memory plugin and has pretty nothing to log until > the memory table is full or the memory is finished); try rewriting > it 'syslog: local4'. <oops> .. that works :) 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). I've scanned the past several months' ML archives and can't see any references to this, so perhaps it is something I'm doing wrong. Any pointers gratefully accepted :) >> Other suggestions: >> * pidfile does not get removed when process gets stopped/killed. >> * way of 'automatically' getting the pid of the children for a >> particular plugin (akin to being able to get the pid of core from the >> pidfile). >> * compile-time default location for config file > > Let me thank you for your suggestions. The first is clear and ok. About > the second, a possible way: one specifies 'pidfile: <pidfile>' into his > configuration; then <pidfile> remains the pidfile for Core Process, while > <pidfile>.<type>.<name> can become the syntax for pidfiles for the active > plugins (type and name are both needed as if more plugins are spawned and > no specific name is attached to them, each name will default to 'default'). That would be good! > The third is tricky to achieve, instead: by default it's assumed the use > of command-line options; this approach rewards in the fact that lets the > user that has downloaded pmacct for the first time to understand what it > does without being forced to get in touch with the configuration syntax. 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. I *would* want it to complain (and not start) if there was no config file though (eg if you specify a filename and it isn't there) .... you are more likely to notice a screw-up if the process isn't running than if it is but not collecting the right/any data. > Lastly, i've read your following mail about how to retrieve the counters > from the memory table; a way is parsing the output got from 'pmacct -s'. > Of course, it's ok if you plan to do something with either all or the > vast majority of the entries in your table. However, if this is not the > case consider the following way: > > shell> pmacct -c sum_host -N "file:/path/to/queries.list" > > where queries.list contains the data to be matched, one per line: > > === > 192.168.0.1 > 192.168.0.2 > 192.168.0.3 > ... > === > > It will batch all queries for you and could result in something definitely > more tailored for your scenario. Of course, results will be shown one per > line, same order of the list. 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 :) Cheers Ivan - -- Ivan Beveridge <[EMAIL PROTECTED]> http://www.linx.net/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFD6L8bQQZN5jq7vncRAuFpAJ9fmMyyRHW5vxYYtwXtI9Zn5fT/pwCdGttb yvSI+ub4o4S5eJTzwC48B3Y= =fHLf -----END PGP SIGNATURE-----
