在许多项目中，我的团队都面临一些重要组件“无声故障”的问题。许多任务都是在幕后执行的，如果某些任务发生故障（无论是由于逻辑错误还是硬件问题），在大多数情况下，负责人都不会收到通知（或不会立即收到通知）。
我知道一些重量级的监控工具可以解决其中的一些问题，但是对于我们的团队来说它们过于复杂而且成本太高。
我感兴趣的是您对于此类问题的解决方案是什么。
感谢您迄今为止的回复。更准确地说，我正在寻找符合以下条件的东西：
可靠性 - 我认为，如果作业脚本返回某些值，则依赖 cron 的 MAILTO 等解决方案或执行通知脚本并不完全可靠（例如，服务器存在一般问题）。完全可靠的解决方案部署在独立的环境中。
可以立即向相关人员发出警报（在某些情况下，电子邮件不能被视为即时警报，短信会更好）。当您每分钟都收到包含相同信息的电子邮件时，这可以很好地防止“电子邮件雪崩”。
需要尽可能少的有关设置和配置的知识。
当脚本执行超过一定时间时进行监控和报警的能力
警报规则由一个地方维护。
我做了一些研究，没有找到任何符合这些标准的东西。Nagios（或类似工具）已经足够好了，但在我看来，它们太复杂了，不方便用户使用，需要复杂的集成。它还需要雇佣熟悉此类工具的人或花大量时间来掌握它们。
我询问此类解决方案的主要原因是，我们软件公司的解决方案基于有趣的方法，可以满足此类要求（或其中大部分），并且在我们的项目中已经运行良好。现在我们的目标是将其发布给社区，我们正在寻找一些可以做几乎相同事情的解决方案，以分析我们方法的优缺点并选择开发方向。欢迎就现有解决方案的问题和您真正欣赏的事物发表评论。
答案1
Nagios 进行被动检查，然后包装您的计划作业，以向您的 nagios 服务器发送一条消息 (send_nsca)，指示作业完成时发生的情况。如果作业出错，nagios 将发出警报。
与您看到的问题更相关的是，您还可以设置 nagios 来在它长时间没有收到您的 cron 作业的消息时发出警报，这样您就可以发现那些悄无声息地失败的作业。
所有设置均免费且相当简单。
答案2
您可以将 crontab 中的命令条目更改为类似
/usr/local/bin/critical_job || /usr/local/bin/notify “关键作业失败”
然后当“citical_job”以非零值退出时，“notify”将运行。最好我尽力在作业本身中捕获它并在那里处理它。
答案3
如果您认为更大规模的监控解决方案不适合您的情况，您可以考虑将管理员电子邮件从服务器转发到某人的实际电子邮件帐户。您可以通过将如下行添加到/etc/别名：
root: [email protected]
在哪里[电子邮件保护]是某人的真实电子邮件地址。
请注意，您的服务器需要一个正常运行的 MTA 来发送电子邮件，并且如果有任何情况阻止系统发送电子邮件（例如网络丢失/没有空间/var），则不会有人收到通知。
答案4
托管死人开关样式服务非常适合这里。简而言之：您设置 cron 作业，以便在 cron 作业完成之前向托管服务发出 HTTP 请求。只要服务没有及时收到 cron 作业的回复，它就会向您发送警报。
- 可靠性：托管服务运行在与您的 cron 作业不同的基础架构上。对于真正关键的任务，您可以 ping 多个服务。
- 短信通知是一种常见功能
- 最低限度的设置或维护，就像任何 SaaS 一样
- 通常，你可以配置 cron 任务在你收到警报之前允许“延迟”多久
- 托管服务将提供一个仪表板，其中包含您所有注册的 cron 作业、其时间表、当前状态、下次预计运行时间等。
一些众所周知的选项：
- Healthchecks.io。2015 年推出。免费监控 20 个职位。
- Cronitor.io。2015 年推出。免费监控 1 个作业。
- 死人的告密者。2013 年推出。免费监控 1 个作业。
（全面披露 – 我是 Healthchecks.io 的创始人。）