关于失败的 GitHub WebHooks 的通知？

Question

当某些受保护的分支更新时，我的公司使用 GitHub Enterprise 自动更新生产和测试服务器。

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

例如，当有人将推送事件发送到 development 分支时，这是 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 会返回此内容。

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

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

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

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

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

Answer 1

有两种选择：

实时监控

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

基于 Cron 的监控

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

显示过去一天所有失败的挂钩交付

ghe-webhook-logs -f -a YYYYMMDD

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

Answer 2

如果我还没有一个小型 Jenkins 实例，我会怎么做。然后在调用 Jenkins 作业的相同事件上创建一个单独的 webhook，该作业基本上计数为任意数字 (1000)，然后检查目标服务器以查看有效负载是否已发送到服务器。这样一来，它就不必持续监控，并且会与您的 webhook 同时被触发。

当然，如果 Jenkins webhook 也出现故障，Jenkins 解决方案就会失败，因此您必须努力使该连接真正防弹。当然，这可能会适得其反，最好把时间花在其他地方。

很糟糕，GitHub API 中似乎没有任何方法可供企业查看请求的响应代码。 API 当然可以显示请求的有效负载，但这显然对您没有帮助。