本篇文章提出了Pigeon，用来在end-host的视角监测。系统包括分布在process、操作系统、路由器和ospf的sensor，报告问题是否是永久性的和问题是否已经发生了。

Pigeon的挑战主要是在架构和设计上，而不是在底层机制上。贡献

网络和主机故障应该暴露给应用程序的论点
用于暴露故障的故障告知者抽象和实现它的服务

motivation challenges & principles

在设计Pigeon时有三个顶级挑战：确定要提供哪些故障细节；安全地处理不确定的信息；以及管理覆盖率、准确度和及时性之间的三方权衡 Pigeon的设计基于以下的原则

放弃killing：考虑提供完美准确性的技术，要使它们不因网络故障而挂掉，需要什么？由于他们的准确性来自于killing（当他们不确定的时候），他们将不得不kill network element，并有意创造network partition。
提供全面覆盖：然而，这导致了两个问题。首先，全覆盖意味着完美的准确性是无法实现的：如果一个告密者必须重新报告所有的故障（并且在不kill的情况下这样做），但对故障是否发生是不确定的，那么告密者有时会错误地报告一些故障。其次，覆盖率、准确性和及时性之间的三方冲突意味着全覆盖会导致准确性（已经不完美）和及时性之间的权衡。
暴露不确定性：尽管偶尔会有错误，故障信息员如何能确保安全？我们的方法是让故障告知者在可能的情况下提供确定性，并将可能出错的报告标记为不确定性。
充分利用本地信息：时间性和准确性的权衡可以通过揭示组件状态的本地知识来改善，对于同样的精度，一个能够访问较低层的故障告知者可以更及时，因为本地信息比必须冒泡到较高层的信息更早可见
设计的可扩展性：避免重新设计的一个关键因素是通过抽象暴露故障，而不是暴露所有细节

Design of Pigeon

The failure informer interface

故障通知器接口向应用暴露conditions，每个condition都抽象了远程目标进程中的一类问题，这些问题都以类似的方式影响分布式应用。有四种condition

在stop condition下，目标进程已经停止执行并失去了它的易失性状态。问题已经发生，而且肯定是永久性的。这个条件抽象了进程崩溃、机器重启等情况。
在unreachability condition下，目标进程可能是可操作的，但客户端无法到达。问题已经发生，但它可能是间歇性的。这种情况下，由于网络瘫痪或进程缓慢而导致的超时被抽象出来。
在stop warning中，目标进程可能很快停止执行，因为一个关键资源丢失或耗尽了。这个问题还没有发生，但是如果它发生了，那就是永久性的。这个条件抽象了一些情况，例如关于即将发生的磁盘故障的重新端口。
在一个unreachability warning中，目标进程可能很快变得不可达，因为一个重要的资源丢失或耗尽。问题还没有发生；如果发生，可能是间歇性的。这个条件抽象了一些情况，如网络链接接近饱和或目标进程的主机CPU过载。

上述四个conditions反映了基于两种对应用有用的不确定性的分类：问题是否肯定是永久性的（停止与不可达）和问题是否肯定发生了（实际与警告）。

Guarantees

Pigeon提供coverage、accuracy、timeliness的保证

Using the interface

给了几个例子，说明在报告不同的condition的时候，应用应该怎么处理。

Architecture

主要分成三个部分：sensor感知、relay向end-host传递信息、interpret information for client application

Prototype of Pigeon

Target environment

我们的原型以使用链路状态路由协议的网络为目标，这在数据中心和企业中很常见。

目前，该原型假设开放最短路径优先（OSPF）协议有一个OSPF区域或路由区。这个假设可能会引起可扩展性问题，我们将在第5.3节讨论这个问题。我们在第6节中讨论多区域路由和第2层网络。

我们假设有一个单一的管理域，运营商可以在应用程序和路由器中调整和安装我们的代码；这种调整是在部署时需要的，而不是在持续运行期间。

