它的实现原理如上图所示。具体的，前文提到的实时计算模块Shaka将Trace数据计算成Metric数据时，会额外以抽样的方式将Trace上的RequsetId与RpcId也写到Metric上（即上文Esper语句中，生成的Metric中的sampling字段）。这种Metric数据会被Consumer模块消费并写入到HBase一张Sampling表中。
用户在前端Portal的指标曲线上点击某个点时，会构建一个Sampling的查询请求。该请求会带上：该曲线的指标名、数据点的起止时间、用户选择过滤条件（即Tags）。Consumer基于这些信息构建一个HBase的RegexStringComparator的Scan查询。查询结果中可能会包含多个结果，对应着该时间点内数据点（Metric）上发生的多个调用链路（Trace），继而拿着结果中的RequestId RpcId再去查询一次HBase/HDFS存储就能获得链路原文。（注：实际构建HBase Rowkey时Tag部分存的是其Hashcode而不是原文String。）
众多转岗、离职的饿了么小伙伴，最念念不忘不完的就是这种“所见即所得”的可观测性排障体验。
报警Watchdog 1.0在应用可观测性基本全覆盖之后，报警的需求自然成了题中之义。技术选型上，根据我们在实时计算模块Shaka上收获的经验，决定再造一个基于实时数据的报警系统--Watchdog。
实时计算模块Shaka中已经将Trace数据计算成指标Metrics，报警模块只需消费这些数据，再结合用户配置的报警规则产出报警事件即可。因此，我们选型使用Storm作为流式计算平台，在Spount层次根据报警规则过滤和分流数据，在Bolt层中Esper引擎运行着由用户配置的报警规则转化成Esper语句并处理分流后的Metric数据。若有符合Esper规则的数据，即生成一个报警事件Alert。Watchdog Portal模块订阅Kafka中的报警事件，再根据具体报警的触达方式通知到用户。默认Esper引擎中数据聚合时间窗口为1分钟，所以整个数据处理流程的时延约为1分钟左右。
Metrics API与LinDB 2.0：在ETrace 1.0阶段，我们只提供了Trace相关的API，LinDB仅供内部存储使用。用户逐步的意识到如果能将“指标”与“链路”整合起来，就能发挥更大的功用。因此我们在ETrace-Agent中新增了Metrics相关的API：
// 计数器类型
Trace.newCounter(String metricName).addTags(Map<String, String> tags).count(int value);
// 耗时与次数
Trace.newTimer(String metricName).addTags(Map<String, String> tags).value(int value);
// 负载大小与次数
Trace.newPayload(String metricName).addTags(Map<String, String> tags).value(int value);
// 单值类型
Trace.newGauge(String metricName).addTags(Map<String, String> tags).value(int value);
基于这些API，用户可以在代码中针对他的业务逻辑进行指标埋点，为后来可观测性大一统提供了实现条件。在其他组件同步开发时，我们也针对LinDB做了若干优化，提升了写入性能与易用性：
- 增加Histogram、Gauge、Payload、Ratio多种指标数据类型；
- 从1.0版本的每条指标数据都调用一次RocksDB的API进行写入，改成先在内存中聚合一段时间，再通过RocksDB的API进行批量写入文件。
在2017年的饿了么，除了ETrace外还有多套可观测性系统：基于Statsd/Graphite的业务可观测性系统、基于InfluxDB的基础设施可观测性系统。后两者都集成Grafana上，用户可以去查看他的业务或者机器的详细指标。但实际排障场景中，用户还是需要在多套系统间来回切换：根据Grafana上的业务指标感知业务故障，到ETrace上查看具体的SOA/DB故障，再到Grafana上去查看具体机器的网络或磁盘IO指标。虽然，我们也开发了Grafana的插件来集成LinDB的数据源，但因本质上差异巨大的系统架构，还是让用户“疲于奔命”式的来回切换系统，用户难以有统一的可观测性体验。因此2018年初，我们下定决心：将多套可观测性系统合而为一，打通“业务可观测性 应用可观测性 基础设施可观测性”，让ETrace真正成为饿了么的一站式可观测性平台。
所谓“改造”未动，“存储”先行。想要整合InfluxDB与Statsd，先要研究他们与LinDB的异同。我们发现，InfluxDB是支持一个指标名（Measurement）上有多个Field Key的。如，InfluxDB可能有以下指标：
measurement=census, fields={butterfiles=12, honeybees=23}, tags={location=SH, scientist=jack}, timestamp=2015-08-18T00:06:00Z
若是LinDB 2.0的模式，则需要将上述指标转换成两个指标：
measurement=census, field={butterfiles=12}, tags={location=SH, scientist=jack}, timestamp=2015-08-18T00:06:00Z
measurement=census, field={honeybees=23}, tags={location=SH, scientist=jack}, timestamp=2015-08-18T00:06:00Z
可以想见在数据存储与计算效率上，单Field模式有着极大的浪费。但更改指标存储的Schema，意味着整个数据处理链路都需要做适配和调整，工作量和改动极大。然而不改就意味着“将就”，我们不能忍受对自己要求的降低。因此又经过了几个月的爆肝研发，LinDB 3.0开发完成。
这次改动，除了升级到指标多Fields模式外，还有以下优化点：
- 集群方面引入Kafka的ISR设计，解决了之前机器故障时查询数据缺失的问题。
- 存储层面支持更加通用的多Field模式，并且支持对多Field之间的表达式运算。
- 引入了倒排索引，显著提高了对于任意Tag组合的过滤查询的性能。
- 支持了自动化的Rollup操作，对于任意时间范围的查询自动选取合适的粒度来聚合。
经过这次大规模优化后，从最初的每日5T指标数据涨到如今的每日200T数据，LinDB 3.0都经受住了考验。指标查询的响应时间的99分位线为200ms。详细设计细节可参看文末的分布式时序数据库 - LinDB。
将Statsd指标转成LinDB指标Statsd是饿了么广泛使用的业务指标埋点方案，各机房有一个数十台机器规模的Graphite集群。考虑到业务的核心指标都在Statsd上，并且各个AppId以ETrace Metrics API替换Statsd是一个漫长的过程（也确实是，前前后后替换完成就花了将近一年时间）。为了减少对用户与NOC团队的影响，我们决定：用户更新代码的同时，由ETrace同时“兼容”Statsd的数据。
得益于饿了么强大的中间件体系，业务在用Statsd API埋点的同时会“自动”记一条特殊的Trace数据，携带上Statsd的Metric数据。那么只要处理Trace数据中的Statsd埋点，我们就能将大多数Statsd指标转化为LinDB指标。如下图：多个Statsd指标会转为同一个LinDB指标。
// statsd:
stats.app.myAppName.order.from_ios.success 32
stats.app.myAppName.order.from_android.success 29
stats.app.myAppName.order.from_pc.failure 10
stats.app.myAppName.order.from_openapi.failure 5
// lindb:
MetricName: myAppName.order
Tags:
"tag1"=[from_ios, from_android,from_pc, from_openapi]
"tag2"=[success, failure]
之前我们的实时计算模块Shaka就在这里派上了大用场：只要再新增一路数据处理流程即可。如下图，新增一条Statsd数据的处理Pipeline，并输出结果到LinDB。在用户的代码全部从Statsd API迁移到ETrace API后，这一路处理逻辑即可移除。
InfluxDB主要用于机器、网络设备等基础设施的可观测性数据。饿了么每台机器上，都部署了一个ESM-Agent。它负责采集机器的物理指标（CPU、网络协议、磁盘、进程等），并在特定设备上进行网络嗅探（Smoke Ping）等。这个数据采集Agent原由Python开发，在不断需求堆叠之后，已庞大到难以维护；并且每次更新可观测逻辑，都需要全量发布每台机器上的Agent，导致每次Agent的发布都令人心惊胆战。
我们从0开始，以Golang重新开发了一套ESM-Agent，做了以下改进：
- 可观测性逻辑以插件的形式，推送到各宿主机上。不同的设备、不同应用的机器，其上运行的插件可以定制化部署。
- 制定插件的交互接口，让中间件团队可定制自己的数据采集实现，解放了生产力。
- 移除了etcd，使用MySql做配置数据存储，减轻了系统的复杂度。
- 开发了便利的发布界面，可灰度、全量的推送与发布Agent，运维工作变得轻松。
- 最重要的，收集到的数据以LinDB多Fields的格式发送到Collector组件，由其发送到后续的处理与存储流程上。
