捕捉并增强故障检测的现场系统可观测性

论文地址：捕捉并增强故障检测的现场系统可观测性 Huang等人，OSDI’18

本文的中心思想是简单而精辟的。在调用进程或线程的客户机中，我们可以获得有关进程或线程运行状况的最相关信息。现在的做法是记录并尝试从客户端失败的调用中恢复，而一个完全独立的故障检测基础设施负责确定事情是否按预期工作。Panorama所做的是将客户机转变为他们调用的组件的观察者和报告者，使用这些观察来确定组件的运行状况。它真的很好用！

全景图可以很容易地与流行的分布式系统集成，并且可以在不到7秒的时间内检测到我们复制的所有15个真实世界的灰色故障，而现有的方法在不到300秒的时间内只检测到其中的一个。

Panaroma是开源的，可在https://github.com/ryanphuang/panorama下载（推荐大家下载下来运行自测下）

用多个观察者对抗灰色故障

在分布式系统环境中最怕的故障恰巧不是雪崩，网络分区，延迟等。以上故障可以通过熔断，负载均衡切换，应用fail-fast,fail-over方式处理。最怕的其实是所谓的”幽灵问题-时好时坏“。**
Panaroma的主要设计是捕捉灰色故障，在灰色故障中，组件和系统提供性能下降，但通常不会崩溃停止。这种失败的一个例子是ZooKeeper集群，它无法再为write requests事件提供服务，尽管leader仍在与它的追随者积极交换heartbeat消息。检测灰色故障通常需要从多个角度观察组件。

在本文中，我们提倡通过增强可观测性来检测复杂的生产故障（一种度量组件的内部状态如何从它们的外部交互中推断出来的方法）…当组件变得不健康时，这个问题很可能通过它对某些（如果不是全部）其他组件的执行的影响来观察。

在ZooKeeper事件示例中，尽管ZooKeeper心跳检测器没有发现部分故障，但客户机Cassandra进程中的请求超时确实被注意到了！

客户端进程可以很好地观察提供者中的问题，但是它们的异常处理代码通常看起来像下面的片段，处理错误（或者至少记录错误！），但不向任何健康管理系统报告。

协同故障检测并不是一个新的概念，但通常是在节点或层内进行的。

Panorama通过允许任何进程中的任何线程报告证据（无论其角色、层或子系统如何），将检测范围推向了极端。由此产生的各种证据来源增强了复杂故障的可观测性。

全景的高级设计
与测量表面信号的单独监视代码不同，Panaroma增强了位于组件之间边界（即线程间和进程间调用）附近的现有客户机代码。基于静态分析，应用程序被用于捕获和报告健康观测，这些观测存储在同一位置的本地观测存储（LOS）中。服务水平的局部决策引擎对观察到的部件状态进行判断。然后，中央裁决服务器允许在分散的败诉中轻松查询判决和仲裁。

使用全景的组件向本地全景实例注册并接收用于报告的句柄。全景视窗有一个观察名单，上面有观察者正在观察的对象。有关某个主题的观察结果存储在本地的专用表中，并且也会传播到监视列表中该主题的所有丢失。

本地决策引擎分析对象的观察日志（包括本地和远程观察），并在判断表中记录判断结果。由于裁决算法是确定性的，因此不会传播裁决。

决策过程通过观察者对一个对象的观察进行分组，然后从最近的观察开始检查每组的观察。对于组中的每个上下文（思考捕获点），将分配一个状态，如果最新状态为“不正常”或“正常”状态没有最近的多数，则该状态为“不正常”。然后汇总所有观察者的总结，并使用简单多数决定状态。

由于这些报告来自请求程序组件执行路径中的错误和成功，而不是人工的非服务信号，我们的经验表明，简单的决策算法足以检测复杂的故障。

一个组件的状态可以是健康、死亡和一些不健康的级别。它也可能是挂起的，当请求者和提供者之间的间接和异步插入时会出现这种情况…

处理间接和异步调用：可观察性模式
**
假设提供者立即响应请求，然后继续在崩溃的后台线程中工作。到目前为止讨论的方案无法应付这种情况。实际上，简单的同步请求-响应模式只是全景团队需要处理的四种通信模式之一：

• (a) synchronous request response
• (b) indirect request, direct reply
• (c) direct request, indirect reply
• (d) indirect request and reply

每种模式对可观测性都有不同的影响。“在不考虑间接影响的情况下放置观察钩可能会导致故障检测的不完整性（尽管不准确）。”

度量工具
**
Panorama包括一个离线工具，它可以静态分析程序的源代码（使用Smoke），找到观察捕获的关键点，并注入用于报告观察结果的钩子（使用AspectJ–yay！）。观察点的典型示例是在观察边界处发生异常时调用的异常处理程序。当然，我们也需要积极（即成功）的观察。观测结果将报告给全景库，在那里进行缓冲，然后在一条聚合消息中发送。

间接模式是通过检测分割请求的源和汇来处理的。

当我们在一个原点有一个观测，但还没有相应的下沉时，这就产生了我们之前看到的挂起状态。我们水槽收到积极的证据，一个健康的观察将随之而来。

我们发现ob源和ob汇分离不仅在检测涉及间接性的问题时有用，而且在检测活性问题时也有用。

评估
Panorama应用于ZooKeeper、HDFS、HBase和Cassandra的进程和线程级别。集成只需要很少的更改。

在将分析器应用于系统时，我们需要注释哪些边界交叉方法可以开始，哪些方法涉及间接寻址，以及它使用的模式。支持这一点的注释工作是适度的（见下表）。HDFS需要做的注释工作最多，一个作者花了大约1.5天的时间来理解HDFS源代码、识别接口和编写注释规范。

下图显示了ZooKeeper中两个检测进程随时间报告的原始观察数。

检测崩溃故障
全景图的目的是检测复杂的故障，不仅仅是故障停止错误，但它最好能够检测故障停止问题以及！作者注入了一些故障停止故障，并测量了全景图报告这些故障所需的时间，与相关系统内置故障检测的检测时间相比。

全景图总是与内置的检测相竞争，有时甚至更快。

检测灰色故障
对于灰色失效测试，作者在所有四个系统中再现了15个真实的生产灰色失效。每种情况在最初发生时都会导致严重的服务中断，在每种情况下，系统仍然被认为是健康的，因此没有采取任何恢复措施。

全景图在所有15个案例中都检测到了灰色故障，检测时间在0.2s到7s之间，大多数小于3s。

全景图除了能够检测出图像的灰度故障外，还能够通过详细的背景信息和观察者信息，准确地找出问题的原因。

假阳性？
由于全景图可以从系统中的任何组件收集观测结果，因此有一个潜在的问题是，噪声观测将导致许多错误警报。但是，根据经验，我们发现这并没有发生…。

观察到的一个ZooKeeper运行了25个小时，多个客户端不停地运行各种工作负载。共作出797219项判决，其中除705项（0.8%）健康外，其余均正常。所有的负面观察都是在系统启动和不稳定的前22秒进行的，剩下的25小时没有报告故障。

管理费用
当全景实例处于活动状态时，它平均消耗大约0.7%的CPU，对于高活动实例，它最多消耗大约50MB的内存。每个检测系统的延迟增加和吞吐量减少低于3%。

最后概述
全景图提出了一种通过构造现场观察者来建立故障检测服务的新方法。评估结果证明了利用可观测性检测复杂生产故障的有效性。

全景图看起来是任何混沌工程计划的完美补充。