在许多项目中，我的团队遇到了一些重要组件“沉默失败”的问题。 有很多任务在幕后执行，如果某些事情（在逻辑或硬件问题上出错）在大多数情况下，负责人不会被通知（或没有立即通知）。
我知道可以解决一些问题的重量级监控工具，但是对于我们的团队而言，这些工具太复杂了，太贵了。
我感兴趣什么是你的解决scheme这样的问题。
感谢您的回应。 为了更准确，我正在寻找符合以下标准的东西：
可靠性 – 我认为像cron的MAILTO这样的解决scheme，或者如果作业脚本返回一些值，执行通知脚本不是完全可靠的（例如服务器存在一般问题）。 完全可靠的解决scheme部署在分离的环境中。
有可能立即提醒有兴趣的人（在某些情况下，电子邮件不能被视为立即处理，短信会好很多）。 当你每分钟收到一封包含相同信息的电子邮件时，防止“电子邮件雪崩”会很好。
要求尽可能less地了解设置和configuration。
警报规则从一个地方维护。
我做了一些研究，找不到任何涵盖这些标准的内容。 Nagios（或类似的工具）差不多已经足够好了，但在我看来，它们是复杂的，而不是用户友好的，需要复杂的集成。 它也需要雇用熟悉这种工具的人或花费大量的时间来掌握这些工具。
我问这样的解决scheme的主要原因是，我们在我们的软件公司解决scheme的基础上开发了一个有趣的方法，可以充分满足这样的要求（或其中大部分），并且已经在我们的项目中工作得很好。 现在我们的目标是为社区发布它，我们正在寻找一些可以做几乎相同的解决scheme来分析我们的方法的优缺点，并select发展的方向。 关于您现有解决scheme的问题以及您真正感激的事情的评论也非常欢迎。
Nagios与被动检查，然后包装您的计划作业发送一个消息（send_nsca）到您的nagios服务器，指出完成后发生了什么。 如果作业错误，那么nagios会提醒。
与你遇到的问题更相关的是，你也可以设置nagios来提醒你是否从你的cron工作中听不到太久，这样你就可以发现失败的工作。
所有自由和相当微不足道的设置。
你可以改变crontab中的命令条目来做一些事情
/ usr / local / bin / critical_job || / usr / local / bin / notify“关键作业失败”
然后当“citical_job”以非零值退出时，将运行“notify”。 最好，我会尽我所能地抓住工作本身，并在那里处理。
如果您觉得大规模的监控解决scheme不适合您的情况，则可以考虑将pipe理员电子邮件从服务器转发给某个人的实际电子邮件帐户。 您可以通过在/ etc / aliases中添加如下所示的行来完成此操作：
root: [email protected] 其中[email protected]是某人的实际电子邮件地址。
请注意，您的服务器需要一个function正常的MTA来发送电子邮件，并且如果有任何阻止系统发送电子邮件的条件（即networking丢失/ / var上没有空格），则不会有人通知。
看看https://cronitor.io – 你可以免费监视一个cron作业。 当你的工作运行时，他们会ping Cronitor，如果Cronitor没有在适当的时候被发现，它会向你发出警报。