問題タブ [monit]

私は、勤務先の会社のサーバークラスターをセットアップしており、Monitを使用して、すべてのサーバープロセスが正常に実行および動作していることを監視しています。

Apacheの監視には、ここで説明するmod_status機能を使用したいと思います。しかし、これは非常に困難であることが判明しました。MonitとApacheの両方をどのように構成しても、Monitは接続障害エラーを報告し続けます（connection failed to 127.0.0.1:80 [APACHESTATUS via TCP]）。

運が悪かったので、MonitWikiの指示に従いました。Apacheステータスページ（http://127.0.0.1/server-status?auto）ページは、テストしたすべてのブラウザで機能します。また、運が悪ければホストをから127.0.0.1に変更してみました。localhost

このセットアップをMonitバージョン4.8.x、4.10x、および5.0-beta6でテストしましたが、すべて同じ結果になりました。また、ほとんどの結果はより些細で単純な問題に関するものであるため、Googleにも役立つ情報はあまりありません。

私は何かが足りないのですか？それとも私はたぶん愚かですか？

プロセス監視に使用するものとその理由は?

Monit でdelayed_jobを監視する方法の例はウェブ上にありますか?

私が見つけることができるものはすべてGodを使用していますが、Ruby で長時間実行されるプロセスは一般的にひどいので、私は God を使用することを拒否します。(God メーリング リストの最新の投稿は? God のメモリ使用量は着実に増加しています。)

更新: delayed_job には、この質問に基づいたサンプルmonit 構成が付属しています。

XMPP 通知とアラートの電子メールを送信するように Monit に指示する方法はありますか?

We have a rails app running on passenger and we background process some tasks using a combination of RabbitMQ and Workling. The workling's worker process is started using the script/workling_client command. There is always only one worker process started, and the script/workling_client has a :multiple => false options, thus allowing only one instance. But sometimes, under mysterious circumstances which I haven't been able to track down, more worklings spawn up. If I let the system run for some time, more and more worklings appear. I'm not sure if these rogue worklings cause any problems, but it is still unsettling not to know why is it happening. We are using Monit to monitor the workling process. So if it dies, it will spawn it up again. But this still does not explain how come there are suddenly more than one of them.

So my question is: does anyone know what can be cause of this and how to make it stop? Is it possible that workling sometimes dies by itself, without deleting it's pid file? Could there be something wrong with the Daemons gem workling_client is build upon?

それで、私はDelayed::Jobを本番環境でしばらくの間泳いでいました。

仕事に変更を加えるときはいつでもそうします（すべての生産環境であなたを気にかけます）

1. [スクリプト] ( https://github.com/tobi/delayed_job/wiki/Running-Delayed::Worker-as-a-daemon )を使用して遅延ジョブを再起動します。
2. を使用してジョブをクリアしますrake jobs:clear

また、monit を実行しています。monit を停止し、スクリプトを再起動してから、monit を開始しました。この順序で...まだサイコロはありません。

とにかく、私たちは皆、古いジョブをメモリから取り出すためにこれを行います。ジョブ キューをクリアするのは、私がそうしているためです。そのステップは必要ないかもしれませんし、私のアプリでは問題ありません。

ただし、最近これらの手順を使用しても、何らかの理由で新しいジョブ コードがリセットされません。job_runner.log ファイルを見ると、スクリプトを再起動するとこのエラーが発生します

だから私は何が起こっているのか分かりません。そのスタック レベルが深すぎるというエラーは、私のコードに起因するものですか? 以前と同じように、すべての統合テストに合格しました。

スライスにメモリの問題がありますか? free私がそれをすると、平均で300MBあると言われますが？

ここで兄弟を助けることができるのは誰ですか?

delayed_jobサーバーが壊れた場合、サーバーはmonit自動的に再起動しdelayed_jobますか?

monitのデバッグは大きな苦痛だと思います。Monitのシェル環境には、基本的に何も含まれていません（パスやその他の環境変数はありません）。また、私が見つけることができるログファイルはありません。

問題は、monitスクリプトのstartまたはstopコマンドが失敗した場合、何が問題なのかを識別するのが難しいことです。多くの場合、シェル環境はmonitシェル環境とは異なるため、シェルでコマンドを実行するほど簡単ではありません。

人々がモニター構成をデバッグするために使用するいくつかのテクニックは何ですか？

たとえば、monitシェルを使用してスクリプトをテストしたり、ログファイルを使用して何が問題になったかを確認したりできれば幸いです。

ローカルマシンで完全に動作するアプリがあり、現在デプロイしています。私はVPSをすべてセットアップしましたが、それもほとんど機能します。私の問題はdelayed_jobを開始できないことに起因します。アプリにSSHで接続しているときに「rubyscript/delayd_job start RAILS_ENV = product」を実行すると、「delayed_job：process withpid11547started」が返されます。htopでプロセスを探すと、見つかりません。

だから私は掘り下げて、Monitがdelayed_jobを続けることができることを読みました。そのようにdelayed_jobを起動できることを期待して、それを設定しました。ただし、delayed_job.pidはないので、遠くまでは行きませんでした。しかし、最終的にnginxとmysqlを設定し、delayed_jobの設定を終了したいと思います。delayd_job.pidの欠如が邪魔になります。

アプリにSSHで接続し、「rake jobs：work RAILS_ENV = Production」を実行すると、すべてが正常に機能します。ですから、アプリ自体は問題ないと確信しています。

私はcollectiveideaのdelayed_jobを使用しています。助けてくれてありがとう。

monit を使用してプロセス グループのローリング再起動を実現する方法について、誰か提案はありますか?

前もってありがとう、フタートル