我有一堆“夜班脚本”来维护服务器。问题是，这些脚本可能运行的“操作窗口”总是不同的。有时几分钟或几小时内什么都没有发生，有时服务器整晚都在处理一些数据。这些脚本不仅仅是（但主要是）数据库脚本。
有位开发人员想到了一个实现守护进程的想法。这个守护进程应该检查服务器状况，如果发现有足够的空闲资源，就会启动一些脚本。
我觉得这个想法很有趣（更不用说很有诱惑力 ;-) ），但不会真正重新发明轮子。有没有经过验证的模式？也许是一些 Shinken 或 Nagios 插件？
答案1
在 nagios 世界中，你可以使用以下方法链接任务事件处理器在服务上。
事件处理程序实际上是第二个命令在第一个服务命令之后执行，总是，（如果在全局配置中激活并针对该服务激活）。事件处理程序的基本用法包括使用服务状态和命令结果启动它。然后，事件处理程序脚本分析服务状态（我们是 OK/WARNING/CRITICAL 吗？这是第一次检查向我们发送此状态吗？硬状态还是软状态等）并决定最终启动命令。文档中的上一个链接显示了一个基本的 bash 脚本执行此操作（请注意，即使在成功结果之后，事件处理程序也始终运行）。
因此，您可以在负载平均服务上添加事件处理程序，并且当服务状态正常时，此事件处理程序可以启动消耗 CPU 的维护任务。或者，它可以简单地在文件系统的某个地方设置一个标志，然后您的 cron 任务将在运行前检查该标志。
现在，您可能需要合并多个服务结果，然后才能决定系统是否真的准备好启动任务，原因如下：
- 检查平均负载和内存状态
- 检查数据库是否准备就绪并处于良好状态
- 检查其他两个任务是否完成，但时间到了，你确实需要完成任务，否则你会迟到
一些检查检查集群可以帮助您合并多个服务结果，如果 5 上的 3 个服务处于 OK 状态（例如），则获得处于 OK 状态的服务。然后，您可以使用 check_cluster 在服务上设置事件处理程序。
管理“我来晚了”状态更难。最好的地方是事件处理程序代码（如果迟到，请忽略关键或警告状态）。
你也可以时间段约束（例如：维护任务应仅在周五晚上运行）。您有几种方法。在我看来，最好的方法是仅使用事件处理程序设置标志，并使用维护任务调度程序设置时间段（定时任务). Nagios 提供时间段可以附加到您的服务上，但即使是最新版本的 Nagios 也存在一些严重的错误，服务没有被安排在 7/7 24/24 运行，这些错误将下一个服务的执行推到了时间段之外，然后将其推迟了 1 周（为什么是 1 周？），然后永远不会再次启动该服务。Cron 或任何外部调度程序将使维护调度程序更好、更强大（我还没有测试过 Shinken 调度程序，也许它真的支持官方高级时间段）