京东零售云里边移动端日志那块，怎么回捞和探索实践的一些心得分享

基于京东零售技术团队公开的技术博客、分享会内容整理）

最开始的时候,我们京东零售云的移动端团队遇到一个挺头疼的问题，就是线上偶尔会出现一些比较“诡异”的用户反馈，比如某个按钮点了没反应，或者页面加载突然特别慢，但在我们开发人员自己的手机上，还有测试同学的手机上，怎么复现都复现不出来，这种问题就像幽灵一样，你知道它存在，但就是抓不住，那时候，我们主要依赖用户上报的日志，但用户手机上的日志存储空间是有限的，不可能把所有过程都记下来，而且为了省流量和电量，日志级别通常设得比较高，很多详细的调试信息在发现问题时早就被覆盖掉了，这就导致我们经常是“巧妇难为无米之炊”，没有足够的一手信息，排查起来非常困难，效率极低。

后来,我们下定决心要解决这个问题，核心思路就是“日志回捞”，这个名字听起来可能有点技术化，但说白了，就是一种“按需取日志”的机制，我们不再被动地等用户上报那些有限的常规日志，而是具备了主动出击的能力，当线上监控系统发现某个用户的App行为出现异常（比如连续崩溃、某个接口错误率突然升高），或者我们接到客服转来的特定用户反馈时，我们就可以通过一个后台指令，精准地对这个或这批用户的App“喊话”，告诉它：“请你把从现在开始，往后一段时间内（比如未来半小时）的、更详细的日志（包括平时不记录的调试信息）保存下来，并在下次网络条件好的时候打包发给我们。”

这个想法很好,但具体做起来，有不少坑要踩，第一个心得就是，你不能影响用户的正常使用，这是我们的一条铁律，所以我们设计的回捞机制一定是“非侵入式”的，指令的下发和日志的上传，都是在后台静默进行的，不会弹窗打扰用户，我们对回捞的触发条件做了非常谨慎的控制，不会漫无目的地大面积下发指令，避免给用户设备和我们的服务器带来不必要的负担。

第二个比较深的体会是,日志的“全链路”追踪非常重要，光知道App前端报错了还不够，我们得清楚这个错误背后，它调用了哪些接口、接口的响应时间和返回内容是什么、甚至是在哪个具体的页面和操作流程中发生的，这就好比破案，需要完整的证据链，所以我们在打日志的时候，会为每一个重要的用户会话或操作流程生成一个唯一的“TraceID”，这个ID会像一根线一样，串起前端用户操作、网络请求、后端服务处理等各个环节的日志，当我们通过回捞拿到前端日志时，通过这个TraceID，就能非常方便地在后端的海量日志里，把同一个事件的所有相关记录都捞出来，一下子就能看到问题的全貌，这个实践对我们排查那种“前端表现异常，但根因在后端”的问题帮助巨大。

第三个实践中的关键点,是日志的“分级和动态开关”，如果为了排查问题，就让用户的App记录所有细节，那日志文件会瞬间膨胀，既占空间又耗性能，我们的做法是，日志有不同的详细等级，比如错误、警告、信息、调试等级别，在正常情况下，App只记录错误、警告等关键信息，而回捞指令里，可以指定将日志级别临时调整为最详细的“调试”级别，并且可以只针对特定的模块或者功能进行详细日志记录，这样既能抓到我们需要的“罪证”，又做到了精准和高效。

说到探索,我们不仅仅把日志回捞用在事后排查问题上，还把它用在了“灰度发布”和“新功能验证”上，这是一个挺有意思的延伸，当我们推一个新的功能给一小部分用户试用时（也就是灰度发布），我们会同时对这部分用户开启详细的日志回捞能力（当然会提前告知用户并获得同意，如果是实验性质的话），这样，新功能在真实用户环境下的每一步操作、每一个性能指标，我们都能看得一清二楚，一旦有苗头不对，就能立即发现并回滚，大大降低了新功能上线带来的风险。

所有这些回捞上来的日志,不能只是一堆杂乱无章的文本文件，我们建设了一个统一的日志分析平台，日志上传后，会自动进行解析、入库，并和我们现有的监控、告警系统打通，研发同学可以通过这个平台，很方便地根据用户ID、设备型号、App版本、时间范围、错误类型等各种条件进行筛选和查询，快速定位问题，平台还会自动做一些聚合分析，比如发现某种类型的错误在今天突然增加了，就会主动告警，让我们能从“被动救火”转向“主动防火”。

在京东零售云移动端日志这块,我们的核心心得就是变被动为主动，通过构建一套灵活、精准、对用户无感的日志回捞体系，并结合全链路追踪和强大的分析平台，我们终于把线上那些“幽灵”问题装进了笼子里，极大地提升了问题排查的效率和线上质量的掌控力，这整个过程，就是一个不断踩坑、不断优化、不断拓展应用场景的实践历程。