随着饿了么的异地多活的技术改造方案确定，对可观测性平台提出了新的挑战：如何设计多活架构下的可观测性系统？以及如何聚合多数据中心的可观测性数据？
经过一年多的推广与接入，ETrace已覆盖了饿了么绝大多数各语言的应用，每日处理数据量已达到了数十T以上。在此数据规模下，决不可能将数据拉回到某个中心机房处理。因此“异地多活”架构下的可观测性设计的原则是：各机房处理各自的可观测性数据。
我们开发一个Gateway模块来代理与聚合各数据中心的返回结果，它会感知各机房间内Console服务。图中它处于某个中央的云上区域，实际上它可以部署在各机房中，通过域名的映射机制来做切换。
如此部署的架构下，各机房中的应用由与机房相绑定的环境变量控制将可观测性数据发送到该机房内的ETrace集群，收集、计算、存储等过程都在同一机房内完成。用户通过前端Portal来访问各机房内的数据，使用体验和之前类似。
即使考虑极端情况下--某机房完全不可用（如断网），“异地多活”架构可将业务流量切换到存活的机房中，让业务继续运转。而可观测性上，通过将Portal域名与Gateway域名切换到存活的机房中，ETrace便能继续工作（虽然会缺失故障机房的数据）。在机房网络恢复后，故障机房内的可观测性数据也能自动恢复（因为该机房内的可观测性数据处理流程在断网时仍在正常运作）。
可观测性数据实时处理的挑战在1.0版本中的Consumer组件，既负责将链路数据写入到HBase/HDFS中，又负责将链路数据计算成指标存储到LinDB中。两个流程可视为同步的流程，但前者可接受数分钟的延迟，后者要求达到实时的时效性。当时HBase集群受限于机器性能与规模，经常在数据热点时会写入抖动，进而造成指标计算抖动，影响可用性。因此，我们迫切需要拆分链路写入模块与指标计算模块。
在选型实时计算引擎时，我们考虑到需求场景是：
- 能灵活的配置链路数据的计算规则，最好能动态调整；
- 能水平扩展，以适应业务的快速发展；
- 数据输出与既有系统（如LinDB与Kafka)无缝衔接；
很遗憾的是，彼时业界无现成的拿来即用的大数据流处理产品。我们就基于复杂事件处理(CEP)引擎Esper实现了一个类SQL的实时数据计算平台--Shaka。Shaka包括“Shaka Console”和“Shaka Container”两个模块。Shaka Console由用户在图形化界面上使用，来配置数据处理流程（Pipeline）、集群、数据源等信息。用户完成Pipeline配置后，Shaka Console会将变更推送到Zookeeper上。无状态的Shaka Container会监听Zookeeper上的配置变更，根据自己所属的集群去更新内部运行的Component组件。而各Component实现了各种数据的处理逻辑：消费Kafka数据、处理Trace/Metric数据、Metric聚合、运行Esper逻辑等。
Trace数据和Metric格式转换成固定的格式后，剩下来按需编写Esper语句就能生成所需的指标了。如下文所示的Esper语句，就能将类型为Transaction的Trace数据计算成以“{appId}.transaction”的指标（若Consumer中以编码方式实现，约需要近百行代码）。经过这次的架构升级，Trace数据能快速的转化为实时的Metric数据，并且对于业务的可观测性需求，只用改改SQL语句就能快速满足，显著降低了开发成本和提升了开发效率。
@Name('transaction')
@Metric(name = '{appId}.transaction', tags = {'type', 'name', 'status', 'ezone', 'hostName'}, fields = {'timerCount', 'timerSum', 'timerMin', 'timerMax'}, sampling = 'Sampling')
select header.ezone as ezone,
header.appId as appId,
header.hostName as hostName,
type as type,
name as name,
status as status,
trunc_sec(timestamp, 10) as timestamp,
f_sum(sum(duration)) as timerSum,
f_sum(count(1)) as timerCount,
f_max(max(duration)) as timerMax,
f_min(min(duration)) as timerMin,
sampling('Timer', duration, header.msg) as sampling
from transaction
group by header.appId, type, name, header.hostName, header.ezone, status, trunc_sec(timestamp, 10);新的UI、更丰富的中间件数据
1.0版本的前端UI，是集成在Console项目中基于Angular V1开发的。我们迫切希望能做到前后端分离，各司其职。于是基于Angular V2的若干个月开发，新的Portal组件登场。得益于Angular的数据绑定机制，新的ETrace UI各组件间联动更自然，排查故障更方便。
饿了么自有中间件的研发进程也在不断前行，在可观测性的打通上也不断深化。2.0阶段，我们进一步集成了--Redis、Queue、ElasticSearch等等，覆盖了饿了么所有的中间件，让可观测性无死角。
*手级功能：指标查看与链路查看的无缝整合传统的可观测性系统提供的排障方式大致是：接收报警（Alert）--查看指标（Metrics）--登陆机器--搜索日志（Trace/Log），而ETrace通过Metric与Trace的整合，能让用户直接在UI上通过点击就能定位绝大部分问题，显著拔高了用户的使用体验与排障速度。
某个排查场景如：用户发现总量异常突然增加，可在界面上筛选机房、异常类型等找到实际突增的某个异常，再在曲线上直接点击数据点，就会弹出对应时间段的异常链路信息。链路上有详细的上下游信息，能帮助用户定位故障。
