Is Ping a reliable way to check if a server is available?

The best way to tell if any given remote service is alive is to ask it to service a request in the way it's meant to - in fact it's the only way to truly know something is working correctly.

As an example I always get my load-balancers to get an actual 'head' response back from our web servers, you could do the same for a small select on a DB box if you wanted to, or whatever your actual server serves. As a tip you can create an 'online.txt' (or whatever name you want to give it) on your web servers, have your LBs try to get that file and if it fails then it removes the server from the VIP, this is a nice way of manually taking individual servers out of your VIPs simply by renaming a single file.

Ping only tests for the ability to respond to pings, so that's base OS, parts of the IP stack and the physical links - but that's all, everything else could be down and you'd not know.

I know this is mentioned below, but it bears repeating again and again.

ICMP Echo Requests (aka "Pings") (aka ICMP Type 8) are built onto the IP stack spec, yes, but are not required to be either implemented or used. As a matter of fact, there are a large number of internet providers who refuse to forward those and silently drop those requests, as they are a form of network attack (called a pingflood).

As mentioned above, this is handled by the OS (specifically at the network stack level) and so it is up to the OS configuration to respond to those or not. If this is turned off (a security precaution?), you can't do anything about receiving ping replies from the other end. This is why it's not reliable.

Most of time, yes, however:

• some servers block ping requests

• just because the server is responding doesn't automatically mean the website (or whatever service you expect to use) is working, you should also check if the response matches the expected contents.

It is true that on many occasions ICMP traffic is filtered out so it could be unreliable...

A better way perhaps could be to telnet the server at the service port you are interested in.

i.e. telnet 127.0.0.1 8080

If the server is only required to respond to pings then this is a good method of determining it's availability. If is is required to provide for example a web service then you should carry out some form of test to see if that is working similarly for fileservices etc.

ping has 2 drawbacks:

• ping sends icmp, that can be filtered by the firewall
• the tcp or udp port your application uses could be busy or not open - ping doesn't check that

a better solution is to check your udp/tcp port directly, to see if the service is still available... :-)

There are special tools for testing and monitoring like Nagios / Icinga.
With these tools you can (of course) do checks with various ping-test but also do checks on your services.

All checks can use the returned value to classify the result as "good", "warning" and "critical" and can be written in nearly every programming language.

Of course not easy to setup (like point and click), but customisable, reliable and extensible. Runs well on various Linux and Unix distributions.

Test the services you are looking for, just ping a server does not mean the services is working.

For example:

Imagine a webserver with dozen websites, then I need to know if the websites is UP, I did myself a tiny script in php and run it every 10 minutes.

The script do the follow ->

<?php
    $website1 = "http://www.mywebsite.com/";
    $myWebsite = file_get_contents($website1);
    $message = 'My website' . $website1 . ' is DOWN at the moment.';
    if (empty($myWebsite)) mail('[email protected]', 'Website is DOWN', $message);
?>

Using ping to determine if a server is available is like an ER doctor checking to see if a patient is breathing. Yes, it is a good place to start, but there may be other issues.

We use ping to do a precheck, that the host is powered-on and reachable, before launching our systemd service that attempts a ssh connection to it. This saves some time debugging, as the systemctl start command will immediately fail, instead of silently fail and get lost in the journalctl jungle.

Note that ping is not "reliable" in the same sense as TCP. If you have a bad connection (or crappy network stack, thank you Intel mpss) and packets are being dropped, a single packet ping may fail. On the other hand, a TCP connection is reliable against dropped packets. So, ironically, an ssh connection might work immediately after a single ping failure. So if you use ping to do a sanity check, be sure to allow some failure.

Just my two cents: We have a legacy application that uses this method, and had to service it because the ping was not sufficient for determining service availability.

Ping merely shows that the server is capable of listening, but in our case the service was unable to start without human intervention.

As a result units, which naively assumed the server was available, were attempting to connect and timeout. Instead of displaying our "Server is Unavailable" message.

--

Our current application, which communicates via XMLHTTPRequests to a web server, sends a formed message which the server will respond to with a status code. The status code is computed by the server doing a number of checks to ensure that various subsystems are online (DB, necessary directories are writable, etc.)