当前我们收到了一堆错误报告，例如：
9/4/17 7:53AM: buildID: B32739cd61, name: windows-amd64-2016, hostType: host-windows-amd64-2016, error: failed to get a buildlet: Error creating instance: &{Code:QUOTA_EXCEEDED Location: Message:Quota 'CPUS' exceeded. Limit: 500.0 ForceSendFields:[] NullFields:[]}
8/4/17 7:53AM: buildID: B059b7649c, name: openbsd-amd64-60, hostType: host-openbsd-amd64-60, error: failed to get a buildlet: Failed to create instance: googleapi: Error 403: Quota 'CPUS' exceeded. Limit: 500.0, quotaExceeded
at main.(*buildStatus).reportErr (coordinator.go:1951)
...等等
这可能不是一个紧急的问题，因为协调器的重试逻辑至少足以确保构建最终能够运行。
编辑：
我们需要找出哪些错误是噪音，并对其余的进行警报。
9条答案
按热度按时间xyhw6mcr1#
尽管我们或许应该考虑为更多CPU付费。
xdnvmnnf2#
是的，这不是一个可警报的问题。
这是在负载高峰期间的正常现象，不会影响用户或构建。
协调器试图进行自己的节流和配额的死记硬背，但似乎从GCP报告的配额存在一些延迟，导致我们的内部使用核算和使用信号量出现问题。
尽管如此，我们可能应该考虑购买更多的CPU。
这只是一个简单的票据来增加配额，但它实际上并不能解决问题。在几次提交中，我们几乎总是有比CPU更多的工作要做，无论我们的CPU限制是多少。有时候偶尔超过限制几分钟是可以接受的。
更好的做法是完成调度器： #19178
l2osamch3#
听起来不错。
o0lyfsai4#
我认为你应该保持这个bug打开，以修复你的日志记录/警报。
你不应该得到误报。
3df52oht5#
啊，没有生成警报。只是记录了错误。
实际上，我根本没有设置任何警报。仍在努力了解什么是正常的，什么是不正常的。
好的，我会修改这个bug来直接解决这个问题(决定要警报的内容并设置警报),然后重新打开。听起来怎么样？
我们应该对#反向构建器警报内容做类似的事情。因为现在它只是噪音。
我可以今天处理那个。cc @shantuo
yqhsw0fo6#
https://golang.org/cl/53353提到了这个问题：
cmd/buildlet: normalize macstadium host names for monitoringpiah890a7#
https://golang.org/cl/96416提到了这个问题：
devapp: start of status handler for monitoringguz6ccqo8#
https://golang.org/cl/97516提到了这个问题：
devapp: revert status changese1xvtsh39#
https://golang.org/cl/210740提到了这个问题：
status: delete unused, incomplete status client & server