Lifeguard本地健康察觉以加速故障检测

概要

SWIM是一个p2p组成员协议具有吸引人的扩展性和鲁棒性。然而，缓慢的消息处理会导致SWIM标记健康的成员消息为失败（因此叫做误报故障探测），即便包含了机制来避免这点。

我们定义了SWIM的特性，是什么导致了这个问题然后提出了Lifeguard，对SWIM的一组扩展，通过局部健康的概念，它本地故障探测模块可能的故障。我们评估了这个方法在精确的环境控制中并且在验证它在真实世界的传感器中，展示了它大大降低了误报率。对比与SWIM的基线真实的故障误报率和探测时间可以同时被减小。

1 介绍

任何分布式系统中必须解决的关键问题是组件之间发现，故障探测，负载均衡。组成员关系是一个易懂的抽象它可以被用来将诶绝这三个问题。组成员和它的客户端提供了当前组成员关系的动态更新视图，并且使用这个视图来执行动作比如请求路由和状态管理。

SWIM是一个组成员协议并且有几个迷人的特性。它的p2p设计和随机沟通单使用让它的节点和网络故障变得高可扩展，健壮，并且容易部署和管理。对比其他的分布式系统协议，它的简单性使其易于实现和调试。

我们知道三个成熟的SWIM开源实现，Butterfly[2]是Habitat[3]的一部分，Habitat[3]是一个流行的软件自动化平台。Ringpop[4]是为支持全球运输技术公司的应用而构建的。memberlist是我们对于SWIM的实现，这是Consul的基础，一个受欢迎的服务发现和管理工具，以及Nomad，一个高可用的数据中心调度。通过我们与客户的关系，我们知道了数十万个运行Consul的事例，并且部署了超过6000个成员在一个组中。

SWIM论文对慢消息处理的敏感性确定为基本SWIM协议的一个问题。慢消息的处理可能是由多种因素引起的，包括CPU连接，网络延迟或者丢失，可能会导致SWIM将健康的成员声明为有缺陷的 - 叫做误报故障单测。针对这种情况，SWIM论文提出了怀疑子协议，这增加了故障检测的延迟，减少了误报。

然而，我们支持Consul和Nomad经历证明了，即便使用怀疑子协议，在某些情况下，缓慢的消息处理可能仍然导致健康的成员被标记失败。当缓慢的处理间歇性发生时，健康成员之间反复摇摆。如果它引发了故障转移的动作，比如供给成员的重平衡，这个摆动的代价可能十分高昂。调试这些场景使我们了解到SWIM处理缓慢消息处理的缺陷，以及去解决这个缺陷的方法。使用的方法是让SWIM的故障检测器的每个实例考虑自身的情况，我们称作本地健康。我们通过对SWIM的一组扩展来实现它，我们叫它Lifeguard。Lifeguard能够明显的减少误报率，无论是在可控的环境下还是真实的环境下。

本文的其余部分结构如下：第二部分阐述了引导我们使用SWIM的优点，以及我们遇到此问题的各种场景。第三部分描述了SWIM和会员列表，以及我们用来评估Lifeguard的SWIM的实现。第4节描述了对SWIM的救生员扩展。第五部分描述了救生员各部件单独和组合的实验评估。部分VI描述了救生员与之前工作的关系。节第七，我们讨论了可以得出的结论和潜力。

2 动机

SWIM基于随机的基于探查的故障检查，基于gossip的更新传播得到了几个好的特性：

• 扩展性。 在SWIM中，第一次检测故障的预期时间，误报率和每个组成员的消息负载无关于组大小。充分传播失败的时间随着团队规模呈对数增长
• 健壮性。因为协议是完全去中心化的，组成员的任何子集同时出现故障或网络分区是可以容忍的。甚至完全分区的子组也可以继续运行，并且在连接重新建立之后自动合并。
• 易于部署和维护。协议的完全去中心化特性意味着，潜在的成员可以联系任成员加入该组织，当一个成员离开时，不需要采取特殊的动作来维护系统的健康。
• 简单的实现。SWIM协议有少量的状态机。因为它是p2p的，没有特殊的结构，比如leader或者层级，必须在初始配置或在成员变更时进行维护。

这里可能指的是在swim之上使用paxos或者raft等算法

