我有一个像 2MB 二进制文件这样的轻量级服务，它在用户单元上运行，但我运行了 120 个类似的服务，但每个服务上使用的配置略有不同。
我想监控所有这些服务，如果它们中的任何一个出现故障，都会通过 API 端点发出警报。
到目前为止，我已经编写了一个 bash 脚本，该脚本迭代列表（一行一个服务名称）并且我正在使用
systemctl status name.service
以及服务的状态和服务名称grep。awk最后，我if在这个while循环中有一个条件，如果其中一个服务未处于活动状态（正在运行），则会将帖子卷曲到 API 端点。
我计划每分钟执行一次这个脚本。不过我不太担心，并有以下问题：
- 每分钟的 cron 是否太过分了？
- 在这样的脚本/crontab 中我应该注意什么？
- 有更好的方法吗？对我来说，这似乎有点业余，但这是一种快速开展工作的方法。
我只是担心 crontab 会出问题，直到为时已晚我才知道，或者其他东西可能会损坏，或者更糟糕的是系统可能会崩溃。
如果我在这里有更好的前进道路，有什么想法吗？
答案1
这应该是一条评论，但有点长。
鉴于有很多很多免费软件包可以进行监控，这似乎是解决问题的一种奇怪的方法。
存在规模问题（规模问题总是存在，但如果有更合适的平台，这些问题将减少几个数量级）。例如，如果每个实例需要超过一秒的时间来响应，会发生什么情况。存在功能问题 - 如何定义监视窗口，如何通知问题，您想要监视但不通知的窗口怎么样。您如何管理历史来衡量干预措施的有效性？......
最终您将在监控平台上运行它。越早开始，未来的痛苦就越少。
答案2
您不需要脚本，也不需要轮询； systemd 已经知道当一个单元发生故障时如何启动某些东西。阅读该OnFailure=指令。您可以简单地定义一个一次性服务，例如，使用curl 来调用具有故障单元名称的REST 端点。
答案3
有很多方法可以做到这一点，您可以选择使用现有的监控解决方案或构建更基本的解决方案。要确定时间和精力的投资是否值得，请进行一些市场研究并弄清楚该解决方案是否可以推广到其他需求。
就个人而言，出于演示目的，我可能会选择 Prometheus + Grafana + Alert 管理器，但这只是因为我有先前的经验并且我已经在使用这些工具。
简而言之，这个想法是公开一个 API 端点在您的应用程序中在预定的端口上（所谓的 Prometheus出口商）。然后 Prometheus 实例将连接到端点（“目标”）并获取指标定期（默认通常为 15 秒）。
如果您使用 Go 或 Python，则在应用程序中嵌入导出器会很容易。所以这取决于您正在使用的技术堆栈。
也许您现在对指标不感兴趣，尽管它们稍后可能有用。但是您可以使用警报管理器来实现，以便当端点在一定时间或连接尝试后不再响应时收到警报。那么通常意味着设备无法访问，或者端点已崩溃。听起来像是你想要的东西。
一项好处是您将拥有历史也。因此，如果您知道问题何时发生（与日志关联），您可以更轻松地跟踪问题。
如果您的架构允许，使用单独的设备进行监控是有意义的。这里的想法是让外部代理探测您的服务（拉）。失败的服务并不总是能够发送通知（推送）并正常崩溃。
但了解您的服务在幕后实际做什么会很有趣。换句话说：定义失败意味着什么以及期望的结果应该是什么样子。仅仅因为服务响应 HTTP 查询并不一定意味着它按照预期工作。它可能依赖于某些功能，例如访问互联网、文件访问或其他功能。这就是指标有用的地方。
例如，Web 服务器的导出器将返回指标的累积和平均数据，例如传输的字节数或服务的页面数。如果某些数字降至零，您可能会怀疑某个地方出现了问题。毕竟，Web 服务器可能工作正常，但由于上游网络中断而无法访问，从而导致指标停滞。
拥有 API 端点很有趣，但如果它确实给出了一些有用的信息，而不仅仅是说“我起来了”，那就更有趣了。