十年匠心定制 · 商业建站与技术教学双线并行 咨询热线:400-886-1026 service@lmnt.cn
ARTICLE DETAIL

资讯详情

深耕网站建设与运营推广的一线实战洞察。

前端日志乱丢又怕泄密,美团开源Logan真能搞定最后一公里?

前端日志乱丢又怕泄密,美团开源Logan真能搞定最后一公里? 最为前端开发而言, 最令人厌烦的便是日志方面的问题, 存在数据丢失情况, 存在传输不上的状况, 并且还会被他人偷看。美团开源了一个名为Logan的事物, 称其能够将这些麻烦统一处理妥当。我针对其展开了一番研究, 发觉它的确具备一定优势, 今日便跟大家讲述一番。提及痛点, 当下存在这样的情况, 一个App进行日志记录时, 存在一套适用于某系统的日志记录方式, 还有一套针对iOS系统的, 另外H5也有一套, 它们各自为政, 到最后进行分析时, 数据却无法相互匹配。更为令人头疼不已的是, 当用户网络状况欠佳的时候, 日志信息会直接丢失不见, 花费大量时间去查找, 都找寻不到其中缘由。除此之外, 还存在隐私方面的问题, 日志里面有着大量敏感信息, 一旦传播出去, 将会引发极其严重的后果。Logan的想法是, 将所有在端上呈现的日志进行统一管理, 它不单单只是一个SDK, 还附带后端以及分析平台, 如同一条流水线一般。在端上, 首先会存储到本地, 接着进行加密压缩, 待网络状况良好时再进行传输, 如此一来便不会丢失, 并且它对好几种日志类型都予以支持, 崩溃、用户行为、网络请求皆能够记录, 采用的是同一个格式。它的架构被划分成五块, 端上收集存储那块, 采用的是本地文件加上缓存, 具备支持断点续传, 能够进行自动压缩加密的特性, 例如当你手机处于没有信号的状态时, 日志会先被予留存, 待信号恢复之后会自动予以补传, 绝不会丢失任何一条。它还依据日志级别进行了等级划分,像是DEBUG、INFO、ERROR, 你能够仅仅采集ERROR级别的, 以此节省流量以及性能。关于多平台SDK这一部分, iOS、Web均采用同一套接口, 然而底层针对各个平台进行过优化, 像是iOS所用的, Web所用的, 插件借助原生通道实现桥接, Dart层调用显得颇为统一, 我曾尝试过, 可以发现接入并非太过复杂。后端范畴中的那一部分内容, 日志实施上传行为之后进入消息队列, 比如说Kafka, 之后又存入HDFS或者ES之中, 而后开展建索引的活动。它具备能够处理海量并发情况的能力, 还拥有去重功能, 并且能够实现自动补全上下文的操作。比如说你自A页面跳转至B页面, 日志能够自动进行关联, 无需手动去拼凑。有一个做分析的平台, 它专门进行可视化操作, 能做日志检索、链路追踪、崩溃分析以及报表生成。与传统的ELK相比, 它更侧重于前端场景, 配置起来要比之简单许多。你无需去了解ES的查询语法, 只需点几下, 就能看到用户的操作路径。Logan所支持的日志行为存在七种, 其中, CAT端到端日志, 能够将前后端调用链予以打通, 进而定位分布式问题埋点日志则负责记录用户点击、曝光以及页面跳转等情况, 支持事件聚合用户行为日志更为细致, 诸如鼠标移动、输入框内容等, 能够还原用户的每一步相应操作代码级日志是在开发阶段由开发者自行添加的, 带有行号以及堆栈信息网络内部日志用于记录HTTP、DNS的耗时以及状态码, 异常能够被自动捕获Push日志可查看推送到达率、点击率以及延迟情况。Crash崩溃日志记载了原生端的崩溃堆栈, 也记载了Web端的崩溃堆栈, 还记载了内存快照以及环境信息。技术亮点存在一些数量。其一是“先存后传”的策略, 该策略能够避免在网络状况不佳时丢失日志。然而, 存储所占空间以及上传的实时性需要达成平衡, Logan的延迟上传机制更契合诸如地铁之类、电梯之内的离线场景特点。其二是端到端加密以及签名, 采用AES加密并结合HMAC签名, 以此防止出现篡改或者泄露情况。与之形成对比的是, 它在传输时默认不进行加密, Logan更适宜于金融以及电商这类敏感场景。其三是日志分级以及采样率控制, 其支持依据级别进行动态调整, 从而降低性能方面的开销。但是采样策略需要依据业务情况来定, 采用一刀切的方式可能会遗漏 日志点最终导致关键信息未被保留。在第四方面, 存在着跨平台统一日志格式的情况, 其运用序列化方式, 使得多端解析整齐划一, 自研格式相较于JSON而言, 在带宽节省方面更具优势, 然而却需要定制解析器。相较于竞品而言, Logan具备的优势表现为日志类型实现了全方位地覆盖, 具备较高的安全性, 且部署方面能够得到有效控制。然而其局限性也较为显著, 需要自行搭建后端, 学习的难度较大。使用起来较为简便, 不过是收费的, 有关隐私的可控性较差。功能较为单一, 仅仅针对异常状况。自行构建ELK的话维护工作极为复杂, 日志格式也需要自己去进行定义。所以说Logan适合于中大型团队, 需要具备后端方面的人力进行支持。该日志系统在美团内部已使用多年, 每日处理的日志数量可达百亿条 , 并且端上存储被控制在10MB范围以内。举个实际发生的场景例子 , 混合App产生的所有崩溃日志 , 能够与原生端作统一上报 , 进而解决了Web崩溃现象下日志数据丢失的问题。同时 , 该日志系统配合埋点日志完成了用户行为路径进行还原 , 由此涵盖查看功能得以实现对操作 、接口 、渲染之间全链路的查看分析。在推行灰度发布期间 , 借助日志分级能够对新版产生的异常情况加速进行定位 , 并可实现自动告警。当前开源社区有5.6K Star, 其文档主要是中文, Issue活跃度处于一般状态。插件已然发布, 然而版本迭代较为缓慢。未来存在支持部署的可能性, 能够简化运维工作并或接入标准, 进而增强可观测性。另外还有AI辅助分析功能, 可自动识别异常模式。首先来讲讲我个人的观点, 日志并非仅仅是记录下来就可以的事情, 它实际上属于一种系统工程, 其中涉及的端、管以及云等各个方面都必须要配合得当才行。Logan证实了开源并不等同于无需进行运维操作, 它比较适合那些具备技术储备的团队。在当今数据安全愈发重要的形势下, 端上加密以及权限控制应当成为一种标配, 而Logan在这方面所做的表现相当不错。要是你当前正在遭受日志问题的折磨, 那么不妨尝试一下, 不过要做好自行搭建后端以及定制化的准备工作。
返回列表