使用Gossip的更新传播让SWIM为弱一致性。也就是说在给定的时间点上，不同的成员可能对组成员有不同的看法。事实上，弱一致性对于许多应用程序是可以接受的。在不可接受的地方，正如SWIM论文所指出的那样，可以通过SWIM上层的一致性视图来实现强一致性，从而检查成员列表。

众所周知，SWIM的故障探测子协议容易受到其消息处理缓慢的影响，它可能会导致故障探测的误报，其中健康的成员被错误的声明为故障。这是一个严重的问题，因为从成员中进行转移通常会产生流量成本，一旦恢复健康，就会重新整合到系统中。

SWIM论文通过添加怀疑机制来解决这些问题，细节将会在第三章解释。然而，我们的开发和一系列系统的支持经历，使用SWIM已经表明，即便使用怀疑机制，在数据中心时会遇到的情况下，错误的故障检测可能高问题率发生。当多个成员运行缓慢时，问题会更加严重。如果它们受到慢速成员互动的影响，即便是健康的成员也会把其他健康的成员标记为故障。

我们一觉调试了这个场景的问题包括：

• web服务，为稳定状态而准备的，但是遇到流量大的突发情况。
• 运行防火墙和其他边缘的入口节点经历持续的分布式拒绝服务（DDos）攻击。
• 视频转码服务器，被分配的工作负载过渡占用了可用的CPU。
• 突发的性能实例，例如AWS T2类和Azure b系列虚拟机，它们被分配的工作负载耗尽了它们的CPU积分，因此它们被它们所执行的管理程序限制

在这些和其他场景，SWIM消息的慢处理在被影响的机器上导致了同一族成员中健康的机器被错误的指控失败。我们在裸机和虚拟机上，在私有数据中心或者公有的云服务上遇到过这种情况。

图1: CPU耗尽的误报，误报的故障单测时间总数和在健康的成员中发生的数量，因为陷入困境的成员数量从1-32不等。结果展示了未修改的SWIM和Lifeguard 的SWIM。图1显示了我们重现视频转码场景特征的实验结果。

图1显示了我们重现视频转码场景特征的实验结果。我们部署了一个100个单核集群（Standard_A1_v2类）虚拟机加入微软Azure公共云。Consul代理（必须在要成为SWIM组成员的每个节点上运行的守护进程）被部署在所有机器上。然后，我们在这些机器的一个子集上运行一个cpu密集型工作负载。在这个例子中，我们使用Linux stress工具，配置运行128个进程，每个函数都执行一个密集循环的数学运算。工作负载运行五分钟。我们记录每次测试期间由Consul引发的所有成员失败事件，并在实验结束后分析日志，以确定发生了多少误报故障检测。

图1的x轴显示了运行压力工作负载的机器数量，范围从1到32台机器（其中每台机器代表集群的1%）。对于每个受压力机器的数量，y轴表示两个相关指标

• 总误报，发生在任何成员（包括运行压力工作负载的成员）上的有关健康成员（未在其上运行压力工作负载）的故障事件
• 健康成员的误报，故障事件不仅与健康节点有关，而且由健康节点报告。这些问题尤其令人担忧，因为涉及的两方——引发事件的一方和造成事件的一方——实际上都是健康的。

每个指标显示两次。一次是Consul运行未修改的SWIM，另一次是Consul运行带有Lifeguard的SWIM。

图1展示了对于SWIM，即使是单个重载成员也足以导致一些误报故障检测事件，而只有4个重载成员(表示占集群的4%)足以在健康成员中产生数百个误报，随着承压构件数量的增加，问题变得越来越严重。相比之下，Lifeguard不会产生误报，直到16台机器同时受到压力，健康成员的误报直到32台机器同时受到压力。两者的产生量都明显低于SWIM。

这些问题并不经常发生。但当他们这样做的时候，他们可能是高度破坏性的。调查了一些这样的事件，这些事件已经升级为高优先级的支持请求，导致了Lifeguard的开发。

3 SWIM和Memberlist

在这一章我们首先回顾SWIM，然后描述Memberlist，一个关于SWIM的实现我们用它来评估Lifeguard。

A。SWIM SWIM有俩个组件

• 故障探测，它探测故障的成员，这个故障探测起来自之前的工作[10]。它是完全去中心化的.
• 传播组件，它传播关于加入或离开群组或失败的成员的更新。

