饿了么EMonitor演进史

简介： 可观测性作为技术体系的核心环节之一，跟随饿了么技术的飞速发展，不断自我革新。

序言

 

时间回到2008年，还在上海交通大学上学的张旭豪、康嘉等人在上海创办了饿了么，从校园外卖场景出发，饿了么一步一步发展壮大，成为外卖行业的领头羊。2017年8月饿了么并购百度外卖，强强合并，继续开疆扩土。2018年饿了么加入阿里巴巴大家庭，与口碑融合成立阿里巴巴本地生活公司。“爱什么，来什么”，是饿了么对用户不变的承诺。

 

饿了么的技术也伴随着业务的飞速增长也不断突飞猛进。据公开报道，2014年5月的日订单量只有10万，但短短几个月之后就冲到了日订单百万，到当今日订单上千万单。在短短几年的技术发展历程上，饿了么的技术体系、稳定性建设、技术文化建设等都有长足的发展。各位可查看往期文章一探其中发展历程，在此不再赘述：

 

• 《饿了么技术往事（上）》
• 《饿了么技术往事（中）》
• 《饿了么技术往事（下）》

 

而可观测性作为技术体系的核心环节之一，也跟随饿了么技术的飞速发展，不断自我革新，从“全链路可观测性ETrace”扩展到“多活下的可观测性体系ETrace”，发展成目前“一站式可观测性平台EMonitor”。

 

 

 

LinDB 3.0:

 

所谓“改造”未动，“存储”先行。想要整合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指标转成LinDB指标

 

InfluxDB主要用于机器、网络设备等基础设施的可观测性数据。饿了么每台机器上，都部署了一个ESM-Agent。它负责采集机器的物理指标（CPU、网络协议、磁盘、进程等），并在特定设备上进行网络嗅探（Smoke Ping）等。这个数据采集Agent原由Python开发，在不断需求堆叠之后，已庞大到难以维护；并且每次更新可观测逻辑，都需要全量发布每台机器上的Agent，导致每次Agent的发布都令人心惊胆战。

 

我们从0开始，以Golang重新开发了一套ESM-Agent，做了以下改进：

 

• 可观测性逻辑以插件的形式，推送到各宿主机上。不同的设备、不同应用的机器，其上运行的插件可以定制化部署。
• 制定插件的交互接口，让中间件团队可定制自己的数据采集实现，解放了生产力。
• 移除了etcd，使用MySql做配置数据存储，减轻了系统的复杂度。
• 开发了便利的发布界面，可灰度、全量的推送与发布Agent，运维工作变得轻松。
• 最重要的，收集到的数据以LinDB多Fields的格式发送到Collector组件，由其发送到后续的处理与存储流程上。

 

 

从ETrace到EMonitor，不断升级的可观测性体验

 

2017年底，我们团队终于迎来了一名正式的前端开发工程师，可观测性团队正式从后端开发写前端的状态中脱离出来。在之前的Angular的开发体验中，我们深感“状态转换”的控制流程甚为繁琐，并且开发的组件难以复用（虽然其后版本的Angular有了很大的改善）。在调用当时流行的前端框架后，我们在Vue与React之中选择了后者，辅以Ant Design框架，开发出了媲美Grafana的指标看版与便利的链路看板，并且在PC版本之外还开发了移动端的定制版本。我们亦更名了整个可观测性产品，从“ETrace”更新为“EMonitor”：不仅仅是链路可观测性系统，更是饿了么的一站式可观测性平台。

 

可观测性数据的整合：业务指标 + 应用链路 + 基础设施指标 + 中间件指标

 

在指标系统都迁移到LinDB后，我们在EMonitor上集成了“业务指标 + 应用链路 + 基础设施指标 + 中间件指标”的多层次的可观测性数据，让用户能在一处观测它的业务数据、排查业务故障、深挖底层基础设施的数据。

 

 

 

可观测性场景的整合：指标 + 链路 + 报警

 

在可观测性场景上，“指标看板”用于日常业务盯屏与宏观业务可观测性，“链路”作为应用排障与微观业务逻辑透出，“报警”则实现可观测性自动化，提高应急响应效率。

 

 

 

