解决方案:从0到1搭建高性能实时日志系统
优采云 发布时间: 2022-11-18 08:13解决方案:从0到1搭建高性能实时日志系统
建筑师(JiaGouX) 我们都是建筑师！
共创未来，你会来吗？
因公众号推送规则变更，请第一时间点击“在看”加“星”获取精彩技术分享
你是否经常遇到需要在线查看日志却又长时间联系不到用户上报日志的情况？或者你是否经常陷入存储空间不足导致日志无法写入的尴尬？本文介绍美团如何从0到1搭建高性能的终端实时日志系统，彻底解决了日志丢失和写满的问题。希望能给您带来一些帮助和启发。
2 设计实现
3 稳定性保证
4 成就
5 未来规划
1 背景 1.1 Logan简介 Logan是美团统一的终端日志服务。已支持移动APP、Web、小程序、IoT等多种环境，具备日志采集、存储、上传、查询、分析等能力。帮助用户定位研发问题，提升排查效率。同时，Logan也是业界较早开源的大型前端日志系统，具有写入性能高、安全性高、日志防丢失等优点。1.2 登录工作流程 为了方便读者更好的理解登录系统的工作原理，下图是一个简化的登录系统工作流程。主要分为以下几个部分：
图1 登录系统工作流程图 1.3 为什么需要实时日志？前文提到，这种“本地存储+主动上报”的模式虽然解决了大前端场景下基本的日志使用需求，但随着业务复杂度的不断提升，用户对日志的要求也越来越高。当前 Logan 架构存在的问题也越来越突出，主要体现在以下几个方面： 部分场景下日志的上报受限：因为用户在 Web 和小程序上的一般使用场景是离开后使用，当在线出现问题时，联系用户主动上报日志。整个处理周期长，可能会错过最佳故障排除时机。缺乏实时分析和告警能力：目前，缺乏实时分析和告警能力。用户多次提到，他们想监控线上的异常日志，当出现符合规则的异常日志时，接收告警信息。缺乏全链路跟踪能力：目前多端日志分散在各个系统中。研发人员在定位问题时需要手动关联日志，操作起来非常不方便。美团缺乏通用的全链路跟踪解决方案。针对以上痛点，我们提出了Logan实时日志的构建，旨在提供一个统一的、高性能的实时日志服务，解决美团不同业务系统想要登录云端的需求。这个阶段。1.4 什么是Logan实时日志？Logan实时日志是一个服务于手机App的实时日志解决方案，Web、小程序、IoT等终端场景。旨在提供高扩展性、高性能、高可靠性的实时日志服务，包括日志采集、上传、处理、消费、投递、查询和分析能力。
图2 洛根实时日志产品功能 图2 设计与实现 2.1 总体架构
图3 洛根实时日志的整体架构如上图所示。整体架构主要分为五个部分，分别是： 2.2 采集通用采集端架构，解决跨平台复用采集Device SDK用于设备端日志采集和需求在各种终端环境中实施。但由于终端和平台众多，技术栈和运行环境不一致，多终端的开发和维护成本会比较高。因此，我们设计了一套核心逻辑复用的通用采集端架构，具体的平台相关代码单独适配。我们推出了微信、MMP、Web、MRN终端，逻辑层代码已经完全复用。采集
图4 采集端SDK架构图 关键模块介绍：磁盘缓存+报表恢复防止日志丢失 为了方便读者更好的理解端日志采集流程，下面将介绍采集详细结束流程设计。采集端初始化API开始调用时，首先创建Logger、Encryptor、Storage等实例对象，并异步拉取环境配置文件。初始化完成后，首先检查是否有放置成功，但报告失败的日志，如果有，则立即恢复上传过程。正常调用写日志接口时，将原创日志加密后加入当前上报组。当报告事件（时间、条目数、导航等）发生时 )被触发，当前上报组的所有日志加入上报队列并上传。采集终端详细流程图如下：
图5 采集SDK流程图 2.3 数据接入层 对于实时日志系统，接入层需要满足以下要求： (1) 支持公网域名上报；(2) 支持高并发处理；(3) 实时性高，延时在分钟级；(4) 支持向Kafka消息队列投递数据。经过对比，美团统一的日志采集通道都满足以上需求，所以我们选择了统一的日志采集通道作为接入层。采集端SDK通过独立的公共域名上报日志后，采集通道将日志数据汇总后投递到指定的Kafka消息队列。如果读者公司没有类似的日志采集渠道，
图6 接入层流程图 2.4 数据处理层 在数据处理框架的技术选择上，我们考虑了传统架构（Java应用）、Storm架构、Flink架构三种方案。尺寸对比数据如下：
表1 技术选型对比表 总的来说，传统架构虽然成熟度和灵活性都比较好，但是在扩展性、容错性、性能等方面不能满足系统的要求，而Flink架构和Storm架构则相对优秀。扩展性和容错性，但是Flink架构在延迟和吞吐量方面表现更好，所以我们最终选择了Flink架构作为数据处理框架。Flink：业界领先的流式计算引擎，具有高吞吐、低延迟、高可靠、精准计算等特点。它对事件窗口的支持非常好，被业界许多公司认为是首选的流计算引擎。在日志处理流程的设计中，日志数据经过接入层处理后投递到summary topic，再通过Flink job的逻辑处理分发到下游。处理流程如下图所示：
图7 日志处理层流程图 汇总的日志数据处理和分发依赖于实时计算平台的实时运算能力。底层使用Flink数据处理引擎，主要负责日志数据的解析，日志内容的解密，拆分到下游。元数据解析：通过实时运算能力将原创日志数据解析为JSON对象数据。内容解密：对加密后的内容进行解密，其中使用非对称协商计算出对称加密密钥，然后进行解密。服务维度拆分：通过topic字段将日志分发到各个业务系统所属的topic中，实现业务日志的相互隔离。数据自定义处理：根据用户自定义的处理语法模板，实时消费处理从服务主题到自定义主题的数据。2.5 数据消费层
对于大多数用户来说，Logan实时日志提供的日志采集、处理、检索能力可以满足他们的大部分需求。但在与用户交流的过程中，我们发现还有一些更高层次的需求，比如指标监控、前后端链路对接、离线数据计算等。因此，我们将Logan标准化的日志统一下发到Kafka流处理平台，并提供一些通用的数据转换能力，方便用户按需接入不同的第三方系统。数据消费层设计如下图所示：
图 8 数据消费层设计图 数据消费层的一些典型应用场景： 网络全链路跟踪：现阶段前后端日志可能分布在不同的系统中，前端日志系统主要记录代码级日志、端到端日志等，后端日志系统记录链接关系、服务耗时等信息。通过罗根实时日志开放的数据消费能力，用户可以根据自己的需求拼接多端日志，实现网络全链路跟踪。指标聚合统计&告警：实时日志也是一种实时数据流，可以作为指标数据上报的载体。如果日志数据接入数据统计平台，可实现指标监测和报警。离线数据分析：如果某些需求场景需要对数据进行长期存储或离线分析，可以将数据导入Hive来实现。2.6 日志平台
日志平台的核心功能是为用户提供日志检索支持。日志平台提供用户ID、自定义标签、关键字等多种检索过滤方式。在底层日志存储架构的选择上，目前业界普遍采用Elasticsearch。考虑到计费和运维成本的关系，美团已经有了统一的框架可以使用，所以我们也选择了Elasticsearch架构。同时，我们也通过一个单独的接口层来支持其他的存储引擎。日志查询流程如下：
图9 日志查询流程设计图 Elasticsearch：是分布式开源搜索分析引擎，具有访问成本低、扩展性高、近实时等优点，更适合大数据的全文检索服务3 稳定性保障 3.1 核心监控 为了衡量终端实时日志系统的可用性，我们制定了以下核心SLA指标：
表2 核心SLA指标表 除了核心指标监控，我们还搭建了全程监控面板，涵盖了子端上报成功率、域名可用性、域名QPS、作业吞吐量等重要观察指标，以及聚合记录的平均数量。针对上报成功率、域名QPS、作业吞吐量等，配置一体化告警。当线上出现异常时，第一时间发现并处理。3.2 蓝绿发布
实时日志依赖于实时作业的处理和计算能力，但是实时作业的发布和部署目前还不能无缝对接，中间可能会出现真空。重启作业时，需要先停止原来的作业，然后再启动新的作业。如果遇到代码故障或者系统资源不足，就会导致作业启动失败，直接面临消息积压严重，数据延迟增加的问题，这是实时日志系统无法承受的。
Blue Green Deployment 是一种平滑过渡的发布模式。在蓝绿发布模型中，应用程序必须首先被分成两个相等的组，蓝色和绿色。蓝色组发布新产品代码并引入一点线上流量，绿色组继续运行旧产品代码。当新产品代码跑上线，观察没有问题时，逐渐引入更多的线上流量，直到所有流量都接入蓝组的新产品。因此，蓝绿发布可以保证整个系统的稳定性，可以在产品发布的早期发现问题并解决问题，保证其影响可控。
目前，美团对于实时运营有不同的蓝绿部署方案。由于洛根实时日志访问业务系统较多，数据量较大，经过综合考虑，我们决定实施适合当前系统的蓝绿方案。部署方案。为了保证系统的稳定性，在作业运行过程中又启动了一个相同的作业。当新作业运行没有问题时，旧作业被切换。蓝绿发布流程图如下：
图10 蓝绿发布流程图 使用蓝绿部署后，彻底解决了因资源不足或参数不正确导致上线失败的问题，平均部署切换时间保持在1分钟以内，基本避免了因资源不足或参数错误导致的日志消耗释放延迟问题。4 实施结果 洛根实时日志在建设初期就受到了各业务的广泛关注。程序、优选商户、餐饮SaaS等大体量业务。以下是业务系统接入的一些典型使用场景，供大家参考： 核心链路还原：道家C端小程序使用Logan实时记录程序核心链路的关键日志和异常日志。当网上有客户投诉出现问题时，可以查看实时日志，第一时间定位问题。项目上线后，客户投诉的平均定位时间从之前的10分钟缩短到3分钟以内，排查效率显着提升。内测阶段排查问题：某企业平台前端项目，由于2.0改版后发生了较大变化，所以在内测阶段使用Logan实时日志，增加更多调试日志，方便定位在线问题。项目上线后，不仅为用户每次排错上报日志节省了10-15分钟的时间，而且杜绝了因存储空间不足而无法获取用户日志的情况。日志数据分析：美团到店团队利用Logan实时日志分析前后端交互过程中的请求头、请求参数、响应体等数据是否符合规范规范。经过一个多月的试运行，一期版本上线后，覆盖300+前端页面，500+前端界面，共发现1000+规范问题。5 未来规划 龙光实时日志经过半年的建设和推广，系统基本能力已经完成，可以满足用户对实时日志的基本需求。但不支持日志数据的深度加工清洗、日志统计、告警等高层次需求。所以，
如果喜欢本文，请点击右上角分享文章到朋友圈
想了解学习的技术要点，欢迎给若飞留言安排分享
·结尾·
<p style="outline: 0px;max-width: 100%;color: rgb(0, 0, 0);font-family: Optima-Regular, Optima, PingFangSC-light, PingFangTC-light, "PingFang SC", Cambria, Cochin, Georgia, Times, "Times New Roman", serif;font-size: 16px;white-space: normal;background-color: rgb(255, 255, 255);box-sizing: border-box !important;overflow-wrap: break-word !important;">相关阅读：一张图看懂微服务架构路线<br style="outline: 0px;max-width: 100%;box-sizing: border-box !important;overflow-wrap: break-word !important;" />基于Spring Cloud的微服务架构分析微服务等于Spring Cloud？了解微服务架构和框架<br style="outline: 0px;max-width: 100%;box-sizing: border-box !important;overflow-wrap: break-word !important;" />如何构建基于 DDD 领域驱动的微服务？
小团队真的适合引入SpringCloud微服务吗？<br style="outline: 0px;max-width: 100%;box-sizing: border-box !important;overflow-wrap: break-word !important;" />
微服务之间的最佳调用方式<br style="outline: 0px;max-width: 100%;box-sizing: border-box !important;overflow-wrap: break-word !important;" />
微服务架构设计总结实践<br style="outline: 0px;max-width: 100%;box-sizing: border-box !important;overflow-wrap: break-word !important;" />
主流微服务全链路监控系统之战<br style="outline: 0px;max-width: 100%;box-sizing: border-box !important;overflow-wrap: break-word !important;" />微服务架构实施原理详解<br style="outline: 0px;max-width: 100%;box-sizing: border-box !important;overflow-wrap: break-word !important;" />微服务的简介和技术栈微服务场景下的数据一致性解决方案设计一个容错的微服务架构</p>
解决方案:WPJAM Basic 详细介绍：一键搞定 WordPress 功能屏蔽和增强优
WPJAM Basic插件的“优化设置”是WPJAM Basic的初始功能。可以说是我爱水煮鱼博客根据多年使用WordPress的经验整理出来的优化插件。
以上是该功能的完整视频介绍。当时的想法是为各种不用的功能，或者可能影响性能的功能提供开关，让你只需要一键即可完成WordPress定制开发。经过几年的发展，我的优化设置的功能分为功能屏蔽和增强优化两部分：
功能掩蔽
从上图可以清楚的看出，功能屏蔽就是让你屏蔽掉WordPress中一些不用的功能，也给出了一些简单的理由以及哪些场景可以屏蔽这个功能。当前支持阻止以下功能：
1.
文章 改版时会往Posts表中插入多条历史数据，导致Posts表冗余。建议屏蔽文章修改功能，提高数据库效率。
2.
Trackbacks协议被滥用，会在博客上产生大量垃圾信息。建议完全关闭 Trackbacks。
3.
WordPress使用图片渲染Emoji表情文字，但是渲染后的图片经常打不开，现在主流浏览器已经支持Emoji文字，建议屏蔽Emoji功能。
4.
WordPress会将一些纯文本字符转换成格式化的HTML实体，但是这些转换不适合中文环境，所以我们最好去掉这些字符转换。
5.
WordPress feeds主要用于阅读器，但现在使用阅读器的用户越来越少，feeds更多用于采集，造成不必要的资源消耗，建议关闭本站feeds。
6.
管理员每六个月重新登录一次后，就会看到站点管理员的邮箱验证界面。如果您认为没有必要，可以屏蔽邮箱验证。
7.
GDPR 是欧洲的通用数据保护条例。为了适应这个规律，WordPress在后台设置了很多隐私功能。如果您只在中国运营博客，您可以在后台删除与隐私相关的页面。
8.
WordPress更新服务器位于国外，经常打不开。建议关闭WordPress后台和自动更新功能，手动或通过SSH更新WordPress。
9.
Auto Embeds 协议允许您插入视频网站 或照片分享网站 的链接，链接中收录的视频或图片将自动显示。不过这个功能支持的网站都是国外的。建议禁用自动嵌入功能以加快页面解析。
10.
文章Embed 功能允许您将 WordPress文章 嵌入本站点或 WordPress 站点中的其他站点。如果不需要，可以屏蔽文章Embed 功能。
11.
WordPress 5.0发布带来的Gutenberg编辑器很酷，但是很多人不习惯，还是喜欢原来简单的编辑器，可以屏蔽Gutenberg。
12.
XML-RPC协议用于在客户端发布文章，如果只在后台发布，可以关闭XML-RPC功能。
增强优化
加速优化是清理WordPress产生的无用代码，加速优化一些WordPress资源。目前，它具有以下功能：
Google 字体非常易于使用和方便。很多WordPress主题也使用谷歌字体，但是谷歌在线字体在国内的速度不是很快，有时甚至打不开。这就是为什么 WordPress 在中国有时速度不够快的原因。
WPJAM Basic允许您选择第三方Google Font字体加速服务，也可以自定义输入加速服务地址：
详细介绍：
Gravatar部分CDN服务器在国内访问困难，存在无法显示头像的问题，而且WordPress后台或评论页面有时会默认加载Gravatar头像图片，可能会导致页面卡顿。
WPJAM Basic允许您选择第三方Gravatar图片加速服务，也可以自定义输入加速服务地址：
详细介绍：
WPJAM Basic允许您直接在后台设置Frame嵌入，避免点击劫持，增强网站的安全性：
详细介绍：
删除类别类别和 WordPress 页面的 URL。这两个页面的页面重写规则是否相同？那么我们可以直接使用页面重写规则来处理。
WPJAM Basic 还添加了一个附加选项。如果博客自定义了其他自定义分类模式，您可以选择将此功能应用于哪种分类模式：
详细介绍：
如果长时间上传的图片名称是1.jpg，那么上传一张图片就会导致数据库执行几十到上百条SQL查询。上传的时候要改一下图片的名字，图片的名字要多加一个时间戳，这样几乎可以保证图片名字不能重复：
详细介绍：
WordPress会在页面头部输出版权信息和其他服务发现代码。版权信息代码会让用户知道你当前运行的 WordPress 版本，服务发现代码会告诉用户你的博客支持哪些服务。
这些代码会在前台造成一些安全问题，最好一键删除。
详细介绍：
一般不建议在网站前台显示WordPress工具栏，可以一键移除。
详细介绍：
如果熟悉WordPress的用户，就会知道如何写出正确的WordPress模式，所以从效率的角度来说，没有必要在这个转换上浪费时间，也可以一键移除。
详细介绍：
在很多WordPress后台页面的右上角，比如后台文章列表页面，都会有“显示选项”和“帮助”两个按钮。一个用于显示和设置本页面的选项，另一个用于获取页面的帮助信息：
首先，这两个按钮在右上角。很多用户没有特别注意，以至于忘记操作，帮助文档对用户的帮助也不是很大。建议两者都去掉。
详细介绍：
最后，如果大家对使用WPJAM Basic有什么疑问，或者有什么功能需求，欢迎给我留言。
点击卡片关注“WordPress Jam”
每天分享 WordPress 技巧