故障探测器取自之前的工作。是完全去中心化的。每个组成员以一些可配置的持续时间（称为协议周期）的轮进行异步工作。每个协议周期，每个组员选择一个其他的成员随机检查健康，并且通过发送ping消息执行直接探查。如果ack消息没有在配置的时间内被收到，通过选择k个更多的成员并且发送他们ping-req消息。收到ping-req消息会导致k个成员中的每一个都向被调查的成员发送ping消息。如果它们中任何一个收到应答，转发它给原始探测成员。如果到协议周期结束时，原始成员没有收到直接或者间接探测的应答消息，则认为被探测成员失败。

传播组件是基于goossip的。每个关于成员加入或离开组的更新会崩共享到其他成员$\lambda log(n)$次，其中n是已知组的大小，$\lambda$是可调节的参数。更新被承载在故障探测协议的ping，ping-req，和ack消息上，所以没有多余的消息被发送。每条消息附带的更新数量是有限的（取决于队消息大小的限制，例如UDP数据的MTU），共享次数较少的更新是首选，以便在更新活动频繁的时候尝试并推进所有更新的传播。

在最简单的SWIM实现中，当一个成员故障探测检查失败，它被立即标记为失败，通过传播组件分享的组中。然而SWIM的作者自己观察到误报的故障探测，并且指出消息缓慢是主要原因。为了解决这点SWIM论文中引入了怀疑机制。它是作为一个扩展引入，但在实践中是SWIM的必要组成部分。在第一章中所有的成熟的SWIM都实现了它。

随着怀疑的使用，哪些在故障探测中没有通过故障检测器的成员将进入中间的可疑状态，并且suspect信息通过传播机制进行传播，确定能否可以在超时之间驳斥怀疑。任何接收到可以消息的也将指定的成员标记为可以，并且gossip它的怀疑。如果怀疑超时，而没有被反驳，被怀疑的成员被通过gossip confirm消息声明为故障。使用这种方式，怀疑机制增加了故障探测延迟总而减低了误报探测率。

一个怀疑是通过一个关于被怀疑的成员的八卦消息来反驳的，并在任何一个成员到达怀疑超时之前到达所有怀有怀疑的成员。SWIM论文描述了俩中机制，通过alive消息可能发起自：在一轮失败检测中成功探测到可疑成员后，由怀有怀疑的成员发起，在一轮检测成功探测到可疑成员后，或者由可疑成员本身发起，在它收到自己的可疑或者确认消息之后。然而在现实中，背会阿姨的成员必须gossip关于它自身的 alive消息来反驳进行工作。

SWIM论文对基本协议的另一个改进是让每个成员选择自己的故障检测器目标-以选房的方式从已知的成员列表中，而不是完全随机的。没有这一点，最坏的情况下，首次检测的延迟是无限的，由于（即为罕见的）在组成员中选择故障检测器目标的情况反复未能选择出故障成员。在轮询中探查，最坏的情况是有限的。然而，每个成员的列表，依然有随机顺序，新成员被插入到随机位置。因此，预期的首次检测时间不变。

B memberlist

memberlist是一个SWIM的开源项目，使用的工具包括了Consul，Nomad和Serf。memberlist实现了所有的SWIM上面描述的特征，它有以下的特征：

• memberlist故障探测使用UDP进行直接和间接的故障探测。但是通过UDP发出间接探测的同时，它将尝试通过TCP进行直接探测。这有助于TCP流量被正确路由的情况，但UDP不是，这是在网络配置中有时会遇到的病理。
• Memberlist添加了anti-entropy机制，通过每个节点定期通过TCP将完整的状态和其他随机选择的节点进行同步。采用[12]pushpull的方式，使用化身序号来调节给定成员的冲突状态。这个完全的状态同步增加了节点更快聚合的可能性，但以更多的带宽为代价。它对于加速从网络分区中恢复特别有帮助。
• Memberlist有一个独立于故障探测协议的gossip层。类似SWIM，memberlist将会承载gossip消息（suspect，alive和confirm）在故障探测信息熵（ping，ping-req，ack），但它也会周期性的子集发送gossip消息。这可以独立于故障检测率来调整gossip的率，如果有必要的话还可以加快收敛速度。
• memberlist保持了周期时间内故障节点的状态，因此，故障节点的状态可以在完全状态同步中传递。这帮助了gossip收敛的概率。

