关于日志:美团高性能终端实时日志系统建设实践

你是否常常遇到线上须要日志排查问题但迟迟分割不上用户上报日志的状况？或者是否常常陷入因为存储空间有余而导致日志写不进去的囧境？本文介绍了美团是如何从 0 到 1 搭建高性能终端实时日志零碎，从此彻底解决日志失落和写满问题的。心愿能为大家带来一些帮忙和启发。

1 背景

1.1 Logan 简介

Logan 是美团面向终端的对立日志服务，已反对挪动端 App、Web、小程序、IoT 等多端环境，具备日志采集、存储、上传、查问与剖析等能力，帮忙用户定位研发问题，晋升故障排查效率。同时，Logan 也是业内开源较早的大前端日志零碎，具备写入性能高、安全性高、日志防失落等长处。

1.2 Logan 工作流程

为了不便读者更好地了解 Logan 零碎是如何工作的，下图是简化后的 Logan 零碎工作流程图。次要分为以下几个局部：

• 被动上报日志：终端设备在须要上报日志时，能够通过 HTTPS 接口被动上传日志到 Logan 接管服务，接管服务再把原始日志文件转存到对象存储平台。
• 日志解密与解析：当研发人员想要查看被动上报的日志时会触发日志下载与解析流程，原始加密日志从对象存储平台下载胜利后进行解密、解析等操作，而后再投递到日志存储系统。
• 日志查问与检索：日志平台反对对单设施所有日志进行日志类型、标签、过程、关键字、工夫等维度的筛选，同时也反对对一些特定类型的日志进行可视化展现。

1.3 为什么须要实时日志？

如前文所述，这套“本地存储 + 被动上报”的模式尽管解决了大前端场景下根底的日志应用需要，然而随着业务复杂度的一直减少，用户对日志的要求也越来越高，以后 Logan 架构存在的问题也变得越来越突出，次要体现在以下几个方面：

1. 局部场景上报日志受限：因为在 Web 与小程序上用户个别的应用场景是用完即走，当线上呈现问题时再分割用户被动上报日志，整个解决周期较长，有可能会错过最佳排查工夫。
2. 短少实时剖析和告警能力：以后短少实时剖析和告警的能力，用户曾多次提到过想要对线上异样日志进行监控，当有合乎规定的异样日志呈现时能收到告警信息。
3. 短少全链路追踪能力：以后多端的日志散落在各个系统中，研发人员在定位问题时须要手动去关联日志，操作起来很不不便，美团外部不足一个通用的全链路追踪计划。

针对以上痛点问题，咱们提出了建设 Logan 实时日志，旨在提供对立的、高性能的实时日志服务，以解决美团现阶段不同业务零碎想要日志上云的需要。

1.4 Logan 实时日志是什么？

Logan 实时日志是服务于挪动端 App、Web、小程序、IoT 等终端场景下的实时日志解决方案，旨在提供高扩展性、高性能、高可靠性的实时日志服务，包含日志采集、上传、加工、生产、投递、查问与剖析等能力。

2 设计实现

2.1 整体架构

如上图所示，整体架构次要分为五个局部，它们别离是：

• 采集端：负责端上日志数据的采集、加密、压缩、聚合和上报等。
• 接入层：负责提供日志上报接口，接管日志上报数据，并将数据转发到数据处理层。
• 数据处理层：负责日志数据的解密、拆分、加工和荡涤等。
• 数据消费层：负责日志数据的过滤、格式化、投递等。
• 日志平台：负责日志数据查问与剖析、业务零碎接入配置、统计与告警等。

2.2 采集端

通用采集端架构，解决跨平台复用

采集端 SDK 用于端侧日志收集，须要在多种终端环境落地，然而因为端和平台较多、技术栈和运行环境也不统一，多端开发和保护老本会比拟高。因而，咱们设计了一套外围逻辑复用的通用采集端架构，具体的平台依赖代码则独自进行适配。咱们目前上线了微信、MMP、Web、MRN 端侧，逻辑层代码做到了齐全复用。采集端架构设计图如下：

重点模块介绍：

• 配置管理：采集端初始化实现后，首先启动配置管理模块，拉取和刷新配置信息，包含上报限流配置、指标采样率、性能开关等，反对对要害配置进行灰度公布。
• 加密：所有记录的日志都应用 ECDH + AES 计划加密，确保日志信息不透露。Web 版加密模块应用浏览器原生加密 API 进行适配，可实现高性能异步加密，其余平台则应用纯 JS 实现。
• 存储管理：线上数据表明，因为页面敞开导致的日志失落占比高达 1%，因而咱们设计了日志落盘性能，当日志上传失败后会先缓存在本地磁盘，等到页面下一次启动时再从新复原上传。
• 队列治理：须要发送的日志首先进行分组聚合，如果期待分组过多则须要抛弃一部分申请，避免在弱网环境或者日志沉积太多时造成内存继续上涨而影响用户。

落盘缓存 + 上报复原，避免日志失落

