文档结构  
翻译进度:已翻译     翻译赏金:0 元 (?)    ¥ 我要打赏

和大多数软件一样,Github 也会有很多异常。这些异常从系统级别问题包括 Git 超时、引用丢失到应用级别的问题,例如代码错误和 JavaScript 错误等等。

我们认真的对待系统的稳定性和性能的问题,因此我们需要快速识别问题的方法,以便团队或者个人能快速找到并解决这个问题。而 Haystack 就是这样的工具。

Haystack dashboard

Haystack 是我们内部的异常跟踪系统,该长篇经过 6 年的开发和完善,用来监控几乎我们构建的所有应用,包括桌面应用。

第 1 段(可获 2 积分)

一个典型的变更部署的场景。

cagedCaged

/deploy github/my-feature

hubotHubot

先关起来,一定要注意 Haystack 中的 graphme 监控的异常和性能问题。

一旦工程师通过 chatops 发布时,Hubot 会将之与消防栓链接起来,消防栓是一个视图可以显示变更发布后相关的异常,并提醒工程师关注异常信息。与此同时 Haystack 继续监控所有应用的运行状态 —— 检查是否当前异常发生的比例是否和之前正常状态下的异常比例是否有波动。我们希望工程师持续关注“消防栓”系统,要求别人关注 Haystack 就好像要求他们通过转播画面观看草坪一样。这也就是为什么我们需要一些异常的检测。

第 2 段(可获 2 积分)

我们有几个简单的规则来检测异常,这些规则已经可以满足绝大多数需求,用于防御失败的部署或者是典型的错误。当发生的异常数超过预设的最小阈值,那么就算是美好的日子也要让大家不得安宁。接着我们获取最近一个小时的异常数来确认最后时刻超过了已配置的 z-score. 不过如果在最近一个小时内异常量非常巨大,这个机制就失效了,这个时候我们只好提升问题的严重性,通知多个人同时进行排查。我们要求开发者必须要对他们的变更负责监控,而不是完全交给机器。

第 3 段(可获 2 积分)
exception_counts = app.needles.histogram(1.hour.ago, Time.now, 3.minutes)
stddev = exception_counts.standard_deviation
mean = exception_counts.mean

if zscore(exception_counts.last, mean, stddev) > app_zscore
  campfire.message(message) if last_deploy.warned_at.nil?
end

Exception level graphs

如果发现了异常级别出现一个尖峰,Hubot 将提醒最后的部署者一些关于应用当前状态的统计信息。这种提醒的好处在于它隐式的设置了一个负责任的机制。最佳的情况是导致某个异常发生的部署者才会收到提醒,没有任何干扰。目前还达不到这个最佳状态,我们在不断的迭代中。

第 4 段(可获 2 积分)

hubotHubot

最近 3 分钟内已经发生了 66 个异常,@Caged 是最后的部署人,时间是 09:18 am PDT (-0700). 请在 haystack 检查?

让我们快速来浏览一下如何寻找问题。

cagedCaged

/haystack sup github

hubotHubot

Deploys
-------
* my-feature deployed by Caged 5 minutes ago - pull request | compare

Rollups
-------
* ▅▁▃▃▇▅ 9 x GitRPC::Timeout, last occurred 2 minutes ago
* ▁▃▁▁▅▅ 5 x GitRPC::ObjectMissing, last occurred 5 minutes ago
* ▁▁▇▁▁▁ 3 x GitHub::TimeoutMiddleware::RequestTimeout, last occurred 17 minutes ago
* ▁▁▇▁▁▁ 3 x GitHub::TimeoutMiddleware::RequestTimeout, last occurred 18 minutes ago
* ▁▁▁▃▁▃ 3 x SlowQueryLogger::SlowQuery, last occurred less than a minute ago
* ▃▁▃▃▁▁ 3 x Ref::ComparisonMismatch, last occurred 15 minutes ago
* ▁▁▁▃▁▃ 2 x GitHub::TimeoutMiddleware::RequestTimeout, last occurred 6 minutes ago
* ▁▃▁▁▁▁ 2 x GitHub::TimeoutMiddleware::RequestTimeout, last occurred 1 minute ago
* ▁▃▃▁▁▁ 2 x ActiveRecord::RecordNotUnique, last occurred 20 minutes ago
[18 more lines]
      
第 5 段(可获 2 积分)

假如有一些 Git 相关的问题发生,我们可以通过 Haystack 面板来获取详情。

Haystack dashboard

这里可以看到是 GitRPC 发生超时。GitRPC::Timeout 异常时发生在当一个文件服务器的 Git 操作时间太长的情况下。你可以想象得到,我们的系统很多地方都可能发生这种问题,我们必须快速确定发生什么问题,在什么地方发生的,该通知谁来修复这个问题。

Haystack rollup view

可以在汇总 Rollup 详情中来查找问题。Rollup 表示一组相同的特征,这是通过对一些不同问题之间相同的属性做哈希得到的。在 Rollup 中我们可以立即看到随着时间的推移到底发生了多少异常,影响的用户、仓库、路由器和服务器。继续滚动我们可以看到单独的异常信息。但如果你查看上面图像的顶部你会发现紫色和蓝色的条目,这些就是我们所说的“责任”的领或者简称为 AOR。

第 6 段(可获 2 积分)

Graphite AOR exception rates

责任范围提供很多方面的帮助。通过它可以一眼就认出出现问题的区域以及哪个团队该为这些问题负责。除此之外,我们使用图形来跟踪异常率,所以能看到随着时间变化异常的处理情况。

Haystack attributes list

由于早期我们在很多地方都使用了 Git,因此有大量的 AOR 是跟这些有关的。我们会看到最近很多相同的问题,点击进去就可以看到问题的详情。特别是我们可以看到网站的 :pulse 部分的问题在增加,这发生在 RepositoriesController#contributors_size 方法中,对应分支是 unicode-3-profile branch。这是我们能从这个异常中获取到的具体信息。

第 7 段(可获 2 积分)

Haystack formatted backtrace

另外一个有用的地方就是例如上述异常显示中的橙色部分。我们去掉了任何路径前缀并可直接在异常中链接到对应的源文件。每个应用都有一个简单的 YAML 配置文件用来定义这些规则。

现在我们已经在正确的轨道上了,我们知道发生了什么,什么时候发生的,错误程度、哪个团队负责以及如何去查找解决的办法。修复这些问题,需要创建一个 Pull Request 或者 Issue 并将链接发布在 Haystack 的详细评论内容中,这样 Haystack 就会自动生成一个跨站引用。这可以方便工程师们快速的在问题和源头之间快速切换,了解这个过程发生的事情。最后,如果这个问题在未来再次发生,那么会自动关联上这个已有的问题。

第 8 段(可获 2 积分)

为什么不适用已有的开源项目以及什么时候开源 Haystack?

Haystack 是 2009 年推出的,尽管之前不一定叫这个名字。我已经忘了之前是什么样子的,但肯定不是今天这样子。2012年初我们开始更新 Haystack 时,我们侧重于提升已有的应用。在过去的几年内我们队 Haystack 做了大量的改动,这些改动都是跟内部的应用相关,跟我们的工作方法相关,然后才到了今天这个样子。Haystack 的价值在于深度的集成到我们的业务系统中,因此很难开源,但我们希望这样的模式或许对你的架构有帮助,可以实现更好的监控、告警以及调试!

第 9 段(可获 2 积分)

文章评论