spring health_为什么Spring的Health会再次向下，向下，向上，向上，向上和向下？...

spring health

为什么

我们新JavaScript客户端应用程序会定期调用Grails后端的/health端点，以确定离线状态。事情开始变得“有趣”。

我们免费获得该端点，因为Grails基于Spring Boot，而Spring Boot带有一个名为Spring Boot Actuator的子项目。

这给了我们许多端点，使我们可以监视我们的应用程序并与之交互，包括/health返回健康信息。

因此，我们的JS客户端会检查它是否可以到达此/health端点（每隔几秒钟执行一次），以确定用户是在线还是离线。没什么好想的，以后我们可能会切换到仅使用Google主页之类的东西，但是现在可以了。

健康检查失败

在localhost一切似乎总是很好，但是一旦我有了Jenkins管道，最终在每次构建后将应用程序部署到我们的测试服务器上，然后我们开始在那里验证应用程序，一切就变得很有趣。

通常情况下，我们的通话情况非常好。

GET https://tst.example.com/health 200 ()
GET https://tst.example.com/health 200 ()
GET https://tst.example.com/health 200 ()
etc

每隔几秒钟，我们就会在Chrome检查器中看到错误累积的情况。运行状况检查将失败，并且HTTP状态代码503 Service unavailable长时间503 Service unavailable 。

GET https://tst.example.com/health 503 ()
GET https://tst.example.com/health 503 ()
GET https://tst.example.com/health 503 ()
etc

过了一会儿，我们会再次接到好电话！

GET https://tst.example.com/health 200 ()
GET https://tst.example.com/health 200 ()
etc

这些失败请求的响应只是说

{"status":"DOWN"}

从设计上来说，这不是很描述。

我当然没有写任何healh指标自己会这样，为什么会“下降”？

经验丰富的Spring Booters知道它将在类路径上获取任何运行状况指示器，并且默认情况下带有一些。实际使用的是一个谜，因为默认情况下，Spring Boot将该端点归类为“敏感”，因此不会向外界暴露太多信息。

我必须通过设置以下设置来使运行状况检查更加“简陋”：

endpoints.health.sensitive: false

现在，手动调用端点即可显示竞争者！

{"status":"DOWN","diskSpace":{"status":"DOWN","total":8579448832,"free":20480,"threshold":10485760},"db":{"status":"UP","database":"H2","hello":1}
}

“关闭”的一般状态是现在明确列出的（在本例中为2）自动配置的运行状况指示器的汇总结果。

当我看到以下内容时，立即想到的是：

我为什么还没有去除H2
嘿，测试服务器上的磁盘空间已经用完了吗？

H2数据库是所有Grails应用程序中的默认依赖项，但是我们的应用程序不使用它-不在生产环境中也不用于测试-因此，我们一定要从依赖项中删除它。不用担心。

关于磁盘空间，这是很好的DiskSpaceHealthIndicator （实际上是自动配置的指示器的一部分），告诉我事情不健康 。

它的默认阈值为10485760字节或10 MB ，这是应该可用的最小磁盘空间。

而且……只有20 kb的可用空间？ 总共8场演出。

这是一个相当低的数字

在最初的0.7秒内，我不相信健康指标，您能想象吗？

因此，我通过SSH进入测试服务器，以使用df实用程序检查可用磁盘空间：

[Ted@server-01t ~]$ df -h
Filesystem             Size  Used Avail Use% Mounted on
/dev/mapper/rhel-root  8.0G  8.0G   20K 100% /
...

是的，至少健康检查证明了事实的真相：实际上只剩下一小块空间。

我将其转给配置此机器的IT同事进行调查。 似乎早先的实验中已经有一些Java堆转储占用了空间-有人告诉我将尽快删除它。

最好也检查其他节点。

[Ted@server-02t ~]$ df -h
Filesystem             Size  Used Avail Use% Mounted on
/dev/mapper/rhel-root  8.0G  5.3G  2.8G  66% /

那儿有足够的空间。

等一下？ “其他节点？” 是的，我们有2个测试服务器01t和02t 。

那时，我意识到：我看到的行为是由于负载均衡器将请求转发到tst.example.com到server-01t或另一个server-02t 。其中之一是磁盘空间不足，这说明该服务器上Grails应用程序的运行状况指示器显示“关闭”，从而导致HTTP 503。

当通过Chrome Inspector观察这些运行状况调用（这些请求由我们的JS客户端不断发出）时，只剩下一个小问题：为什么我们会有（有时50倍）“涨”（ 200 ），然后一连串的“跌” ”（ 503 ），然后按照看似随机的顺序？

负载平衡器应使我们“固定”在JS客户端首次发出请求的那个节点上，因为我们这样配置服务器。

如果负载均衡器将每个请求 （发送给tst.example.com ）轮流发送给服务器1或2，我期望会有更多（随机）响应，例如“ up” ， “ down” ， “ down” ， “ up” ，“ “向下” ， “向上” ， “向上” ， “向下” ， “向上” 。

好吧，在我观察此行为的窗口期间，似乎团队的其余成员仍在开发功能，并…推向Jenkins挑选的Git，并将其部署到两台服务器上。由于将应用程序串行重新部署到ech服务器，因此负载平衡器“看到”该应用程序在一台服务器上的不可用（具有足够的磁盘空间： “ up” ， “ up” ， “ up” ， “ up” ， “ up” ” ）在部署期间将流量重定向到另一台服务器 （几乎没有磁盘空间： “关闭” ， “关闭” ， “关闭” ））…

…不久之后就用新的WAR更新，并再次在另一台服务器上结束请求（具有足够的磁盘空间： “ up” ， “ up” ， “ up” ， “ up” ， “ up” ）。

再花3个小时浪费我的生命。包括一些时间在这里记下这些东西（但我认为这是值得的）