美团高性能终端实时日志系统建设实践
总第541篇
2022年 第058篇
1 背景
1.1 Logan 简介
Logan 是美团面向终端的统一日志服务，已支持移动端App、Web、小程序、IoT 等多端环境，具备日志采集、存储、上传、查询与分析等能力，帮助用户定位研发问题，提升故障排查效率。同时，Logan 也是业内开源较早的大前端日志系统，具有写入性能高、安全性高、日志防丢失等优点。
1.2 Logan 工作流程
为了方便读者更好地理解 Logan 系统是如何工作的，下图是简化后的 Logan 系统工作流程图。主要分为以下几个部分：
主动上报日志：终端设备在需要上报日志时，可以通过 HTTPS 接口主动上传日志到 Logan 接收服务，接收服务再把原始日志文件转存到对象存储平台。 日志解密与解析：当研发人员想要查看主动上报的日志时会触发日志下载与解析流程，原始加密日志从对象存储平台下载成功后进行解密、解析等操作，然后再投递到日志存储系统。 日志查询与检索：日志平台支持对单设备所有日志进行日志类型、标签、进程、关键字、时间等维度的筛选，同时也支持对一些特定类型的日志进行可视化展示。
1.3 为什么需要实时日志？
如前文所述，这套“本地存储+主动上报”的模式虽然解决了大前端场景下基础的日志使用需求，但是随着业务复杂度的不断增加，用户对日志的要求也越来越高，当前 Logan 架构存在的问题也变得越来越突出，主要体现在以下几个方面：
部分场景上报日志受限：由于在 Web 与小程序上用户一般的使用场景是用完即走，当线上出现问题时再联系用户主动上报日志，整个处理周期较长，有可能会错过最佳排查时间。 缺少实时分析和告警能力：当前缺少实时分析和告警的能力，用户曾多次提到过想要对线上异常日志进行监控，当有符合规则的异常日志出现时能收到告警信息。 缺少全链路追踪能力：当前多端的日志散落在各个系统中，研发人员在定位问题时需要手动去关联日志，操作起来很不方便，美团内部缺乏一个通用的全链路追踪方案。
1.4 Logan 实时日志是什么？
Logan 实时日志是服务于移动端 App、Web、小程序、IoT 等终端场景下的实时日志解决方案，旨在提供高扩展性、高性能、高可靠性的实时日志服务，包括日志采集、上传、加工、消费、投递、查询与分析等能力。
2 设计实现
2.1 整体架构
如上图所示，整体架构主要分为五个部分，它们分别是：
采集端：负责端上日志数据的采集、加密、压缩、聚合和上报等。 接入层：负责提供日志上报接口，接收日志上报数据，并将数据转发到数据处理层。 数据处理层：负责日志数据的解密、拆分、加工和清洗等。 数据消费层：负责日志数据的过滤、格式化、投递等。 日志平台：负责日志数据查询与分析、业务系统接入配置、统计与告警等。
2.2 采集端
通用采集端架构，解决跨平台复用
采集端SDK用于端侧日志收集，需要在多种终端环境落地，但是由于端和平台较多、技术栈和运行环境也不一致，多端开发和维护成本会比较高。因此，我们设计了一套核心逻辑复用的通用采集端架构，具体的平台依赖代码则单独进行适配。我们目前上线了微信、MMP、Web、MRN 端侧，逻辑层代码做到了完全复用。采集端架构设计图如下：
重点模块介绍：
配置管理：采集端初始化完成后，首先启动配置管理模块，拉取和刷新配置信息，包括上报限流配置、指标采样率、功能开关等，支持对关键配置进行灰度发布。 加密：所有记录的日志都使用 ECDH + AES 方案加密，确保日志信息不泄漏。Web 版加密模块使用浏览器原生加密 API 进行适配，可实现高性能异步加密，其他平台则使用纯 JS 实现。 存储管理：线上数据表明，由于页面关闭导致的日志丢失占比高达 1%，因此我们设计了日志落盘功能，当日志上传失败后会先缓存在本地磁盘，等到页面下一次启动时再重新恢复上传。 队列管理：需要发送的日志首先进行分组聚合，如果等待分组过多则需要丢弃一部分请求，防止在弱网环境或者日志堆积太多时造成内存持续上涨而影响用户。
落盘缓存 + 上报恢复，防止日志丢失
2.3 数据接入层
对于实时日志系统来讲，接入层需要满足以下几点要求：（1）支持公网上报域名；（2）支持高并发处理；（3）具备高实时性，延迟是分钟级；（4）支持投递数据到 Kafka 消息队列。
2.4 数据处理层
在数据处理框架的技术选型上，我们先后考虑了三种方案，分别是传统架构（Java 应用）、Storm 架构、Flink 架构，这三种方案在不同维度的对比数据如下：
Flink：业内领先的流式计算引擎，具有高吞吐、低延迟、高可靠和精确计算等优点，对事件窗口有很好的支持，被业内很多公司作为首选的流式计算引擎。
汇总后的日志数据处理和分发依赖于实时计算平台的实时作业能力，底层使用 Flink 数据处理引擎，主要负责日志数据的解析、日志内容的解密以及拆分到下游等。
元数据解析：通过实时作业能力完成原始日志数据解析为 JSON 对象数据。 内容解密：对加密内容进行解密，此处使用非对称协商计算出对称加密密钥，然后再进行解密。 服务维度拆分：通过 topic 字段把日志分发到各业务系统所属的 topic 里面，从而实现业务日志相互隔离。 数据自定义加工：根据用户自定义的加工语法模版，从服务 topic 实时消费并加工数据到自定义 topic 中。
2.5 数据消费层
数据消费层的一些典型的应用场景：
网络全链路追踪：现阶段前后端的日志可能分布在不同的系统中，前端日志系统记录的主要是代码级日志、端到端日志等，后端日志系统记录的是链路关系、服务耗时等信息。通过 Logan 实时日志开放的数据消费能力，用户可以根据自己的需求来串联多端日志，从而实现网络全链路追踪。 指标聚合统计&告警：实时日志也是一种实时的数据流，可以作为指标数据上报的载体，如果把日志数据对接到数据统计平台就能实现指标监控和告警了。 离线数据分析：如果在一些需求场景下需要对数据进行长期化保存或者离线分析，就可以将数据导入到 Hive 中来实现。
2.6 日志平台
Elasticsearch：是一个分布式的开源搜索和分析引擎，具有接入成本低、扩展性高和近实时性等优点，比较适合用来做大数据量的全文检索服务，例如日志查询等。
3 稳定性保障
3.1 核心监控
为了衡量终端实时日志系统的可用性，我们制定了以下核心 SLA 指标：
3.2 蓝绿发布
实时日志依赖于实时作业的处理计算能力，但是目前实时作业的发布和部署不能无缝衔接，中间可能存在真空的情况。当重启作业时，需要先停止原作业，再启动新的作业。如果遇到代码故障或系统资源不足等情况时则会导致作业启动失败，从而直接面临消息积压严重和数据延时升高的问题，这对于实时日志系统来说是不能忍受的。
蓝绿发布（Blue Green Deployment）是一种平滑过渡的发布模式。在蓝绿发布模式中，首先要将应用划分为对等的蓝绿两个分组，蓝组发布新产品代码并引入少许线上流量，绿组继续运行老产品代码。当新产品代码经线上运行观察没有问题后，开始逐步引入更多线上流量，直至所有流量都访问蓝组新产品。因此，蓝绿发布可以保证整体系统的稳定，在产品发布前期就可以发现并解决问题，以保证其影响面可控。
4 落地成果
核心链路还原：到家某 C 端小程序使用 Logan 实时日志记录程序核心链路中的关键日志与异常日志，当线上有客诉问题发生时，可以第一时间查看实时日志并定位问题。项目上线后，平均客诉定位时间从之前的 10 分钟减少到 3 分钟以内，排障效率有明显提升。 内测阶段排障：企业平台某前端项目由于 2.0 改版改动较大，于是使用 Logan 实时日志在内测阶段添加更多的调试日志，方便定位线上问题。项目上线后，每次排查问题除了节省用户上报日志时间 10-15 分钟，还杜绝了因为存储空间不足而拿不到用户日志的情况。 日志数据分析：美团到店某团队使用 Logan 实时日志分析前后端交互过程中的请求头、请求参数、响应体等数据是否符合标准化规范。经过一个多月时间的试运行，一期版本上线后共覆盖 300+ 前端页面和 500+ 前端接口，共计发现 1000+ 规范问题。
5 未来规划
Logan 实时日志经过半年的建设与推广，已经完成了系统基础能力的建设，能满足用户对于实时日志的基本诉求。但是对于日志数据深加工与清洗、日志统计与告警等高阶需求还不支持，因此为了更好地发挥日志价值，提升终端故障排查效率，Logan 实时日志有以下几个方面的规划：
完善功能：支持更多终端类型，建设日志加工与清洗、日志统计与告警、全链路追踪等功能。 提升性能：支持百万并发 QPS、日志上报成功率提升至 99.9% 等。 提升稳定性：建设限流熔断机制、应急响应与故障处理预案等。
6 本文作者
---------- END ----------
阅读更多