由于这些特性通常在部署Memberlist的时候使用，它们都可以用于本文的评估。Butterfly[2]和Ringpop[4]实现了许多相同的附加功能。

4 Lifeguard

这里可能指的是间接探测节点是需要都存活的

调查可能的在第二章中所述的解决方案，我们观察到怀疑机制仍然假设一些即使处理一些消息。特别帅，只有当所有怀疑该成员的成员都即使处理了反驳alive消息时，对怀疑的反驳才成功。因此，故障检测器模块本身处理缓慢是导致SWIM的怀疑机制无法抑制的误报的主要原因。

我们还观察到，缺少预期的响应可能表明成员正在经历缓慢的预期处理，在一个给定的群组成员中，一个缓慢的消息处理插曲可能会在短时间内影响其与其他成员的多次交互。我们将其称为该节点本地故障检测器实例的运行状况度量，我称为本地健康。

基于这些观察，我们设计了Lifeguard：一组SWIM的扩展让它成为自适应协议。Lifeguard使用启发式的方法衡量本地健康，让成员考虑当故障探测器便慢以及，如果这样动态的调节超时时间缓解时效性问题。

Lifeguard尽可能的维护和SWIM相同的设计。它与SWIM的不同之处在与三个组成部分，这些组成部分提供了新颖的行为：

• 本地健康感知探测（LHA-探测）取代SWIM故障检测器的探测阶段， 它有固定的探测周期和超时，其中一个是动态调整的，基于该成员与其他成员的故障检测相关通信。
• 本地健康感知怀疑（LHA-Suspicion）替换SWIM故障探测器的怀疑状态，SWIM的有固定的怀疑超时，另一个有动态的超时。每个新怀疑的超时往明显的高于固定的超时，但是随着对同一可以成员的独立怀疑被处理它会减少。
• Buddy系统 将SWIM的消息选择器替换为有限通知可以成员选择器，以减少平均的反驳时间，它同时有助于本地健康感知探测和本地健康感知怀疑组件便的甚至更有效。

这个组件的细节在下面进行描述。

A。本地健康感知探查

本地健康感知探查（LHA-Probe）替换了SWIM的故障探测器的探测阶段，它有固定的周期和超时，其中一个是基于最近成员故障检测相关通信调整的。使用了几个反馈源：

nack就是间接的ping。这里的LHM的意义就是判断自身是否健康，自身越健康，越频繁的发出探测，并将超时时间设置的越短。

• 将受到的ack消息的数量与发出的ping和ping-req消息的数量进行比较。缺少的消息可能是由于本地特别慢，特别是由多个ack消息缺少的情况下。
• 需要反驳对自己的怀疑，说明该成员没有处理最近的ping消息。
• 本地健康感知探测添加了nack消息来进行故障探测协议，它会在直接探测失败的情况下进行发送。这为发起间接探查的成员提供了一种检查它是否从所招募的k个成员那里受到即使响应的方法，即便是间接的ping目标没有响应。

不同的反馈源结合本地健康乘数（LHM）。LHM是一个饱和计数器，最大值为S最小值为0，它不会比S大不会比0小。以下事件会导致LHM计数器发生指定的更改：

• 成功的探测（ping或者ping-req和ack）：-1
• 失败的探测 +1
• 驳斥关于自己的怀疑消息：+1
• 错过了nack探测+1

LHM当前的值被用来设置探测间隔和超时时间如下

这里的S其实就是一个倍数。

$$ P robeInterval = BaseP robeInterval.(LHM(S) + 1)\\ P robeT imeout = BaseP robeT imeout.(LHM(S) + 1) $$

ProbeInterval是尝试连续随机的对等体进行活体探测之间的周期，ProbeTimeout是接受给定探测的ack消息的超时时间。在Memberlist的视线中，我们设置BaseProbeInterval为1秒，并且BaseProbeTimeout为500ms。S默认为8，这意味着探测间隔和超时分别减少到9秒和4.5秒。

B。本地健康感知怀疑

怀疑时间保持很高就意味着，这个节点会保留更长的时间。

本地健康探测怀疑（LHA-Suspicion）替换了SWIM故障探测的怀疑阶段，其中SWIM有固定的怀疑超时，而LHA有动态的超时。每次新怀疑的超时时间起始值显著高于固定超时的情况，但随着来自其他成员针对同一被怀疑成员的独立怀疑被处理，该超时时间会缩短。这样，只要本地成员即使接受和处理gossip消息，超时时间就会降到最小。相反，对于没有及时接受和处理gossip消息的成员来说，怀疑时间将保持很高。