Sensors

我们的原型包括四种类型：一个进程传感器和一个在终端主机上的嵌入式传感器，以及一个路由器传感器和一个在路由器上的OSPF传感器。

Process sensor：这个传感器在终端主机上运行。当一个被监控的应用程序启动时，它通过UNIX域套接字连接到其本地进程传感器。该传感器检测三种故障。
- F-exit（关键）。目标进程不再在操作系统的进程表中，并且失去了它的易失性状态，但是操作系统仍然在运行。
- F-suspect-stop。目标进程在进程表中，但对本地探测没有反应。
- F-disk-vulnerable。目标进程使用的一个磁盘发生了故障或容易发生故障
Embedded sensor：嵌入在终端主机操作系统中的逻辑。它可以检测三种故障。
- F-host-reboot（关键）。目标进程的操作系统正在重启。
- F-host-shutdown（关键）。目标进程的操作系统正在关闭。该传感器使用与F-host-reboot相同的机制。
- F-suspect-stop。目标进程的操作系统不再调度一个高优先级进程，该进程每隔T inc时间单位就会增加内核内存中的一个计数器。传感器通过检查计数器是否每隔T inc-check时间单位至少增加一次来检测故障。
Router sensor：路由器上的一个进程作为一个传感器运行，检测两个故障。
- F-suspect-stop。终端主机不再对网络探测做出反应。
- F-link-util。一个网络链接的利用率很高。
OSPF传感器。路由器的OSPF逻辑作为一个传感器，检测两个故障。
- F-link。网络中的一条链路发生了故障。我们环境中的路由器使用双向转发检测（BFD）检测链接故障。
- F-router-reboot。一个网络路由器即将重启。传感器检测到这个故障是因为操作系统通知它路由器即将重启。

不确定性和置信度不一样，置信度是概率性。

Relays

原型使用三种中继：一个在终端主机，称为主机中继，两个在路由器，称为路由器中继和OSPF中继。

主机中继。这个中继器传达由进程传感器检测到的故障，它与进程传感器在同一进程中运行。当一个客户开始监视一个目标进程时，客户的解释器在目标的主机中继站注册一个回调。每当进程传感器检测到一个故障时，主机中继就会调用这个回调。回调提高了及时性，因为解释器在故障发生后很快就能了解到故障。

路由器中继。这个中继器传达由路由器传感器检测到的F-疑似停止故障，以及由嵌入式传感器检测到的所有故障。该中继器与路由器传感器在同一进程中运行，并且它使用与主机中继器相同的回调协议。

OSPF中继。该中继器使用OSPF的链路状态路由协议来交流有关链接的信息。在此协议下，路由器在链路状态广告（LSA）中产生有关其链路的信息，并使用OSPF的泛滥机制向其他路由器发送LSA。对于链路故障（F-link），OSPF中继使用正常的LSA，而对于优雅的关闭（F-router- reboot），中继使用无限距离的LSA。为了宣布过载链路（F-link-util），路由器重新铺设使用不透明的LSA，这是携带特定应用信息的LSA。

The interpreter

解释器必须

确定哪些传感器与客户指定的目标进程相对应：解释器通过使用网络拓扑结构的知识、传感器的位置以及客户和目标进程的位置来确定哪些传感器对目标进程是有意义的。
确定一个condition是否由故障imply：解释器不能把每个故障都报告为condition。If the interpreter cannot determine the effect of a fault from failure information alone, it uses hints.
估计condition的持续时间：解释器估计一些不可达condition的持续时间。目前，这些持续时间是根据我们的测试平台测量结果硬编码的
通过客户库向应用程序报告condition：解释器向客户库报告所有conditions
永远不要错误地报告stop condition：解释器只对关键故障（F-exit等）报告stop

Evaluation

我们考虑了几个真实世界的应用和故障场景（合成故障），并展示了Pigeon在这些情况下的好处。