cronタスクを監視する方法は？

クラスター上のcronタスクを監視するための良いテクニックはありますか？

cronを使用して、毎日の間隔でタスクを起動し始めています。情報をチェックアウトするためのいくつかのアイデア：

1. DBなどの「ネットワーク対応」の場所に情報を記録する特別なアプリケーション処理を追加します
2. cronログを（他の可能なログファイルと一緒に）処理/クエリの中心点に定期的に転送するログファイルシステムを構築します。

人々はcronと他のことを別々にやることで成功したのか、あるいはタスクが完全に別のアプローチに統合されたのか疑問に思っています。私は2番目に傾いていますが、もっと経験のある人が何を試してみるのか知りたいです。

他の答えに加えて：

• ジョブが終了したときに、実際のジョブからの戻り値とともにジョブにタイムスタンプを書き込ませます
• 戻り値を元の呼び出し元に伝播します

Nagios（Icinga）がチェックするのを簡単にするために最初のものを使用します。たとえば、最後に書き込まれたタイムスタンプがn時間（および必要なロジック）よりも古いかどうか-何か問題が発生したことがわかります。

したがって、私の一般的なアプローチは次のとおりです。

• cronされたアプリケーションが正常に完了したときにstdoutを生成しないでください。
• 出力を/ dev / nullにパイプしないでください。
• 何か問題が発生した場合に意味のある標準エラー出力を生成します。
• crontabで$ MAILTOアドレスを設定して、必要なチームにそのエラー出力を送信してください。

上記に加えて：

• 何か問題が発生した場合は、stderrへの書き込みとともに「ロガー」を呼び出してください。さらに「loghost」という中央ホストに転送するようにsyslogを構成します。（ロガーはデフォルトで「user.notice」機能を使用しますが、変更できます。）

cronjobを監視するために使用できるテクニックがいくつかあります。

cronjobの失敗のアラートを受信するには：

• cronの標準MAILTO =関数を使用します。cronjobがSTDERRで出力を生成する場合、選択したアドレスに郵送されます。
• cronメールを追跡して処理するために、それらをチケットシステムに転送できます。

「ネットワーク対応」の場所に情報を記録することを提案するシステムは、syslogのように聞こえます。syslogは、ログを作成する簡単な方法を提供します。通常は、/ var / log / messagesなどのファイルを管理します。どのファイルがログメッセージを受信するかを選択するなど、基本的なカスタマイズを行うことができます。

Syslogは、ネットワーク対応モードで開始できます。たとえば、スレーブがマスターにログインできるように設定できます。

[root@slave ~]#  echo "hello world from slave" | logger -p local1.info

[root@master ~]# tail /var/log/myapp
Jun 29 13:07:01 192.168.1.2 logger: hello world from slave

Red Hatベースのディストリビューションの構成例は次のとおりです。

[root@slave ~]# cat /etc/syslog.conf | grep local1
local1.*                                                @192.168.1.3

[root@master ~]# cat /etc/sysconfig/syslog | grep SYSLOGD_OPTIONS
SYSLOGD_OPTIONS="-m 0 -r"

[root@master ~]# cat /etc/syslog.conf | grep local
local1.* /var/log/myapp

（最初の構成行はlocal1。*ログ通知を@ 192.168.1.3（「マスター」）にリダイレクトします。2番目のSYSLOGD_OPIONS行の-rフラグはネットワークサポートをオンにします。最後に、3番目の構成行は「master」ファイルに）。

syslogアプローチは、エラー/情報のロギングのみに適しています。ログファイルは電子メールよりも可視性が低いため、何か問題が発生しない限り、おそらくログを見ることはありません。

syslogスタイルのルートを選択する場合は、syslog-ng（http://freshmeat.net/projects/syslog-ng/）も検討してください。

もちろん、両方を使用することで、両方のテクニックを最大限に活用できます。たとえば、失敗と成功の両方をsyslogに記録し、失敗をメールで送信するだけです。

StackOverflow（/programming/21025495/system-for-monitoring-cron-jobs-and-automated-tasks）の質問に同様の回答を投稿しました

Cronitor（https://cronitor.io）は、私がまさにこの目的のために構築したツールでした。基本的には、httpリクエストをpingとして使用するトラッキングビーコンになります。

ただし、OPがコメントで言及しているニーズの1つは、ジョブの実行に時間がかかりすぎるときに通知を受ける必要があることです。

これと同じニーズがあり、同様のツールではこの種の監視を簡単にサポートできないことがわかりました。Cronitorは、期間を追跡するためにオプションで開始イベントと終了イベントをトリガーできるようにすることでこれを解決します。

