jdalrymple wrote:*it won't help* but maybe a step to take would be to dump the data to a pcap file then feed it into sfcapd in a more "labby" type environment then maybe more data can be extracted from sfcapd during the crash.
Is there no chance of going this route? We would only need the data to be collected long enough to be ensured that a crash of sfcapd would have happened, so if your flow only lasts 10 minutes generally - 15 should be a good number.
If not, I think fiddling with those other parameters would be just that - 'fiddling' My initial thought would be to lower the metrics slightly from 1400 and 128 to maybe 1200 and 96 or some such.
cd /tmp
wget http://sourceforge.net/projects/nfdump/files/stable/nfdump-1.6.13/nfdump-1.6.13.tar.gz/download
tar xzf download
./configure --prefix=/usr/local --enable-sflow --enable-nsel
make
make install
Be sure to check out our Knowledgebase for helpful articles and solutions!
Good news ! The sflow source doesn't interrupt anymore since my reboot yesterday evening. It seems that nfdump reinstallation is working . Can you tell me if the nfdump version we downloaded is the same version as the orginal ? It this something that we need to do if we reinstall the server for any reason ?
That is good news.
To answer your question, nfdump-1.6.13 does come with the latest version of Network Analyzer but NSEL isn't compiled in it. The next version will have that enabled.
With the libc errors you were getting, it looks like the previous compile didn't work or some other package was updated causing a compatibility issue so it is hard to say what was causing it.
Be sure to check out our Knowledgebase for helpful articles and solutions!