这一机制模拟了一种“信心累积”的过程：随着独立怀疑的数量增加，对目标节点确实失效的信心也随之提高，因此可以更快地标记故障。

每次收到新的独立怀疑（从未见过的怀疑消息），系统会根据公式重新计算怀疑超时时间。

• 如果独立怀疑数量 CCC 增加，超时时间会缩短（更接近 MinMinMin）。
• 每个怀疑消息都显著提高系统的信心，但后续怀疑的边际影响逐渐减弱（通过对数衰减公式实现）。

这反应了信心随独立怀疑数量的C增长的非线性关系，第一个怀疑对信心的贡献最大，后续的怀疑贡献逐渐变小。

为了更高效地传播独立怀疑消息，LHA-Suspicion 增强了 Gossip 的传播规则：当收到针对同一目标节点的新独立怀疑（最多 K 次），节点会将这些消息重新传播。

给定的怀疑计算超时如下

$$ SuspicionT imeout =max( M in, M ax − (M ax − M in)\frac{log(C+1)}{log(K+1)}) $$

其中

• Min和Max是最小和最大的可疑超时时间。章节5-C讨论了这个配置。
• K是将怀疑超时时间设置为Min之前需要接受的独立怀疑的个数。我们默认设置K为3。
• C是自提出怀疑以来受到的关于该成员独立怀疑的数目。

每当受到suspect消息，就会重新计算超时，该消息表示以前从未见过的对同一组成员的独立怀疑。此时，当前的怀疑计时器将被取消，并替换为剩余时间的怀疑计时器，直到新的减少超时。如果已经过了一段时间，则会出发超时。

使用对数衰减，随着受到更多独立的可疑信息，以便超时的每次连续减少都小于上一次。这背后的直觉是，第一个独立的消息可以最大程度增加被即使接受的信心，而随后每个消息的增加信心则更少。

为了让独立的怀疑更加普遍，当启用LHA怀疑时，收到的关于同一成员的第一个K独立怀疑会被重新gossip。每个怀疑被发送$\lambda log(n)$次，如果再收到K个怀疑，被发送消息的最大值是$(K+1)\lambda log(n)$.没有LHA-Suspicion，独立的怀疑就不会被重新传播，只有成员自己的怀疑才会被gossip，最大$\lambda log(n)$次。

C。buddy系统

在SWIM中，被怀疑的成员不保证在第一时间听到怀疑的消息。被怀疑的节点只在接收到关于自己的suspect消息才怀疑自己。虽然Gossip消息被附加在故障检测器消息上，包括ping消息，控制八卦消息传播的规则包括每次携带的八卦消息数量有限，每条八卦消息的重复发送次数，以及对更新的八卦消息的偏好有限。

Buddy System将SWIM的piggyback消息选择器替换为优先通知可疑成员的消息选择器。这保证了任何Ping可以消息的节点（要么代表它自己，要么代表另一个节点的间接路径）都会将怀疑作为ping的一部分进行通信。这可以导致反驳开始更快，这将是有帮助的，即使没有其他救生员组件。但它也有助于本地健康感知探查和地方健康感知怀疑更有效地发挥作用。

5 评估

6 相关工作

7 结论

我们的Lifeguard的目标是减少相对于SWIM来说的故障误报率，同事最小化延迟一下和消息负载。在官方的测试案例中，Lifeguard做到了，将误报率降低了10-100倍，平均降低了50倍以上。误报率大大降低，以至于模型并发异常级别上，再重复测试期间，健康节点没有出现误报。实现这一目标的中位数检测和传播潜伏的增加可以忽略不记，而99和99.9潜伏期适度增加（6-9%）。平均而言，发送的信息增加了12%，但是发送的总字节数实际上在下降2%。

此外，通过使用Lifeguard的本地健康感知怀疑组件来进行调和，误报的减少可以换来延迟的减少。但是即便在最极端的权衡测试中，其中中位检测和传播延迟减少了45%（接近2倍），对比与SWIM健康节点的假阳率仍然降低68%（三倍）。

