部署Web应用程序的系统的健康检查的范围应该是什么？

今天，我有一项任务是为长期运行的服务“编写运行状况检查”，该服务是用于部署Web应用程序的业务流程系统。

我试图确定这种健康检查的范围，并提出了与健康检查范围有关的以下问题：

1. 如果业务流程系统报告任务正在运行，则认为服务正常是否足够好？
2. 还是我们应该手动ping每个服务？
3. 还是应该走得更远，并尝试确保网络应用按照显示网页的目的进行操作？
4. 运行状况检查是否还必须检查某些依赖服务是否也在运行？就像数据库或业务流程系统本身一样。还是其他健康检查的责任？
5. 最后，如果其中一项从属服务失效，并且Web应用程序随后发生故障，那么Web应用程序应该报告不良运行状况还是良好运行状况，因为这不是Web应用程序的故障？

我知道这是5个独立的问题，但是它们都与部署Web应用程序的长期运行服务的运行状况检查范围有关，因此我认为将它们分组在一个问题中会更有意义。

这对我来说很难实现，因为我不确定什么是健康的定义或类似标准的健康检查应该是什么样。

此特定服务的健康检查应包含哪些内容？

由于对健康的定义，这很难实施

您在这里回答了自己的问题。健康检查的定义将有所不同，因为健康的内容有所不同。它还取决于发出健康检查的内容。

一个好问题要问自己：“从问询者的角度来看，受检查的服务是否按预期工作？” 如果是您，则可以对其进行定义。如果是其他团队/服务，则需要确定健康检查的标准/规格。

可能在大型组织中，您将对健康检查应执行的操作制定某种标准。弄清楚。

特别是在这里，您的webapp示例意味着它不应恢复正常，因为该webapp不正常。但也许您对“健康”的定义会将其包括为“好”。这是上述需求讨论的一部分（同样，即使只是您自己的代码）。

我的建议是假设没有在其他地方指定，则应该具有与不同故障相关的某种状态代码。当您查询Web应用程序时，它可能会返回一个错误，指出“相关服务已死”，因此您的客户端（或执行运行状况检查的任何操作）可以知道客户端已死的原因。

对于已编辑的问题：

如果业务流程系统报告任务正在运行，则认为服务正常是否足够好？

不，仅仅是因为一个进程正在运行并不意味着它没有被挂起，完全无法运行或存在其他多种可能性。

还是我们应该手动ping每个服务？

这可能有效，具体取决于应用程序功能的范围。如果验证服务响应“您还活着吗？” ping，那么这可能就是所需要的。但是，如果该服务可以轻松地“活跃且响应迅速，但实际上却无法正常工作”，那么也许您还需要检查其他事项。

还是应该走得更远，并尝试确保网络应用按照显示网页的目的进行操作？

您的健康检查需要确保所需的预期功能可以按预期运行。

如果您的应用程序返回“正常”，并且不能做它需要做的，你可能也摆脱了整个健康检查的，因为它会产生假阳性（更不用说混淆赫克出来的人试图调试问题- “嘿我们的网络服务器显示正常，为什么我们看不到该页面？'）。

运行状况检查是否还必须检查某些依赖服务是否也在运行？就像数据库或业务流程系统本身一样。还是其他健康检查的责任？

这在某种程度上取决于。如果您的服务依赖于另一项服务，则该交互的性质应反映在应用程序中发送给它的API /网络调用中，并整合到运行状况检查中。

例如，从数据库读取的Web服务器需要具有有关内置数据库的状态信息-否则，如果API调用失败，则Web应用程序将完全崩溃。您可以简单地修改这些调用以将其合并到您的健康检查中。

但是，如果您的服务将事件发送给未经监听而直接监听的使用者，那么使用者的应用对应用程序的功能就不那么重要了。您的应用“正常”正在发送消息，但实际上并未接收到消息。

基本上，如果您的服务需要与其他服务进行对话并验证它们的运行状况，则至少应对此服务的运行状况检查进行基本检查。考虑到我刚才所说的内容，从概念上讲这应该是有意义的，因为您的应用程序已经在处理此问题（或者我认为是随机崩溃）。

最后，如果其中一项从属服务失效，并且Web应用程序随后发生故障，那么Web应用程序应该报告不良运行状况还是良好运行状况，因为这不是Web应用程序的故障？

上面已经基本回答了。我的建议是让您的健康检查返回提供此信息的代码/消息/任何内容。这两条信息都很重要：确保您的服务所需的依赖服务已失效，并且因此服务将无法正常工作。

通常，健康检查仅表示“它还活着并且正在响应”。除此之外，进一步的检查是高度专业的，并且完全取决于系统的使用。您是否愿意花更多的精力检查系统是否正确处理了请求，但这取决于您，但是您应该首先进行基础操作-检查它是否存在，检查它是否可以接收请求并返回响应。

实施运行状况检查的最简单方法是简单地编写一条命令，该服务将使用其他命令所使用的相同机制来处理服务，该命令除了返回确认外什么也不做。这将显示活跃性，并且系统正在接收和处理响应。

检查从属系统不是运行状况检查的一部分，您需要使其简单且独立。依次向每个相关服务添加运行状况检查。这样，您可以获取正在运行的，运行良好的系统的列表，并轻松分辨出什么时候变坏了，哪个坏了！

以我的经验，关键服务通常具有以下功能：

心跳

如果服务定期运行，则只需在日志文件或类似文件中写一行，并附带时间戳，以指示服务主体在给定时间启动。

面包屑

与上面类似，面包屑通常只是方法名称（有时是参数）的转储，以表明服务正在按预期方式处理服务主体及其流向。由于它们可以生成更多输出，因此通常由配置文件或类似文件控制，因此一旦服务嵌入，就可以将其关闭。

添加许多其他内容（例如各种服务器，服务和数据库的状态等）可能很诱人。尽管这无疑是有价值的，但我建议不要写太多内容。这些措施可能会使您自己省心，但是一旦负责各种接触点的当事方知道它们存在，这些保护措施就会被滥用。在不知不觉中，您可能正在为整个公司编写诊断应用程序。