为了不便读者更好地了解端上日志采集过程，上面将具体介绍下采集端流程设计。当采集端初始化 API 开始调用时，先创立 Logger、Encryptor、Storage 等实例对象，并异步拉取环境配置文件。初始化实现之后，先查看是否有胜利落盘，然而上报失败的日志，如果有的话立刻开始复原上传流程。当失常调用写日志 API 时，原始日志被加密后退出以后上报组，等到有上报事件（工夫、条数、导航等）触发时，以后上报组内的所有日志被退出上报队列并开始上传。采集端具体流程图如下：

2.3 数据接入层

对于实时日志零碎来讲，接入层须要满足以下几点要求：（1）反对公网上报域名；（2）反对高并发解决；（3）具备高实时性，提早是分钟级；（4）反对投递数据到 Kafka 音讯队列。

通过比照，美团内的对立日志收集通道均满足以上需要，因而咱们选用了对立日志收集通道作为接入层。采集端 SDK 通过独立的公网域名上报日志后，收集通道将日志数据汇总好并投递到指定的 Kafka 音讯队列。如果读者公司没有相似的日志收集通道，那么能够参考以下流程搭建实时日志零碎接入层。

2.4 数据处理层

在数据处理框架的技术选型上，咱们先后思考了三种计划，别离是传统架构（Java 利用）、Storm 架构、Flink 架构，这三种计划在不同维度的比照数据如下：

<center> 表 1 技术选型比照表 </center>

综合来看，尽管传统架构有比拟好的成熟度与灵活性，然而在扩展性、容错性以及性能上均不能满足零碎要求，而 Flink 架构与 Storm 架构都有比拟优良的扩展性与容错性，然而 Flink 架构在提早与吞吐量上体现要更好，因而咱们最终抉择了应用 Flink 架构作为数据处理框架。

Flink：业内当先的流式计算引擎，具备高吞吐、低提早、高牢靠和准确计算等长处，对事件窗口有很好的反对，被业内很多公司作为首选的流式计算引擎。

在日志解决流程设计上，日志数据通过接入层解决后被投递到汇总 topic 外面，而后再通过 Flink 作业的逻辑解决后散发到上游。解决流程如下图所示：

汇总后的日志数据处理和散发依赖于实时计算平台的实时作业能力，底层应用 Flink 数据处理引擎，次要负责日志数据的解析、日志内容的解密以及拆分到上游等。

1. 元数据解析：通过实时作业能力实现原始日志数据解析为 JSON 对象数据。
2. 内容解密：对加密内容进行解密，此处应用非对称协商计算出对称加密密钥，而后再进行解密。
3. 服务维度拆分：通过 topic 字段把日志散发到各业务零碎所属的 topic 外面，从而实现业务日志互相隔离。
4. 数据自定义加工：依据用户自定义的加工语法模版，从服务 topic 实时生产并加工数据到自定义 topic 中。

2.5 数据消费层

对大部分用户来说 Logan 实时日志提供的日志采集、加工、检索能力曾经能满足大部分需要。然而在与用户沟通过程中咱们发现还有一些更高阶的需要，比方指标监控、前后端链路串联、离线数据计算等。于是咱们将 Logan 标准化后的日志对立投递到 Kafka 流解决平台，并提供一些通用的数据转换能力，不便用户按需接入到不同的第三方零碎。数据消费层设计如下图所示：

数据消费层的一些典型的利用场景：

1. 网络全链路追踪：现阶段前后端的日志可能散布在不同的零碎中，前端日志零碎记录的次要是代码级日志、端到端日志等，后端日志零碎记录的是链路关系、服务耗时等信息。通过 Logan 实时日志凋谢的数据生产能力，用户能够依据本人的需要来串联多端日志，从而实现网络全链路追踪。
2. 指标聚合统计 & 告警：实时日志也是一种实时的数据流，能够作为指标数据上报的载体，如果把日志数据对接到数据统计平台就能实现指标监控和告警了。
3. 离线数据分析：如果在一些需要场景下须要对数据进行长期化保留或者离线剖析，就能够将数据导入到 Hive 中来实现。

2.6 日志平台

日志平台的外围性能是为用户提供日志检索反对，日志平台提供了用户标识、自定义标签、关键字等多种检索过滤形式。在日志底层存储架构的抉择上，目前业界宽泛应用的是 Elasticsearch，思考到计费与运维老本的关系，美团外部曾经有一套对立的框架能够应用，所以咱们也选用了 Elasticsearch 架构。同时，咱们也反对通过独自的接口层适配其余存储引擎，日志查问流程如下：

Elasticsearch：是一个分布式的开源搜寻和剖析引擎，具备接入成本低、扩展性高和近实时性等长处，比拟适宜用来做大数据量的全文检索服务，例如日志查问等。

3 稳定性保障

3.1 外围监控

为了掂量终端实时日志零碎的可用性，咱们制订了以下外围 SLA 指标：

<center> 表 2 外围 SLA 指标表格 </center>

