核心观点：交互式组件执行路径中的错误增强了复杂故障的可观测性。这些可观测性带来了更多的可能。实际上就是通过inter-process和inter-thread的error log来增加可观测性。一个设计点是indirection的处理。

开源 https://github.com/ryanphuang/panorama

Panorama system

Abstractions and APIs

核心概念是observation，此外还有

observer，发出观察的
subject，被观察的
status，被观察者的状态
context，观察者的状态
verdict，综合判断

Local Observation Store

LOS由两个主要结构组成：原始观察和判决表。

因为是分布式的，所以同一个subject的原始观察是被同步的。

判决表不需要同步，因为是deterministic的。

Observers

Panorama没有采用专门的故障检测器。相反，它利用现有分布式系统组件中的代码逻辑，将它们变成原地的逻辑观察者。

有两种方法可以将一个组件变成一个Panorama观察者。一种是在组件的源代码中插入Panorama API钩子。另一种是通过不断解析和监测与其他组件有关的日志条目，与组件的日志集成。

Panorama使用的是后者。为了减轻开发人员插入Panorama钩子的负担，Panorama提供了一个离线分析工具，自动进行源代码插桩。

Observation Exchange

本地观测者提交给LOS的观测结果只反映了被观测者的部分观点。为了减少观察结果的偏差，Panorama运行一个传播程序，将观察结果传播给其他LOS，并从他们那里学习观察结果。

每个LOS保持一个观察列表，其中最初只包含本地观察者。当本地观察者向LOS报告观察结果时，LOS会将观察的主题添加到观察列表中，以表明它现在对其他人关于这个主题的观察感兴趣。每个LOS还为每个子目标保留一个忽略列表，其中列出了它不应该向其传播关于该目标的新观测的LOS。

当一个新主题的本地观测首次出现时，LOS会进行一次性的广播。对观察结果不感兴趣的LOS（基于他们自己的观察列表）将指示广播的LOS将他们列入其忽略列表。如果一个LOS后来对这个主题感兴趣，该协议就会确保集团成员将这个LOS从他们的忽略名单中重新移出。

Judging Failure from Observations

bounded-look-back majority算法。

For a set of observations about a subject, we first group the observations by the unique observer, and analyze each group separately.

The observations in a group are inspected from latest to earliest and aggregated based on their associated contexts.

For an observation being inspected, if its status is different than the previously recorded status for that context, the look-back of observations for that context stops after a few steps to favor newer statuses.

Afterwards, for each recorded context, if either the latest status is unhealthy or the healthy status does not have the strict majority, the verdict for that context is unhealthy with an aggregated severity level.

Design Pattern and Observability

给了一个例子，说明当发生indirection的时候，可观测性会收到影响。很难通过交互来判断subject的健康情况。

分析包括以下四种

no indirection
request indirection
response indirection
full indirection

Observability Analysis

Locate Observation Boundary

Panorama只在cross boundaries的时候记录对应的error。这些boundaries包括

inter-process boundary: a library API invocation, a socket I/O call, or a remote procedure call (RPC)
inter-thread boundary: 通过finding custom public methods in classes that extend the thread class找到

Identify Observer and Observed

通过一些标识符来唯一确定Observer和Subject。

Extract Observation

一旦我们有了观察边界，下一步就是在边界附近寻找观察点。这种观察点的一个典型例子是当异常发生在观察边界时调用的异常处理程序。

为了找到作为异常处理程序的观察点，一个直接的方法是首先确定观察边界可能产生的异常类型，然后在边界之后的代码重新区域中找到这些类型的捕获条款。这种方法有两个挑战。首先，一个异常可能在调用者或调用者的调用者处被捕获。反复在调用链上走动以找到该条款是很麻烦的，而且可能是不准确的。其次，边界抛出的异常类型可能是一个通用的异常，如IOException，可能是由同一try子句中的其他非边界代码产生。这两个挑战可以通过在边界之前插入一个try，并在其之后插入一个catch来解决。这样做是可行的，但是，如果观察边界很频繁的话，过多的包装会造成非显著的开销。

Handling Indirection

大概是等待完整回调。