Ask HN: A simple tcp monitor ?
17 comments
There you go :)
#include <string.h>
#include <stdio.h>
#include <unistd.h>
#include <netdb.h>
int main(int argc, char ** argv)
{
struct hostent * he;
struct sockaddr_in sa = { AF_INET };
unsigned int port;
int foo, sk;
if (argc != 3)
return 1; /* Syntax error */
if (sscanf(argv[2], "%u%n", &port, &foo) != 1 ||
strlen(argv[2]) != foo ||
port > 65535)
return 1; /* Syntax error */
he = gethostbyname(argv[1]);
if (! he)
return 2; /* DNS error,OS error or syntax error */
sa.sin_addr.s_addr = *(unsigned long*)he->h_addr;
sa.sin_port = htons(port);
sk = socket(AF_INET, SOCK_STREAM, 0);
if (sk < 0)
return 3; /* OS error */
if (connect(sk, (void*)&sa, sizeof sa) < 0)
return 4; /* TCP error */
return 0;
}
To build: gcc tcp-check.c -o tcp-check
To use: ./tcp-check yahoo.com 80; echo $?
0 is OK, 1 - syntax error, 2 - DNS error, 3 - OS error, 4 - TCP error. Call it from a shell script, look at the return value and, if it's non-zero, dispatch your message. Then stick the script itself into a cron schedule, and you are done.Thank you very much for the effort :)
Sounds like a simple-enough prog to build: check the port regularly and shell out a command if conditions are met.
The trick will be just limiting it to simple functionality. Easy for these types of apps to get out of hand.
About ten years ago I wanted to write a windows app that allowed text to appear as a window -- no rectangular frame, menu, or close button. Just text. The text was the window, and there was nothing else but the text.
I figured out how to do it, and ended up writing something that had a properties page that looked like it could launch Trident Missiles. Fun project, but definitely overkill for what I needed.
The trick will be just limiting it to simple functionality. Easy for these types of apps to get out of hand.
About ten years ago I wanted to write a windows app that allowed text to appear as a window -- no rectangular frame, menu, or close button. Just text. The text was the window, and there was nothing else but the text.
I figured out how to do it, and ended up writing something that had a properties page that looked like it could launch Trident Missiles. Fun project, but definitely overkill for what I needed.
One problem with any auto-fix script is what if it goes berserk? What if your mail server is dying because of overload and the auto-fix keep restarting it? The overload will never clear out. If you go with the auto-fix solution, remember to add a throttle to the number of times it restarts a service.
A buddy of mine is on a holiday and asked me to monitor his pages for him. Little did I know that his goes off a bit more frequently than I like :) One of the problems I've traced back to a java process that hangs with some regularity. Because I don't want to go and mess with it beyond my current understanding of the system and the system seems to come back up reliably after restarting the service I figured that a quick & dirty way to guarantee a good nights sleep would be to auto-restart the process on failure to retrieve a url due to time-out or other connect issues.
Nagios will do the job but it's total overkill. Ideally a simple solution such as:
Nagios will do the job but it's total overkill. Ideally a simple solution such as:
./monitor http://localhost:someport/ 60 "/etc/init.d/someservice restart"
should do the trick (resource, checkinterval, action)If you already know how Nagios works or have set it up previously, then you and your friend may be better off if you go with it even if it is "overkill". You could probably have it done in 20 minutes and when your friend gets back they'll have something standard and easy to maintain or extend.
Grab the Nagios plugins tarball, build it on linux, and find the check_tcp program. Wrap a little shell program around check_tcp that will either do nothing, or fire off your script depending on the return code of check_tcp. Run this once a minute out of cron. Make sure these scripts won't stack up, by either setting check_tcp's socket timeout to less than 60 seconds, or have the script initially check to make sure no other of its kind are running.
Make sure these scripts won't stack up
And that's exactly why you don't roll these things on your own unless you have a very good reason. Making sure a cronjob doesn't stack up reliably is non-trivial and becomes extremely hairy when the network gets involved. Many people think "I'll just use a lockfile" - think again.
Since for monitoring scripts this kind of reliability is the whole point, I strongly suggest to use something like monit where someone else has already worked out all the little corner cases.
And that's exactly why you don't roll these things on your own unless you have a very good reason. Making sure a cronjob doesn't stack up reliably is non-trivial and becomes extremely hairy when the network gets involved. Many people think "I'll just use a lockfile" - think again.
Since for monitoring scripts this kind of reliability is the whole point, I strongly suggest to use something like monit where someone else has already worked out all the little corner cases.
[deleted]
The OP is not likely interested in monitoring software advocacy, he wants "a quick & dirty way to guarantee a good nights sleep" while his buddy is on vacation.
I still think a smart wrapper around check_tcp is the way to do this. Perhaps not out of cron, it can instead be a long running process in a sleep/fork/exec(check_tcp)/waitpid loop.
I still think a smart wrapper around check_tcp is the way to do this. Perhaps not out of cron, it can instead be a long running process in a sleep/fork/exec(check_tcp)/waitpid loop.
Have you looked at god [1]? If you're into Ruby, you'll love it.
I use it in a medium to high volume production environment [2], and it has done a very good job at getting our lighttpd and nginx back up on the air whenever we experience peaks above the normal workload.
[1] http://god.rubyforge.org/
[2] http://video.nrkbeta.no/
I use it in a medium to high volume production environment [2], and it has done a very good job at getting our lighttpd and nginx back up on the air whenever we experience peaks above the normal workload.
[1] http://god.rubyforge.org/
[2] http://video.nrkbeta.no/
[deleted]
On a simmilar note, HAProxy can proxy http traffic or just tcp traffic, which you can use to cluster your service and provide a little redundancy.
http://haproxy.1wt.eu/
http://haproxy.1wt.eu/
I'm sure I can whip up something simple but my experience is that such simple things tend to get more complicated than you expect once you start building.
The intended platform is linux.