除了外围指标监控之外，咱们还建设了全流程监控大盘，笼罩了分端上报成功率、域名可用性、域名 QPS、作业吞吐量、均匀聚合条数等重要观测指标，并且针对上报成功率、域名 QPS、作业吞吐量等配置了兜底告警，当线上有异样时能够第一工夫发现并进行解决。

3.2 蓝绿公布

实时日志依赖于实时作业的解决计算能力，然而目前实时作业的公布和部署不能无缝连接，两头可能存在真空的状况。当重启作业时，须要先进行原作业，再启动新的作业。如果遇到代码故障或系统资源有余等状况时则会导致作业启动失败，从而间接面临音讯积压重大和数据延时升高的问题，这对于实时日志零碎来说是不能忍耐的。

蓝绿公布（Blue Green Deployment）是一种平滑过渡的公布模式。在蓝绿公布模式中，首先要将利用划分为对等的蓝绿两个分组，蓝组公布新产品代码并引入少许线上流量，绿组持续运行老产品代码。当新产品代码经线上运行察看没有问题后，开始逐渐引入更多线上流量，直至所有流量都拜访蓝组新产品。因而，蓝绿公布能够保障整体零碎的稳固，在产品公布后期就能够发现并解决问题，以保障其影响面可控。

目前美团已有的实时作业蓝绿部署计划各不相同，因为 Logan 实时日志接入业务零碎较多，且数据量较大，通过综合考量后，咱们决定本人实现一套适宜以后零碎的蓝绿部署计划。为了保证系统的稳定性，在作业运行过程中，启动另外一个雷同的作业，当新作业运行没有问题后，再实现新老作业切换。蓝绿公布流程图如下：

应用蓝绿部署后，彻底解决了因为资源有余或参数不对导致的上线失败问题，均匀部署切换耗时也放弃在 1 分钟以内，根本防止了因公布带来的日志生产提早问题。

4 落地成绩

Logan 实时日志在建设初期就受到了各个业务的宽泛关注，截止到 2022 年第 3 季度，Logan 实时日志接入并上线的业务零碎数量已多达二十余个，其中包含美团小程序、优选商家、餐饮 SaaS 等大体量业务。上面是一些业务零碎接入的典型应用场景，供大家参考：

1. 外围链路还原：到家某 C 端小程序应用 Logan 实时日志记录程序外围链路中的要害日志与异样日志，当线上有客诉问题产生时，能够第一工夫查看实时日志并定位问题。我的项目上线后，均匀客诉定位工夫从之前的 10 分钟缩小到 3 分钟以内，排障效率有显著晋升。
2. 内测阶段排障：企业平台某前端我的项目因为 2.0 改版改变较大，于是应用 Logan 实时日志在内测阶段增加更多的调试日志，不便定位线上问题。我的项目上线后，每次排查问题除了节俭用户上报日志工夫 10-15 分钟，还杜绝了因为存储空间有余而拿不到用户日志的状况。
3. 日志数据分析：美团到店某团队应用 Logan 实时日志剖析前后端交互过程中的申请头、申请参数、响应体等数据是否合乎标准化标准。通过一个多月工夫的试运行，一期版本上线后共笼罩 300+ 前端页面和 500+ 前端接口，共计发现 1000+ 标准问题。

5 将来布局

Logan 实时日志通过半年的建设与推广，曾经实现了零碎根底能力的建设，能满足用户对于实时日志的根本诉求。然而对于日志数据深加工与荡涤、日志统计与告警等高阶需要还不反对，因而为了更好地施展日志价值，晋升终端故障排查效率，Logan 实时日志有以下几个方面的布局：

• 欠缺性能：反对更多终端类型，建设日志加工与荡涤、日志统计与告警、全链路追踪等性能。
• 晋升性能：反对百万并发 QPS、日志上报成功率晋升至 99.9% 等。
• 晋升稳定性：建设限流熔断机制、应急响应与故障解决预案等。

6 本文作者

洪坤、徐博、陈成、少星等，均来自美团 - 根底技术部 - 前端技术核心。

7 招聘信息

美团根底技术部 - 前端技术核心，诚招高级、资深技术专家，Base 上海、北京。咱们致力于为美团海量业务建设高性能、高可用、高体验的前端根底技术服务，涵盖终端通信、终端平安、资源托管、可观测性、研发协同、设计工具、低代码、Node 基建等技术畛域，欢送有趣味的同学投送简历至：[email protected]。

浏览美团技术团队更多技术文章合集

前端 | 算法 | 后端 | 数据 | 平安 | 运维 | iOS | Android | 测试

| 在公众号菜单栏对话框回复【2021 年货】、【2020 年货】、【2019 年货】、【2018 年货】、【2017 年货】等关键词，可查看美团技术团队历年技术文章合集。

| 本文系美团技术团队出品，著作权归属美团。欢送出于分享和交换等非商业目标转载或应用本文内容，敬请注明“内容转载自美团技术团队”。本文未经许可，不得进行商业性转载或者应用。任何商用行为，请发送邮件至 [email protected] 申请受权。