我们应该在看到来自各种服务的新的/许多的"坏"日志消息时收到警报。对于新、许多和坏的一些定义。也许坏可以意味着它包含"错误"。或者还有其他十几种情况。(从https://go-review.googlesource.com/c/build/+/179419/1/cmd/coordinator/gce.go#b193 分支)/cc @bcmills@dmitshur
voase2hg1#
作为临时的解决方法，我们可以将非关键服务(build.golang.org和dev.golang.org,而不是golang.org)以“仅在崩溃时”的方式进行配置，并确保我们能够注意到任何给定的服务是否处于关闭状态。
build.golang.org
dev.golang.org
golang.org
yrwegjxp2#
对于那些可能自行恢复的非关键性问题，我可以在 https://farmer.golang.org/#health 上添加项目(在适当的情况下，可以设置为警告级别),这些项目都可以很容易地与监控连接起来。我希望在依赖的非关键服务出现临时问题时，不要崩溃。我们有很多这样的服务。
wgx48brx3#
build.golang.org 和 dev.golang.org 不是非关键服务。如果它们出现故障，尝试机器人和构建器将无法运行，gopherbot 将无法为 CL 分配审阅者等。人们依赖这些事情正常工作，因此我认为以降低 Go 贡献者生产力为代价解决此问题并不是一个好主意。我们应该寻找一种不会破坏性的途径来查找日志中的“错误”条目。
3条答案
按热度按时间voase2hg1#
作为临时的解决方法，我们可以将非关键服务(
build.golang.org和dev.golang.org,而不是golang.org)以“仅在崩溃时”的方式进行配置，并确保我们能够注意到任何给定的服务是否处于关闭状态。yrwegjxp2#
对于那些可能自行恢复的非关键性问题，我可以在 https://farmer.golang.org/#health 上添加项目(在适当的情况下，可以设置为警告级别),这些项目都可以很容易地与监控连接起来。
我希望在依赖的非关键服务出现临时问题时，不要崩溃。我们有很多这样的服务。
wgx48brx3#
build.golang.org和dev.golang.org不是非关键服务。如果它们出现故障，尝试机器人和构建器将无法运行，gopherbot 将无法为 CL 分配审阅者等。人们依赖这些事情正常工作，因此我认为以降低 Go 贡献者生产力为代价解决此问题并不是一个好主意。我们应该寻找一种不会破坏性的途径来查找日志中的“错误”条目。