我应该使用哪个HTTP状态代码进行运行状况检查失败？

Question

我正在实现一个/_status/端点，它会对我们数据库中的数据进行一些健全性检查。

例如，我们正在收集测量结果，如果最新测量结果超过一小时，状态将变为“糟糕”。

我想在这个网址上指出Pingdom利用他们的警报基础设施并告诉我们什么时候出错了。

在“良好”状态下，我将提供具有HTTP 200 OK状态的HTML页面。但是，对于“坏”，适当的HTTP状态代码是什么？或者更正确的是不通过状态代码传递这些信息，而是通过HTML内容来传达？

谢谢！

Answer 1

嗯......这是一个老问题，但我最终到了这里，所以我想我会在这里给我两分钱： 很明显，如果一切正常，应该返回2xx

如果健康状况不好，我认为它应该返回5xx结果（4xx说明客户端在请求中有错; 2xx和3xx在某种程度上都是成功的。）

我认为5xx是正确的，因为这是一个回应整个服务状态的特殊请求。此外，因为大多数负载均衡器提供基于响应代码的活跃度检查，并不是所有都提供了解析更复杂的有效负载的方法（除了可能使检查变得脆弱的RegExp匹配）。

我同意@Julien认为500（特别）似乎不合适，我们决定 503服务不可用。

503似乎有几个原因：

• 这是一个5xx系列结果代码，表示服务器端正在进行某些操作。
• 它具有暂时性质，表明它可能会恢复。

Answer 2

我们刚刚在我们小组进行了类似的讨论。为了我们的目的，我们决定HTTP响应代码应该报告服务器成功或失败以满足请求。对于GET，这将意味着您是否可以使用所请求的资源进行响应。在这种情况下，请求的资源是健康报告，因此只要您成功返回，它就应该是200响应。

我们正在为健康检查返回JSON，顶级“isHealthy”字段设置为true或false。我们的负载均衡器和其他监视器将解析JSON并使用此字段来确定系统是否健康。

如果您不想在监视器中解析JSON，可以尝试使用自定义响应标头来指示系统的二进制运行状况，例如System-Health: true或System-Health: false。你可能有更好的运气获得可以检查的显示器。

如果您真的想要使用响应代码，我建议使用名为“health”的附加端点，在健康时返回“204 No Content”，并且“404 Not Found”什么时候不健康在这种情况下，URL定义的资源象征性地是系统的运行状况，因此如果它是健康的，您可以返回成功的响应。如果它不健康，那么它的健康就无法找到，因此404。

Answer 3

如果您的数据“糟糕”，因为服务失败（即使这是后端作业失败），那么HTTP 500似乎是一个有效的响应。它表明某些事情在某个地方被打破了。

这不是很具体，你耸耸肩说：

  

500（内部服务器错误）状态代码表示服务器      遇到意外情况，无法实现      请求。

ietf rfc7231

Answer 4

如果您要求健康并且服务器状态不健康，那么我会偏爱409冲突，“它表示由于资源的当前状态冲突而无法处理该请求”。

有些人可能会反对，如果您可以答复，那么可以处理该请求，但我不同意。每个错误消息都是响应。服务器定义资源语义。如果您要求提供好消息资源，并且服务器响应“这是坏消息”，则它没有给您提供该资源所定义的内容。

在实践中，说2 ** =“上” 4 ** =“下”更加容易，并且管道请求计入可用性指标，并使负载均衡器根据响应代码将服务器从其池中删除。想出办法说“嘿，我们告诉了你一件事，所以200行”对我来说似乎就像是在为树木抢走阿甘。