13

I'm monitoring the TCP stack on a server hoping to generically infer problems with application on the box.

My first inclination is to measure the number of sockets in all reported states (LISTEN,ESTABLISHED,FIN_WAIT2,TIME_WAIT, etc) and detect some anomalies.

A teammate suggests that 'lsof' would be a better tool to see what state the TCP stacks are in.

Any preferences or experience tips from the serverfault crowd?

Improve this question
1
  • 3
    Please add a *nix tag to scare away us Windows geeks
    – KevinH
    Jul 7, 2009 at 16:27

4 Answers 4

Reset to default
8

I prefer lsof because it's output is consistent across all platforms on which it runs. You can pretty much get the same info from both programs, though. I think it comes down to personal preference.

Improve this answer
2

My first implication would be to use netstat -ptan which will give you all the information you are looking for. Probably pipe to sort and uniq. The following should give you a good number of socket status'.

netstat -ptan | awk '{print $6 " " $7 }' | sort | uniq -c

Improve this answer
1

Check out dstat and run with:

% sudo dstat --tcp

Even better, if you want to analyze the output, you can have it write to CSV with --output.

Improve this answer
1
  • Interesting tool, alas linux only (though understandably so). Nice to see something akin to SAR that includes network info (though linux sar versions seem to show that too).
    – ericslaw
    Jul 13, 2009 at 11:31
1

I think it's really more of a personal preference, as with a little tweaking (and the right command options) you can get just about the same information from either.

However, if you're wanting to monitor the number of connections in various states, I wouldn't do that with a single-shot command line tool. I'd make use of something that can do some trending so you can review it over time. Something like munin would be very useful, as it would graph it over time (along with showing you other potentially useful system statistics).

Troubleshooting an application is always easier if you have good information about the box itself and how it's performing (both during problems and when problems are absent).

Improve this answer
1
  • The command line tool is for collection only. Your point of collecting data for a baseline is indeed the propr approach.
    – ericslaw
    Jul 13, 2009 at 11:34

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .