美团高性能终端实时日志系统建设实践
总第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 ----------
阅读更多