必要：サーバー上のプロセスをリモートで監視する簡単な方法
Javaプロセスを実行しているクラウドベースのサーバーがあります（davmailと呼ばれるPOP/SMTPサーバー、詳細は実際には重要ではありません）。
そのJavaプロセスのステータスをリモートで監視する最も簡単な方法は何ですか？それがダウンするかどうか、いつダウンするかを知る必要があります。sshセッションを開いたままにして、ログを追跡することもできますが、もっとエレガントなものはありますか？
たぶん、Webサーバーをインストールして、同じサーバー上でいくつかの監視ソフトウェアを実行する必要があります。または、ローカルマシン（Mac）で実行できるクライアントプログラムがあり、Javaプロセスが停止するたびに、サーバー上のcronジョブによってアラートを受け取ることができますか？
さて、あなたはいつでもcronjobを実行させることができます
echo "100 logout" | nc yourserver.fqdn 143 || \
{
echo "The server is down" |\
mailx -s "Red alert! Red alert! This is not a drill!" [email protected];
}
あなたがシンプルと呼ぶものとあなたが望むかもしれない他の機能に依存します。
100 logoutは非常に簡単なIMAPコマンドであり、これまでにログインしたことがない場合は、サーバーに接続を終了させます。ncは、TCP接続を開き、STDINとSTDOUTをソケットに接続するツールです。
この組み合わせにより、IMAPサーバーへの接続が確立され、「完了しました」と通知されます。 IMAPサーバーが稼働している場合は、コマンドを認識してTCP接続を閉じ、ncを正常に終了させます。
TCP接続が確立されない、またはサーバーがIMAPコマンドを処理しないためにタイムアウトするなど、問題が発生した場合、IMAPサーバーは明らかに使用できません。その場合は通知。その場合、ncは常に異常終了します。
||は、ncが異常終了した場合、{ ... }が実行されます。ここで提供するコマンドの例では、mailxを使用して[email protected]に、件名が「Red alert！Red alert！これはドリルではありません」と内容が「サーバーがダウンしています」というメールを送信します。
ただし、mailxはすべてのLinuxのインストールの一部ではなく、異なるバージョンがあり、動作が異なることに注意してください。
もちろん、いくつかの監視ソフトウェアをデプロイすることもできます。たとえば、 Shinken は、すばらしいWebフロントエンドを備えており、監視対象を追跡し、電子メールを送信できます。
それはすべて、「ダウン」の意味によって異なります。実行していることや実行していることの詳細 do は、監視するときにも重要になる傾向があります。
「サービス」を監視する最も徹底的な形式は、外部の自動化システムにクライアントが行うことを実行させ、いつ予期しないことが発生します。
メールサービスの簡単な説明から、私の最初のエンドツーエンドのテストは次のようになります。
- メールを送る
#idSMTP経由でローカルのmonitorアカウントに - 必要な最大秒数を待ちます。
- メールを確認してください
#id@monitorPOPサーバー上。
外部の監視ホストからの1つのチェックで、単純な電子メールシステムで発生する可能性のある問題の約99％が検出されます。
これらのサービスまたはトランザクションモニターは、 Ruby 、 Python または Perl のようなもので記述されたカスタムスクリプトである傾向があり、 [〜＃〜] smtp [〜＃〜] または [〜＃〜] pop [〜＃〜] プログラムで。その後、スクリプトは通常、監視ソリューションにプラグインしますが、単純なものが必要な場合は、単純な電子メールまたはcronジョブからのゲートウェイ経由のSMS）をトリガーするだけで十分です。監視ソリューションの料金を支払う場合は、通常、同じタイプのモニターのGUIデザイナーを試してみてください。
もちろん、現実の世界では、これはすぐに複雑になります。別のチェックが必要なPOPとSMTPの両方に安全なポートを提供する場合があります。たぶんIMAPはCarddavとCaldavのビットで追加されます、あなたは複数のホストでサービスを持っているかもしれません。
上記のような全体的なサービスチェックでは簡単にはわかりませんが、どこに問題があるのか、どこかに問題があるというだけです 。
低レベルの監視
サービスの個々のコンポーネントを監視することにより、基本的に、脚の作業を行う前に監視することで問題がどこにあるかを特定（または予測）しやすくなります。このタイプのコンポーネント監視は、 Nagios 、 Zabbix のようなシステム、または Tivoli Monitoring のような大きなシステムが得意なものです。
これは、作成する詳細度や、「サービス」をサポートするシステムの複雑さに応じて、拡大し続けるツリーになる可能性があります。
「あなたのメールサービス」は
Services: POP:110 SMTP:25
Application: devmail
OS: linux Z
Host: server Y
Components: diskA diskB cpu1 cpu2 memory
Ntwork: ethernetA, Switch B, Router C, Firewall X
各コンポーネントには、レポートできるメトリックまたは状態があります。
外部的に
Service:
POP service - Are we accepting connections on 110,995
SMTP service - Are we accepting connections on 25,587
ローカルで
Application:
devmail process(es) (is it running, memory, cpu, handles, io)
JMX parameters of the Java process (memory, threads, performance, garbage collection)
OS:
Disk, Memory, Cpu, IO
etc...
監視ホストがダウンした場合はどうなりますか？または、サービスとモニターの間のネットワークだけです。
一般に、クライアントの送信元にできるだけ近い2つ（またはそれ以上）の外部ホストからサービスチェックを実行することをお勧めします（監視に影響を与えることはありません）。次に、ホスト上でローカルに、または少なくともローカルネットワークからチェックを実行します。このようにして、ほとんどのネットワークベースの問題をよりよく理解できます。
- 1つの外部クライアントに障害が発生した場合は、おそらく外部ネットワークです。
- ローカルクライアントは機能しているが、すべての外部クライアントに障害が発生している場合、おそらくローカルネットワーク。
- すべてのクライアントに障害が発生している場合は、おそらくローカルの問題です。
多くの人が監視ソリューションを間違った方法で構築する傾向があるようです。彼らは、多くの低レベルのシステムメトリックと、何千ものモニターとレベルを考え出しますが、それが本当に重要な場合は、警告するのが適切であると考えています。つまり、分析と容量管理に適しています。これらすべての値からいくつかのしゃれたグラフを作成でき、非常に便利ですが、レベルyでメトリックxを見逃した場合、つまり誰も受け取ることができない場合は、あまり意味がありません。メール。
SNMPトラップ、電子メール、ハードウェアまたはソフトウェア/サブスクリプションがある場合はSMS）など、さまざまな方法でアラームを送信するように構成できる監視アプリケーションはいくつもあります。それらのうち、必要に応じてそれ自体でプロセスを再開することもできます。
Google for monit、nagios、または単に「監視ソフトウェア」。また https://softwarerecs.stackexchange.com/ は、推奨事項を尋ねるのに適した場所かもしれません。
Nagiosまたはmonitをローカルで使用することは避けるのが難しいですが、 https://cronitor.io のようなものを使用してnagiosプロセス自体を監視することにより、優れた2番目の防衛線を得ることができます。クロニターアドレスに対してヘルスチェックを実行するようにnagiosまたはmonitを設定すると、ヘルスチェックが実行されない場合に警告が表示されます。
試してみることをお勧めします SeaLion 。これは、クラウドベースのLinuxサーバー監視ツールです。インストールはほんの数秒で完了し、UIはクリーンでシンプルです。さらに、アラート機能は素晴らしいです。サーバーのパフォーマンスの概要を記載した時間指定の電子メールを毎日送信する「毎日のダイジェスト」機能があります。