私の職場では、cron を多用して、バックアップからレポート生成まで、多くのシステム管理タスクを自動化しています。問題は、50 以上の cron ジョブからなるシステムの複雑さが、自重で崩壊し始めていることです。セットアップについて少し説明しましょう。
- ~15 人の開発者 (個人の crontab を介して実行される cron ジョブを担当する人もいます)
- 30 台以上のマシン。そのうちのいくつかは cron ジョブを実行しており、時には複数の人によって実行されています。
- 多くの cron ジョブがログに記録されておらず、それらの stdout と stderr がすべて /dev/null にパイプされています (残念なことに)
- 一部の cron ジョブはノイズが多すぎて、過剰な量のテキストを吐き出し、cron からの電子メールをふるいにかけるのが面倒になります。
- ほとんどの cron ジョブは、監視されている場合でも、グループの電子メール エイリアスに送信されるため、多くの人が自分に関係のないメッセージを見て、それらを無視するように条件付けられます。
- 多くの場合、cron ジョブは失敗し、時間内に気付かない
- 一部の cron ジョブは、バックアップ システムによって追跡されていますが、追跡されていないジョブもあります。ソース管理なし。
- サーバーの 1 つがダウンすると、そのマシン上のユーザーの crontab ファイルに保存されている cron ジョブが実行されないことを意味し、cron ジョブが実行に失敗したことを認識していません。
理想的には、次のようなセットアップまたはソフトウェア システムが必要です。
- 開発者は誰でも簡単に cron ジョブを調整/修正でき、個人の crontab に限定する必要はありません。
- crontab が何らかの形で特定のマシンに集中している場合でも、cron ジョブを実行するマシンについて柔軟性を持たせる
- 成功した cron ジョブの実行はすべて簡潔にログに記録されるため、何かが発生したことがわかります。
- すべてのエラーはトラップされ、エラー メッセージと cron ジョブに基づいて、関連する開発者の詳細なリストに報告されます
- ユーザーは、成功または失敗に関係なく、特定の cron ジョブを監視するように設定できます
- ユーザーは、特定の時間枠内で失敗したジョブと成功したジョブの詳細を示す概要 (電子メールまたは Web ページ) を受け取ることができます。
- 分析用
のRRDtoolなどを使用した cron ジョブ統計 (実行時間、終了ステータス、出力ボリューム) のログ記録
- 堅牢性: 1 つのサーバーがダウンしても、cron ジョブ システム全体が破壊されることはありません。
オンラインで検索すると、「cron ジョブのベスト プラクティス」に関する議論がいくつか見られますが、それは私たちの要件の一部にしか対応していないようです。これらの機能の一部に対するソフトウェア サポートに関しては、cronic、shush、および cronwrap などのツールがあるようです (申し訳ありませんが、私は新しいユーザーであり、2 つのハイパーリンクに制限されています)。私が見逃しているものはもっとあると確信しています。
このようなコードを作成できたようですが、確かにこのようなものはすでに作成されているに違いありません。既存のシステム/方法論に関するアドバイス、またはそのようなシステムを構築する方法に関する指針は、非常に高く評価されます。