git - 关于失败的 GitHub WebHooks 的通知？

Question

我的公司使用 GitHub Enterprise 在某些 protected 分支更新时自动更新生产和测试服务器。

当有人发送推送事件时，有效载荷会传送到各种服务器，每个服务器都运行一个小型网络服务器来接收此类有效载荷。然后，Web 服务器检查有效负载的“ref”元素，以查看更新的分支是否与服务器相对应。

例如，当有人向 development 分支发送 push 事件时，这是 WebHook 传递给两个服务器 prod01 和 dev01 的负载的开始。

{
  "ref": "refs/heads/development",
  "before": "e9f64fa5a4bec5f68faf9533050097badf1c4c1f",
  "after": "e86956f39a26e85b850b81643332def33e7f15c6",
  "created": false,
  "deleted": false,
...
}

prod01 服务器检查 production 分支是否已更新。事实并非如此，所以该服务器上什么也没有发生。服务器 dev01 检查相同的负载以查看 development 分支是否已更新。它是 ("ref": "refs/heads/development")，因此 dev01 运行以下命令。

git -C /path/to/dev01/repo reset --hard
git -C /path/to/dev01/repo clean -f
git -C /path/to/dev01/repo pull origin development

正确交付负载后，GitHub Enterprise 会返回它。

但有时网络服务器没有在 prd01 或 dev01 上运行，所以我们得到这个。

发生这种情况时，我们更新存储库并期望服务器具有相同更改的工作流程将不起作用。

如何收到负载失败的通知？如果可能的话，我宁愿不设置一些东西来轮询 Web 服务器或轮询不良状态。除此之外，任何检查负载状态(RESTfully？)的解决方案都比检查 Web 服务器是否仍在运行要好，因为负载可能仍会因其他原因而失败。

编辑:我已经进行了内部检查，看起来我们可以设置我们当前的监控服务之一来检查每台服务器上网络服务器端口的响应。在上图中，它是 8090，但它经常不同。

这不是我理想的解决方案，因为它只真正涵盖了网络服务器没有响应的情况。有效负载传送可能失败的其他原因有很多。

Answer 1

有两种选择:

实时监控

配置log forwarding并监视 hookshot_resque 中错误代码为 422 或 504 的失败事件。

基于 Cron 的监控

有些用户有 administrative shell access您的实例可以使用命令行实用程序检查失败事件 ghe-webhook-logs .例如:

显示过去一天所有失败的 hook 投递

ghe-webhook-logs -f -a YYYYMMDD

下一步是解析和自动化命令。虽然这会延迟检测失败的 webhook，但它是可用的最稳健和可靠的方法。