灵活的看板配置与业务大盘

 

在指标配置上，我们提供了多种图表类型--线图、面积图、散点图、柱状图、饼图、表格、文本等，以及丰富的自定义图表配置项，能满足用户不同数据展示需求。

 

在完成单个指标配置后，用户需要将若干个指标组合成所需的指标看板。用户在配置页面中，先选择待用的指标，再通过拖拽的方式，配置指标的布局便可实时预览布局效果。一个指标可被多个看板引用，指标的更新也会自动同步到所有看板上。为避免指标配置错误而引起歧义，我们也开发了“配置历史”的功能，指标、看板等配置都能回滚到任意历史版本上。

 

看板配置是静态图表组合，而业务大盘提供了生动的业务逻辑视图。用户可以根据他的业务场景，将指标配置整合成一张宏观的业务图。

 

 

第三方系统整合：变更系统 + SLS日志

 

因每条报警信息和指标配置信息都与AppId关联，那么在指标看板上可同步标记出报警的触发时间。同理，我们拉取了饿了么变更系统的应用变更数据，将其标注到对应AppId相关的指标上。在故障发生时，用户查看指标数据时，能根据有无变更记录、报警记录来初步判断故障原因。

 

 

饿了么的日志中间件能自动在记录日志时加上对应的ETrace的RequestId等链路信息。如此，用户查看SLS日志服务时，能反查到整条链路的RequestId；而EMonitor也在链路查看页面，拼接好了该应用所属的SLS链接信息，用户点击后能直达对应的SLS查看日志上下文。

 

 

使用场景的整合：桌面版 + 移动版

 

除提供桌面版的EMonitor外，我们还开发了移动版的EMonitor，它也提供了大部分可观测性系统的核心功能--业务指标、应用指标、报警信息等。移动版EMonitor能内嵌于钉钉之中，打通了用户认证机制，帮助用户随时随地掌握所有的可观测性信息。

 

 

 

为了极致的体验，精益求精

 

为了用户的极致使用体验，我们在EMonitor上各功能使用上细细打磨，这里仅举几个小例子：

 

1. 我们为极客开发者实现了若干键盘快捷键。例如，“V”键就能展开查看指标大图。
2. 图上多条曲线时，点击图例是默认单选，目的是让用户只看他关心的曲线。此外，若是“Ctrl+鼠标点击”则是将其加选择的曲线中。这个功能在一张图几十条曲线时，对比几个关键曲线时尤为有用。
3. 为了让色弱开发者更容易区分成功或失败的状态，我们针对性的调整了对应颜色的对比度。

 

成为饿了么一站式可观测性平台

 

EMonitor开发完成后，凭借优异的用户体验与产品集成度，很快在用户中普及开来。但是，EMonitor要成为饿了么的一站式可观测性平台，还剩下最后一战--NOC可观测性大屏。

 

NOC可观测性大屏替换

 

饿了么有一套完善的应急处理与保障团队，包括7*24值班的NOC（Network Operation Center）团队。在NOC的办公区域，有一整面墙上都是可观测性大屏，上面显示着饿了么的实时的各种业务曲线。下图为网上找的一张示例图，实际饿了么的NOC大屏比它更大、数据更多。

 

当时这个可观测大屏是将Grafana的指标看版投影上去。我们希望将NOC大屏也替换成EMonitor的看版。如前文所说，我们逐步将用户的Statsd指标数据转换成了LinDB指标，在NOC团队的协助下，一个一个将Grafana的可观测性指标“搬”到EMonitor上。此外，在原来白色主题的EMonitor之上，我们开发了黑色主题以适配投屏上墙的效果（白色背景投屏太刺眼）。

 

终于赶在2018年的双十一之前，EMonitor正式入驻NOC可观测大屏。在双十一当天，众多研发挤在NOC室看着墙上的EMonitor看版上的业务曲线不断飞涨，作为可观测性团队的一员，这份自豪之情由衷而生。经此一役，EMonitor真正成为了饿了么的“一站式可观测性平台”，Grafana、Statsd、InfluxDB等都成了过去时。

 

报警Watchdog 2.0

 

