【问题标题】:Google App Engine updated health checksGoogle App Engine 更新了健康检查
【发布时间】:2018-03-09 13:03:31
【问题描述】:

我正在使用 Google App Engine 柔性环境 (Node.js)。是否有任何理由在指定的每个间隔秒内分别触发 6 次活动性和就绪性检查? (这些都在同一个时间戳)

A  GET 200 2 B 2 ms GoogleHC/1.0 /readiness_check GET 200 2 B 2 ms GoogleHC/1.0 
A  GET 200 2 B 2 ms GoogleHC/1.0 /readiness_check GET 200 2 B 2 ms GoogleHC/1.0 
A  GET 200 2 B 1 ms GoogleHC/1.0 /readiness_check GET 200 2 B 1 ms GoogleHC/1.0 
A  GET 200 2 B 1 ms GoogleHC/1.0 /readiness_check GET 200 2 B 1 ms GoogleHC/1.0 
A  GET 200 2 B 3 ms GoogleHC/1.0 /readiness_check GET 200 2 B 3 ms GoogleHC/1.0 
A  GET 200 2 B 1 ms GoogleHC/1.0 /readiness_check GET 200 2 B 1 ms GoogleHC/1.0 
A  GET 200 2 B 2 ms GoogleHC/1.0 /liveness_check GET 200 2 B 2 ms GoogleHC/1.0 
A  GET 200 2 B 2 ms GoogleHC/1.0 /liveness_check GET 200 2 B 2 ms GoogleHC/1.0 
A  GET 200 2 B 2 ms GoogleHC/1.0 /liveness_check GET 200 2 B 2 ms GoogleHC/1.0 
A  GET 200 2 B 2 ms GoogleHC/1.0 /liveness_check GET 200 2 B 2 ms GoogleHC/1.0 
A  GET 200 2 B 1 ms GoogleHC/1.0 /liveness_check GET 200 2 B 1 ms GoogleHC/1.0 
A  GET 200 2 B 1 ms GoogleHC/1.0 /liveness_check GET 200 2 B 1 ms GoogleHC/1.0 

准备检查无限期地继续进行是否正常?我原以为在一个实例被认为“准备好”之后,准备情况检查会停止。只是似乎没有必要让准备就绪和活跃度检查都连续命中我的实例,而活跃度检查似乎就足够了。如果有人知道一种更好的配置方法以使其不那么多余,我将不胜感激。我的 app.yaml 的相关部分如下所示:

runtime: nodejs
env: flex
readiness_check:
  path: '/readiness_check'
  check_interval_sec: 20
  timeout_sec: 4
  failure_threshold: 2
  success_threshold: 2
  app_start_timeout_sec: 300
liveness_check:
  path: '/liveness_check'
  check_interval_sec: 30
  timeout_sec: 4
  failure_threshold: 3
  success_threshold: 2
  initial_delay_sec: 300

谢谢!

【问题讨论】:

  • 一些与经典健康检查相关的问题,如果更新的健康检查不受影响,请不要这样做:请参阅stackoverflow.com/questions/42841697/…
  • 感谢您的回复。我已经看到了那个答案,并且肯定认为它是相关的,但希望更新有一些改进。我想我最终想知道我是否可能错误地使用了检查组合。再次感谢!

标签: google-app-engine


【解决方案1】:

准备就绪检查的目的是为了让您可以根据自己的意愿将虚拟机从流量轮换中移除(例如,您想要重新加载一些缓存等)。活力也是如此。它还允许负载均衡器检测问题并移除不循环的虚拟机(例如,如果您的应用崩溃并正在重新启动)或修复它(例如,如果虚拟机完全死机)。

关于请求数量 - 这取决于您部署的实例数量(您是否正在运行 2 个实例?)并且每个实例处理 3 个并行请求(来自 3 个不同的运行状况检查器),因此我们确保结果。

总体而言,除非您过于激进并实施过于昂贵的自定义运行状况检查处理程序,否则这应该是您 VM 的最小流量。

希望对你有帮助, 安德烈

【讨论】:

  • 嗨,安德烈,非常感谢您的回复。所以基本上,活动性检查旨在确定是否应重新启动 VM,而就绪性检查旨在决定是否将 VM 从轮换中完全移除?我只运行了 1 个实例,每个实例仍然收到 6 个并行请求,但我确实将其保留为自动扩展,并将实例的最小和最大数量都设置为 1(我可以看到在这种情况下会导致问题)。我可以测试多个实例并记录实例 ID 以检查多个实例的频率。
  • 我最终并不担心每张支票的额外请求。主要问题围绕着这样一个事实,即使用就绪检查的默认设置(5 秒间隔)和 1 个实例上的 6 个并行请求,我的大多数请求都收到 502 错误。当我将检查间隔秒增加到 20 时,502 错误消失了。这是使用 1 个实例。当我增加实例计数时,我不得不再次将就绪检查间隔增加到 45 秒,将活动检查间隔增加到 65 秒,但是我仍然偶尔会收到来自 nginx 的随机 502 错误。
  • 是否存在其他可能导致该级别 502 错误的因素?即使请求开始全部返回 502 并且日志中没有真正指示可能导致它们的原因,运行状况检查仍继续收到 200 个 OK。 502 响应的数量似乎与 nginx 处理健康检查的频率直接相关
  • 我们最近确实在防火墙规则中发现了一个错误,我认为这最终是您观察到的行为的原因。它应该与您设置的时间无关。你现在可以再试一次吗? (使用默认值应该就可以了)。谢谢!
猜你喜欢
  • 2019-02-28
  • 1970-01-01
  • 1970-01-01
  • 2017-08-10
  • 1970-01-01
  • 1970-01-01
  • 2014-10-02
  • 2021-09-13
  • 2019-11-03
相关资源
最近更新 更多