私は1時間ごとにスケジュールされたcronjobを持っていましたが、時間が経つと実行に1時間以上かかり始めたため、継続時間の追跡は私にとって必須でした。お役に立てば幸いです！

この記事を書いている時点ではまだかなりの開発中ですが、https://github.com/jamesrwhite/minicronをご覧になることをお勧めします。あなたが説明する問題を解決するために開発されました。実行するコマンドをわずかに変更するだけで、ジョブの出力と終了ステータスを記録し、そのデータをリアルタイムで中央サーバーに送り返すことができ、ジョブが失敗したときに電子メール、SMS、PagerDutyでアラートを送信できます（終了ステータス> 0）または、必要なときに実行されません。

免責事項：私はそれに取り組んでいる開発者です。

これはAlertGridの古典的な使用例のように見えます。

インストールは不要です。このツールのメリットを享受するために必要なことは次のとおりです。

1. cronジョブが動作するたびにAlertGridにSignalを送信します（これは非常に単純なAPIで実行できます。signalは単なるHTTPリクエストです）。次のようなパラメータを送信することもできますexecution_time！
2. 以下のような通知ルールを設定します。

my_jobがX分（あなたの場合は時間）で応答しなかった場合-> SMSを管理者に送信する

または

execution_time> 60秒の場合->関心のある人にメールを送信する

実際にはそれだけです。優れたビジュアルエディタを使用して通知ルールを管理できます。何かが変更された場合、ソースコードや一部の構成ファイルを変更する必要はありません。一元化されたソリューションであるため、単一の場所からルールを管理することでメリットを得ることができます。

これが誰かを助けることを願っています。無料アカウントが提供されているので、興味がある場合はAlertGridをテストして使用できます。私はAlertGridチームのメンバーの1人です。質問がある場合はお気軽にお問い合わせください。

cronジョブはすでにsyslog経由で記録されています。そのデータは、別の標準サービスであるsyslogdを使用して中央サーバーに送信できます。

http://www.debuntu.org/how-to-remote-syslog-logging-on-debian-and-ubuntu/にこれを設定する方法の詳細があります。

私はhttp://cronrat.comを使用し、&& curl "... your cronrat url"をcronジョブに追加します。私が好きな最高の機能は、最初のアカウントを作成した後に何かを設定する必要がないことです。各アラートは、使用する分に稼働します。したがって、最初にジョブを設定する必要がある一部のサービスとは異なり、自動ツールを使用して、まだ存在しないジョブを開始できます。

これらの正確なニーズに応えて、Power Cronを作成しました。cronジョブを一元管理するビューと、異なるクラスターメンバーのジョブ間の依存関係の概念が必要でした。

また、ログで見つけることができる情報よりも多くの情報が必要であり、ジョブプロファイリングを追加しました。

このために、PushMon、http： //www.pushmon.comを構築しました。毎日の仕事が午前3時に実行され、通常は午前4時に終了するとします。「毎日午前4時まで」のPushMonスケジュールを設定できます。または、「1時間以内に毎日午前4:00までに」などのもう少し進んだスケジュール。必要なことは、ジョブを実行するたびにPushMon URLを「ping」することです。これにより、pingが欠落していることが警告されます。処理できない例外をキャッチしたときなど、エラーが発生したことが確実にわかっている場合は、オンデマンドアラート機能を使用できます。

Healthchecks（https://github.com/healthchecks/healthchecks/）は、cronジョブの監視用に構築されたサービスとダッシュボードです。本番環境で使用され、維持され、コードの貢献を受け入れます。

Cronitor、Dead Man's Snitch、および友人と同様に機能します。終了する直前に、cronジョブを設定して、特別な一意のURLにHTTP / HTTPSリクエストを送信します。ヘルスチェックはこれらのpingを受信して​​ログに記録します。pingが予想される間隔で到着するかどうかを常にチェックします。問題を検出すると、通知を送信します。サポートされている通知方法は、電子メール、webhook、Slack、Telegram、Discord、SMS、Pushover、Pusbullet、PagerDuty、PagerTree、HipChat、VictorOps、OpsGenieです。

これをすべて設定して自分でホストできますが、他のWebサービスと同様に、ドメイン名、証明書の設定、HTTPリバースプロキシの設定、データベースバックアップの設定などに手間がかかります。実行するには、このHerokuに対応したバージョンhttps://github.com/iphoting/healthchecksを使用します。このプロジェクトを自分で実行し、それを使用して何百ものサービスを監視する人々を知っています。

免責事項：私は著者です。また、https： //healthchecks.ioでホストされたサービスとしてHealthchecksを実行しています