同样在EMonitor之前，亦有Statsd与InfluxDB对应的多套报警系统。用户若想要配置业务报警、链路报警、机器报警，需要辗转多个报警系统之间。各系统的报警的配置规则、触达体验亦是千差万别。Watchdog报警系统也面临着统一融合的挑战。

 

1. 在调研其他系统的报警规则实现后，Watchdog中仍以LinDB的指标作为元数据实现。
2. 针对其他报警系统的有显著区别的订阅模式，我们提出了"报警规则+一个规则多个订阅标签+一个用户订阅多个标签"的方式，完美迁移了几乎其他系统所有的报警规则与订阅关系。
3. 其他各系统在报警触达与触达内容上也略有不同。我们统一整合成“邮件+短信+钉钉+语音外呼”四种通知方式，并且提供可参数化的自定义Markdown模板，让用户可自己定时报警信息。

 

经过一番艰苦的报警配置与逻辑整合后，我们为用户“自动”迁移了上千个报警规则，并最终为他们提供了一个统一的报警平台。

 

 

 

报警，更精准的报警

 

外卖行业的业务特性是业务的午高峰与晚高峰，在业务曲线上便是两个波峰的形状。这样的可观测数据，自然难以简单使用阈值或比率来做判断。即使是根据历史同环比、3-Sigma、移动平均等规则，也难以适应饿了么的可观测性场景。因为，饿了么的业务曲线并非一成不变，它受促销、天气因素、区域、压测等因素影响。开发出一个自适应业务曲线变化的报警算法，势在必行。

 

 

我们经过调研既有规则，与饿了么的业务场景，推出了全新的“趋势”报警。简要算法如下：

 

1. 计算历史10天的指标数据中值作为基线。其中这10天都取工作日或非工作日。不取10天的均值而取中值是为了减少压测或机房流量切换造成的影响。
2. 根据二阶滑动平均算法，得到滑动平均值与当前实际值的差值。
3. 将基线与差值相加作为预测值。
4. 根据预测值的数量级，计算出波动的幅度（如上界与下界的数值）。
5. 若当前值不在预测值与波动幅度确定的上下界之中，则触发报警。

 

如上图所示，22点01分的实际值因不在上下界所限定的区域之中，会触发报警。但从后续趋势来看，该下降趋势符合预期，因此实际中还会辅以“偏离持续X分钟”来修正误报。（如该例中，可增加“持续3分钟才报警”的规则，该点的数据便不会报警）算法中部分参数为经验值，而其中波动的阈值参数用户可按照自己业务调整。用户针对具备业务特征的曲线，再也不用费心的去调整参数，配置上默认的“趋势”规则就可以覆盖大多数的可观测性场景，目前“趋势”报警在饿了么广泛运用。

 

智能可观测性：根因分析，大显神威

 

作为AIOPS中重要的一环，根因分析能帮助用户快速定位故障，缩短故障响应时间，减少故障造成的损失。2020年初，我们结合饿了么场景，攻坚克难，攻破“指标下钻”、“根因分析”两大难关，在EMonitor上成功落地。

 

根因分析最大的难点在于：包含复杂维度的指标数据难以找到真正影响数据波动的具体维度；孤立的指标数据也难以分析出应用上下游依赖引起的故障根因。例如，某个应用的异常指标突增，当前我们只能知道突增的异常名、机房维度的异常分布、机器维度的异常分布等，只有用户手工去点击异常指标看来链路之后，才能大致判断是哪个SOA方法/DB请求中的异常。继而用户根据异常链路的环节，去追溯上游或下游的应用，重复类似的排查过程，最后以人工经验判断出故障点。

 

因此，在“指标下钻”上，我们针对目标指标的曲线，细分成最精细的每个维度数据（指标group by待分析的tag维度），使用KMeans聚类找出故障数据的各维度的最大公共特征，依次计算找到最优的公共特征，如此便能找到曲线波动对应的维度信息。

 

 

 

其次，在链路数据计算时，我们就能将额外的上下游附加信息附加到对应的指标之中。如，可在异常指标中追加一个维度来记录产生异常的SOA方法名。这样在根据异常指标分析时，能直接定位到是这个应用的那个SOA方法抛出的异常，接下来“自动”分析是SOA下游故障还是自身故障（DB、Cache、GC等）。

 

 

 

 

