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

时间:2014-08-19 17:14:01

标签: http web-applications monitoring

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

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

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

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

谢谢!

4 个答案:

答案 0 :(得分:17)

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

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

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

我同意@Julien认为500(特别)似乎不合适,我们决定 503服务不可用

503似乎有几个原因:

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

答案 1 :(得分:13)

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

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

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

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

答案 2 :(得分:1)

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

这不是很具体,你耸耸肩说:

  

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

ietf rfc7231

答案 3 :(得分:0)

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

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

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