Pingは、サーバーが利用可能かどうかを確認する信頼できる方法ですか？
私のアプリケーションでは、サーバーにpingを送信し、応答を待っています。これを使用して、サーバーが使用可能で応答性があるかどうかを判断しています。
これは可用性を判断する信頼できる方法ですか？ファイアウォールがICMPトラフィックをフィルタリングしている可能性があると思います...他の欠点はありますか？より信頼できる方法はありますか？
特定のリモートサービスが生きているかどうかを確認する最良の方法は、意図したとおりにリクエストを処理するように依頼することです。実際、これは、何かが正しく機能していることを本当に知る唯一の方法です。
例として、私は常にロードバランサーにWebサーバーから実際の「ヘッド」応答を返すようにします。必要に応じて、DBボックスの小さな選択に対して、または実際のサーバーが提供するものに対して同じことを行うことができます。ヒントとして、Webサーバーに 'online.txt'（またはファイルに付ける任意の名前）を作成し、LBにそのファイルの取得を試行させます。失敗した場合、サーバーをVIPから削除します。これは単一のファイルの名前を変更するだけで、VIPから個々のサーバーを手動で削除する優れた方法。
Pingはpingに応答する能力のテストのみを行うため、これはベースOS、IPスタックの一部、および物理リンクです。しかし、それだけです。他のすべてがダウンしている可能性があり、ユーザーにはわかりません。
これについては後述しますが、何度も繰り返すことになります。
ICMPエコー要求（別名「Ping」）（別名ICMPタイプ8）は、IPスタック仕様に組み込まれています。ただし、実装または使用する必要はありません。実際には、それらを転送することを拒否し、それらのリクエストをネットワーク攻撃（pingフラッドと呼ばれる）の形式であるため、これらのリクエストを静かにドロップするインターネットプロバイダーが多数あります。
上記のように、これはOSによって（特にネットワークスタックレベルで）処理されるため、それらに応答するかどうかはOSの構成次第です。これがオフになっている場合（セキュリティ対策？）、相手からのping応答の受信については何もできません。これが信頼できない理由です。
ただし、ほとんどの場合、そうです。
一部のサーバーはpingリクエストをブロックします
サーバーが応答しているから自動的にWebサイトを意味しない（または、使用する予定のサービス）機能している、応答が予期されたコンテンツと一致するかどうかも確認する必要があります。
多くの場合、ICMPトラフィックは除外されるため、信頼できない可能性があります...
より良い方法は、おそらく、興味のあるサービスポートでサーバーにtelnetを実行することです。
つまり、telnet 127.0.0.1 8080
サーバーがpingに応答するだけでよい場合は、これがサーバーの可用性を判断する良い方法です。たとえばWebサービスを提供する必要がある場合は、何らかのテストを実行して、ファイルサービスなどで同様に機能するかどうかを確認する必要があります。
pingには2つの欠点があります。
- pingはicmpを送信します。ファイアウォールでフィルタリングできます。
- アプリケーションが使用するtcpまたはudpポートがビジーであるか、開いていない可能性があります-pingはそれをチェックしません
より良い解決策は、udp/tcpポートを直接チェックして、サービスがまだ利用可能かどうかを確認することです...：-）
探しているサービスをテストします。サーバーにpingするだけでは、サービスが機能しているわけではありません。
例えば：
数十のウェブサイトを備えたウェブサーバーを想像してみてください。次に、ウェブサイトが稼働しているかどうかを知る必要があります。自分でphpで小さなスクリプトを作成し、10分ごとに実行しました。
スクリプトは次のようにします->
<?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);
?>
Pingを使用してサーバーが使用可能かどうかを判断することは、ER医師が患者の呼吸を確認するようなものです。はい、それは開始するのに良い場所ですが、他の問題があるかもしれません。
pingを使用して、ssh接続を試行するsystemdサービスを起動する前に、ホストの電源がオンで到達可能であることを事前確認します。 systemctl startコマンドは警告なしに失敗してJournalctlジャングルで失われるのではなく、すぐに失敗するため、これによりデバッグにかかる時間が節約されます。
PingはTCPと同じ意味では「信頼できる」ものではないことに注意してください。接続が不良である（またはネットワークスタックが不安定でありがちです、ありがとうIntel mpss）場合、パケットがドロップされると、単一のパケットpingが失敗することがあります。一方、TCP接続は、ドロップされたパケットに対して信頼性があります。そのため、皮肉なことに、ssh接続は機能する可能性があります単一のpingの直後failure。したがって、pingを使用してサニティチェックを行う場合は、何らかの失敗を許可するようにしてください。
私の2セントだけ：このメソッドを使用するレガシーアプリケーションがあり、pingがnotでサービスの可用性を判断するのに十分であったため、サービスを提供する必要がありました。
Pingは、サーバーがリッスンできることを示しているだけですが、私たちの場合、サービスは人間の介入なしでは開始できませんでした。
その結果、サーバーが使用可能であると単純に想定していたユニットが、接続とタイムアウトを試みました。 「サーバーが利用できません」というメッセージを表示する代わりに。
-
XMLHTTPRequestsを介してWebサーバーと通信する現在のアプリケーションは、サーバーがステータスコードで応答する形成されたメッセージを送信します。ステータスコードは、さまざまなサブシステムがオンラインになっていることを確認するためにサーバーがいくつかのチェックを行うことによって計算されます（DB、必要なディレクトリが書き込み可能など）。
Ping（Packet Internet Groper）は、システムがネットワーク経由で接続を確立したいシステムと通信しているかどうかを知らせます。 pingを実行しても、RemoteRegistryサービスなどのサービスが実行されているわけではありません。
ただし、問題を修正するには、pingが必要です。リモートで問題を修正できます。したがって、pingには独自の重要性があります。
通常の状況でサーバーがpingに応答する場合は、1分間隔でpingを実行して応答するかどうかを確認すると便利です。もちろん、これはそのIPアドレスにサーバーがあり、pingの送信元から宛先へのネットワークパスがあることを通知するだけです。応答時間のしきい値を設定すると、ネットワークの状態を監視することもできます。インターネット上のサーバーにpingを送信している場合、ネットワークを修正するためにできることはほとんどないかもしれませんが、顧客から苦情があった場合、問題はすでに認識されています。さらにgoogle.comへのpingも役立ちます。あなたとグーグルの両方がダウンしている場合、何かが起こっています。
他の人が述べたように、提供しているサービスが応答していること、およびそのパフォーマンスに問題がないことを監視することが重要です。つまり通常は1秒で応答するWeb時代がなぜ10秒だと応答しているのかを確認したい場合があります。
したがって、サービスが応答しておらず、pingが失敗していることを知ることで、1つのアプローチよりも多くの情報を得ることができます。また、プロセスも監視している場合、pingが応答することを知っていると、サービスは応答せず、Webサーバーには正しい数のプロセスがないため、最初にどこを探すべきかがわかります。
あなたは監視に夢中になることができますので、何か悪いことが起こったときや危険になっているときに通知するのに十分な監視をしてください。つまりスワッピングが多すぎる、90％を超えるディスク使用率、高いディスクio、100％のCPUが長期間にわたって続くこと、および監視は非常にゆっくりと実行されるサービス拒否攻撃にすぎないことを覚えておいてください。