所有检测和传播延迟的度量都通过调整而减少，然而，中位延迟和第99百分位延迟之间的差距随着中位延迟的减少而扩大。这不奇怪，因为Lifeguard选择与通信的同班就像SWIM一样，是随机的成员之间没有协调。进一步的工作会探索一种方式更健米的绑定探测和传播延迟。增加随机覆盖网络可能是一种方法，我可没特别从[31]上徐州那好哦灵感。

Lifeguard 目前有几个参数使用了启发式确定的值。这些参数包括本地健康感知怀疑（LHA-Suspicion）的重新 Gossip 因子（K）、LHM 计数器的饱和限制（S），以及影响 LHM 计数器的不同事件所分配的分数。未来的工作可以探索对这些参数进行自动调节的可能性，其中一种可行的方法是寻找（或学习）相关的指标，使这些参数能够通过反馈机制自适应地调整。

在开发Lifeguard时，我们设计了启发式的方法，利用了Lifeguard从SWIM继承的随机通信模式。未来的工作可能会取代Lifeguard的启发式，有一个正式的模型，或从一个模型衍生的新启发式，如[31]，或从一个效用函数，如[32]。另一项工作是研究将本地运行状况方法应用于其他类型的故障检测器。

引用

[1] A. Das, I. Gupta, and A. Motivala, “SWIM: Scalable Weakly - consistent Infection - style Process Group Membership Protocol,” in Proceedings of the 2002 International Conference on Dependable Systems and Networks, ser. DSN ’02. Washington, DC, USA: IEEE Computer Society, 2002, pp. 303–312.
[2] (2017, Nov.) Butterfly documentation. Chef. [Online]. Available: https://www.habitat.sh/docs/internals/#supervisor - internals
[3] (2017, Nov.) Habitat. Chef. [Online]. Available: https://www.habitat.sh
[4] (2017, Nov.) Ringpop documentation. Uber Technologies Inc. [Online]. Available: https://ringpop.readthedocs.io/en/latest/architecture design.html
[5] HashiCorp, “memberlist Project,” https://github.com/hashicorp/memberlist, 2017, [Online; accessed 28 - Feb - 2017].
[6] ——, “Consul Project,” https://www.consul.io/, 2017, [Online; accessed 28 - Feb - 2017].
[7] ——, “Nomad Project,” https://www.nomadproject.io/, 2017, [Online; accessed 28 - Feb - 2017].
[8] ——, “Consul vs. Serf,” https://www.consul.io/intro/vs/serf.html, 2017, [Online; accessed 28 - Feb - 2017].
[9] D. Ongaro and J. Ousterhout, “In search of an understandable consensus algorithm,” in Proceedings of the 2014 USENIX Conference on USENIX Annual Technical Conference, ser. USENIX ATC’14. Berkeley, CA, USA: USENIX Association, 2014, pp. 305–320. [Online]. Available: http://dl.acm.org/citation.cfm?id=2643634.2643666
[10] I. Gupta, T. D. Chandra, and G. S. Goldszmidt, “On scalable and efficient distributed failure detectors,” in Proceedings of the Twentieth Annual ACM Symposium on Principles of Distributed Computing, PODC 2001, Newport, Rhode Island, USA, August 26 - 29, 2001, 2001, pp. 170–179. [Online]. Available: http://doi.acm.org/10.1145/383962.384010
[11] HashiCorp, “Serf Project,” https://www.serf.io/, 2017, [Online; accessed 28 - Feb - 2017].
[12] A. Demers, D. Greene, C. Hauser, W. Irish, J. Larson, S. Shenker, H. Sturgis, D. Swinehart, and D. Terry, “Epidemic algorithms for replicated database maintenance,” in Proceedings of the Sixth Annual ACM Symposium on Principles of Distributed Computing, ser. PODC ’87. New York, NY, USA: ACM, 1987, pp. 1–12. [Online]. Available: http://doi.acm.org/10.1145/41840.41841
[13] T. Bowden, B. Bauer, J. Nerin, S. Feng, and S. Seibold, “The /proc Filesystem,” https://www.kernel.org/doc/Documentation/filesystems/proc.txt, 2009, [Online; accessed 28 - Feb - 2017].
[14] HashiCorp, “Consul Telemetry,” https://www.consul.io/docs/agent/telemetry.html, 2017, [Online; accessed 28 - Feb - 2017].
[15] I. Gupta, K. P. Birman, and R. van Renesse, “Fighting fire with fire: using randomized gossip to combat stochastic scalability limits,” Quality and Reliability Engineering International, vol. 18, no. 3, pp. 165–184, 2002.
[16] T. D. Chandra and S. Toueg, “Unreliable failure detectors for reliable distributed systems,” J. ACM, vol. 43, no. 2, pp. 225–267, Mar. 1996.
[17] W. Chen, S. Toueg, and M. K. Aguilera, “On the quality of service of failure detectors,” in Proceeding International Conference on Dependable Systems and Networks. DSN 2000, 2000, pp. 191–200.
[18] ——, “On the quality of service of failure detectors,” IEEE Trans. Computers, vol. 51, no. 1, pp. 13–32, 2002.
[19] M. Bertier, O. Marin, and P. Sens, “Implementation and performance evaluation of an adaptable failure detector,” in Proceedings International Conference on Dependable Systems and Networks, June 2002, pp. 354–363.
[20] N. Hayashibara, X. Defago, R. Yared, and T. Katayama, “The phi; accrual failure detector,” in Proceedings of the 23rd IEEE International Symposium on Reliable Distributed Systems, 2004., Oct 2004, pp. 66–78.
[21] B. Satzger, A. Pietzowski, W. Trumler, and T. Ungerer, “A new adaptive accrual failure detector for dependable distributed systems,” in Proceedings of the 2007 ACM Symposium on Applied Computing, ser. SAC ’07. New York, NY, USA: ACM, 2007, pp. 551–555.
[22] J. Liu, Z. Wu, J. Wu, J. Dong, Y. Zhao, and D. Wen, “A weibull distribution accrual failure detector for cloud computing,” PLOS ONE, vol. 12, no. 3, pp. 1–16, 03 2017.
[23] I. Gupta, A. M. Kermarrec, and A. J. Ganesh, “Efficient epidemic - style protocols for reliable and scalable multicast,” in 21st IEEE Symposium on Reliable Distributed Systems, 2002. Proceedings., 2002, pp. 180–189.
[24] P. Levis, N. Patel, D. Culler, and S. Shenker, “Trickle: A self - regulating algorithm for code propagation and maintenance in wireless sensor networks,” in Proceedings of the 1st Conference on Symposium on Networked Systems Design and Implementation - Volume 1, ser. NSDI’04. Berkeley, CA, USA: USENIX Association, 2004.
[25] S. Gobriel, D. Mosse, and R. Melhem, “Mitigating the FloodingWaves Problem in Energy - Efficient Routing for MANETs,” in 26th IEEE International Conference on Distributed Computing Systems (ICDCS’06), 2006, pp. 47–47.
[26] Z. J. Haas, J. Y. Halpern, and L. Li, “Gossip - based ad hoc routing,” in Proceedings.Twenty - First Annual Joint Conference of the IEEE Computer and Communications Societies, vol. 3, 2002, pp. 1707–1716 vol.3.
[27] ——, “Gossip - based ad hoc routing,” IEEE/ACM Transactions on Networking, vol. 14, no. 3, pp. 479–491, June 2006.
[28] P. Kyasanur, R. R. Choudhury, and I. Gupta, “Smart gossip: An adaptive gossip - based broadcasting service for sensor networks,” in 2006 IEEE International Conference on Mobile Ad Hoc and Sensor Systems, Oct 2006, pp. 91–100.
[29] V. Bhandari and I. Gupta, “Prioritycast: Efficient and time - critical decision making in first responder ad - hoc networks,” in 2006 IEEE International Conference on Mobile Ad Hoc and Sensor Systems, Oct 2006, pp. 246–255.
[30] H. Johansen, A. Allavena, and R. van Renesse, “Fireflies: Scalable support for intrusion - tolerant network overlays,” in Proceedings of the 1st ACM SIGOPS/EuroSys European Conference on Computer Systems 2006, ser. EuroSys ’06. New York, NY, USA: ACM, 2006, pp. 3–13.
[31] J. A. Patel, I. Gupta, and N. Contractor, “Jetstream: Achieving predictable gossip dissemination by leveraging social network principles,” in Fifth IEEE International Symposium on Network Computing and Applications (NCA’06), July 2006, pp. 32–39.
[32] G. He, R. Zheng, I. Gupta, and L. Sha, “A framework for time indexing in sensor networks,” ACM Trans. Sen. Netw., vol. 1, no. 1, pp. 101–133, Aug. 2005.