在2020.3月在饿了么落地以来，在分析的上百例故障中，根因分析的准确率达到90%以上，显著缩短的故障排查的时间，帮助各业务向稳定性建设目标向前跨进了一大步。

 

 

 

4.0：继往开来，乘势而上

 

经过4、5年的发展，风云变幻但团队初心不改，为了让用户用好可观测性系统，EMonitor没有停下脚步，自我革新，希望让“天下没有难用的可观测性系统”。我们向集团的可观测性团队请教学习，结合本地生活自己的技术体系建设，力争百尺竿头更进一步，规划了以下的EMonitor 4.0的设计目标。

 

 

一、进行多租户化改造，保障核心数据的时延和可靠性

 

在本地生活的技术体系与阿里巴巴集团技术体系的不断深入的融合之中，单元化的部署环境以及对可观测性数据不同程度的可靠性要求，催生了“多租户化”的设计理念。我们可以根据应用类型、数据类型、来源等，将可观测性数据分流到不同的租户中，再针对性配置数据处理流程及分配处理能力，实现差异化的可靠性保障能力。

 

 

初步我们可以划分为两个集群--核心应用集群与非核心应用集合，根据在应用上标记的“应用等级”将其数据自动发送到对应集群中。两套集群在资源配置上优先侧重核心集群，并且完全物理隔离。此外通过配置开关可动态控制某个应用归属的租户，实现业务的柔性降级，避免当下偶尔因个别应用的不正确埋点方式会影响整体可观测可用性的问题。

 

未来可根据业务发展进一步发展出业务相关的租户，如到家业务集群、到店业务集群等。或者按照区域的划分，如弹内集群、弹外集群等。

 

二、打通集团弹内、弹外的可观测性数据，成为本地生活的一站式可观测性平台

 

目前本地生活很多业务领域已经迁入集团，在Trace链路可观测方面，虽然在本地生活上云的项目中，EMonitor已经通过中间件改造实现鹰眼TraceId在链路上的传递，并记录了EMonitor RequestId与鹰眼TraceId的映射关系。但EMonitor与鹰眼在协议上的天然隔阂仍使得用户需要在两个平台间跳转查看同一条Trace链路。因此，我们接下来的目标是与鹰眼团队合作，将鹰眼的Trace数据集成到EMonitor上，让用户能一站式的排查问题。

 

其次，本地生活上云后，众多中间件已迁移到云上中间件，如云Redis、云Kafka、云Zookeeper等。对应的可观测性数据也需要额外登陆到阿里云控制台去查看。云上中间的可观测性数据大多已存储到Prometheus之中，因此我们计划在完成Prometheus协议兼容后，就与云上中间件团队合作，将本地生活的云上可观测性数据集成到EMonitor上。

 

 

 

三、拥抱云原生，兼容Prometheus、OpenTelemetry等开源协议。

 

云原生带来的技术革新势不可挡，本地生活的绝大多数应用已迁移到集团的容器化平台--ASI上，对应带来的新的可观测环节也亟需补全。如，ASI上Prometheus协议的容器可观测性数据、Envoy等本地生活PaaS平台透出的可观测性数据与Trace数据等。

 

因此，我们计划在原先仅支持LinDB数据源的基础上，增加对Prometheus数据源的支持；扩展OpenTelemetry的otel-collector exporter实现，将Open Telemetry协议的Trace数据转换成EMonitor的Trace格式。如此便可补全云原生技术升级引起的可观测性数据缺失，并提供高度的适配性，满足本地生活的可观测性建设。

 

结语

 

纵观各大互联网公司的产品演进，技术产品的走向与命运都离不开公司业务的发展轨迹。我们饿了么的技术人是幸运的，能赶上这一波技术变革的大潮，能够发挥聪明才智，打磨出一些为用户津津乐道的技术产品。我们EMonitor可观测性团队也为能参与到这次技术变更中深感自豪，EMonitor能被大家认可， 离不开每位参与到饿了么可观测性体系建设的同伴，也感谢各位对可观测性系统提供帮助、支持、建议的伙伴！