关于jquery:闲鱼如何建设技术舆情治理体系-多图多代码

30次阅读

共计 6060 个字符，预计需要花费 16 分钟才能阅读完成。

简介：从日志、监控、性能检测几个方面建设了有日志可查、有数据可依的排查体系

现状和问题

闲鱼的舆情治理，依靠阿里团体的设施建设，有以下能力：

  • 解体异样、性能在线聚合查问；
  • 本地日志：TLog；
  • 在线日志：埋点日志（t+1）和用户行为日志（门路和申请）

但在应答舆情治理方面仍存在较多的问题：

  • 有相当一部分闪退、黑屏、卡死舆情无 Crash 或 ANR 日志；
  • 技术舆情中的业务问题定位艰难；业务问题如图片视频上传失败、内容显示异样、无奈退出、服务器谬误等；日志内容缺失：大部分业务日志被写入控制台，而不是本地日志或在线日志；个别重要业务应用埋点日志，但仍可能存在内容有余和 t+1 不及时问题。
  • 本地日志定位问题能力无限本地 TLog 日志有较为具体的团体二方 SDK 日志，但缺失设施根底信息、业务日志、用户行为日志等未知异样问题，如视频绿屏等，无控制台 logcat 日志日志标准不欠缺，日志查看效率低
  • 本地日志回捞艰难用户被动反馈时，没有触发本地日志上报闲鱼属于交易 App，用户不会长时间在线，在线命令推送成功率低命令推送在后盾没有缓存机制
  • 反馈问题和线上理论状况存在偏差闲鱼反馈入口较深，相比闲鱼上亿用户基数，反馈占比低，存在线上有问题但无反馈的状况

舆情治理计划整体设计

基于现状问题，从新梳理和补充的舆情治理体系如下图：

基于现状问题，从新梳理和补充的舆情治理体系如下图：

线上舆情问题治理体系

上面会重点开展讲述的内容：

  • 如何晋升本地日志定位能力
  • 补充线上卡顿监测能力
  • 补充被动发现问题能力

晋升本地日志定位能力

本地控制台日志补充

治理后期，大量业务日志进入了控制台日志，即使治理后将大量日志转入 tlog 日志，仍有局部日志流入控制台，如 Android Maven 引入独立模块和 Flutter 插件包模块。此外，局部未知异样问题，如视频绿屏、黑屏等，logcat 日志也提供了定位的可能性。

Android Log 模块提供了多种日志缓存类型，见 Android logging，可通过 logcat 命令获取对应类型的日志。这里，咱们在用户反馈的时候，别离将 LOG_ID_MAIN、LOG_ID_EVENTS 和 LOG_ID_CRASH 类型 logcat 读取并写入到本地文件，而后将 logcat 日志同 tlog 文件一起打包通过 AUS 上传至 OSS。

// LOG_ID_MAIN 主应用程序 log，-t 设置日志下限 20000
adb logcat -d -v threadtime -t 20000

// LOG_ID_EVENTS 零碎事件信息
adb logcat -d -b events -v threadtime -t 6666

// LOG_ID_CRASH 应用程序 crash 日志
adb logcat -d -b crash -v threadtime -t 6666

logcat.txt 内容

本地日志回捞能力

后面提到，因为在线命令推送成功率低且后盾无命令缓存机制，所以闲鱼 App 本地日志回捞艰难。为解决日志难以获取问题，舆情治理体系中设计了多种日志回捞策略，见下图所示。

本地日志回捞策略

本地日志下载查看流程

  • 为晋升用户被动反馈触发的日志上传成功率，应用 AUS 上传日志打包文件至 OSS 平台，同时将 url 写入反馈内容（打包和上传若超出 5 秒则无奈写入反馈内容）和阿里云 SLS 实时日志平台；
  • 为晋升研发下载本地日志的效率，应用 TLog SDK 上传至 TLog 平台，其中 50% 以上能上传胜利。

线上卡顿 /ANR 检测能力

线上用户反馈 ANR 并给出截图证实，因为没有卡顿日志，难以定位问题。

线上用户反馈黑屏，无无效日志难以定位问题

页面卡死的另一种体现

技术计划现状

在闲鱼 App 的混合工程场景，依靠 Emas 平台已实现 iOS 端卡顿检测，Flutter 端卡顿检测计划查看 Flutter 卡顿问题的监控与思考，这节次要讲述 Android 端线上卡顿 /ANR 检测。

在线下场景，Android 端卡顿 /ANR 检测伎俩曾经很成熟，普通卡顿检测计划有 BlockCanary，ANR 检测可通过 adb bugreport 查看 traces.txt 文件失去。然而在 线上环境，以上卡顿检测计划就存在肯定问题。

traces.txt 文件权限问题

在线上场景，为了监听辨认是否产生 ANR 以及读取 ANR 内容，APP 须要监听 traces.txt 文件变动，并尝试读取 traces.txt 文件内容。监听文件的计划，在 Android 6.0 及当前存在权限问题，大部分场景无奈检测到 ANR

  • 无法访问 /data/anr/traces.txt 文件
  • 无奈读取无效零碎属性 dalvik.vm.stack-trace-file

如以下代码执行在红米手机 Android 11 上运行，mSystemTraceFilePath 为 “”，mSystemTraceFile 的门路为 “/”

File mSystemTraceFile;

...
this.mSystemTraceFilePath = "/data/anr/traces.txt";
this.mSystemTraceFile = new File(this.mSystemTraceFilePath);
if (!this.mSystemTraceFile.exists()) {String propSystemTraceFilePath = SystemPropertiesUtils.get("dalvik.vm.stack-trace-file");
    ...
    this.mSystemTraceFile = new File(propSystemTraceFilePath);
    ...
}
...

BlockCanary 检测原理和性能问题

外围原理

BlockCanary 检测 500ms 卡顿

BlockCanary 的外围原理是，设置 UI 线程的 Looper.mLogging 字段，主线程每次解决音讯均会执行 print 办法。

public void start() {if (!mMonitorStarted) {
        mMonitorStarted = true;
        Looper.getMainLooper().setMessageLogging(mBlockCanaryCore.monitor);
    }
}

BlockCanary.java

public void setMessageLogging(@Nullable Printer printer) {mLogging = printer;}
   
public static void loop() {
    ...
    for (;;) {
        ...
        // This must be in a local variable, in case a UI event sets the logger
        final Printer logging = me.mLogging;
        if (logging != null) {
            logging.println(">>>>> Dispatching to" + msg.target + " " +
                    msg.callback + ":" + msg.what);
        }
        ...
    }
}

Looper.java

在 print 办法中时，触发 StackSampler 工作，即勾销上一次异步线程提早工作，从新触发一次提早工作，延迟时间为 BlockThreshold * 0.8f（假如要检测 500ms 以上的卡顿堆栈，则延迟时间为 400ms）。若 UI Looper 工作产生卡顿（>BlockThreshold），则提早工作被执行，且在卡顿期间的获取主线程堆栈信息，之后在下一次 print 办法被执行的时候，若确认产生卡顿，则可把主线程堆栈信息当做卡顿堆栈记录上报。

@Override
public void println(String x) {
    ...
    if (!mPrintingStarted) {mStartTimestamp = System.currentTimeMillis();
        mStartThreadTimestamp = SystemClock.currentThreadTimeMillis();
        mPrintingStarted = true;
        startDump();} else {final long endTime = System.currentTimeMillis();
        mPrintingStarted = false;
        if (isBlock(endTime)) {notifyBlockEvent(endTime);
        }
        stopDump();}
}

LooperMonitor.java

性能问题

在线上环境，大部分场景下并不会产生卡顿，但卡顿检测 SDK 会始终执行。能够发现 app 每一帧工夫 (16.6ms)，UI Looper 中的工作会执行屡次，最终产生大量的有效 字符串拼接操作 和大量小对象碎片。特地的，在线上低端机或者 cpu 负载较高的场景下，app 性能会因而降级，影响用户体感。

logging.println(">>>>> Dispatching to" + msg.target + " " +
                    msg.callback + ":" + msg.what);

卡顿检测计划

方案设计

针对 traces.txt 读取权限问题，可通过检测主线程 5s 卡顿当做 anr。针对 BlockCanary 线上应用的性能问题，为升高提早工作勾销和触发频率，同时防止字符串对象频繁创立问题，必须放弃 Looper.mLogging 的计划。从新思考为什么能够通过设置 Looper.mLogging 检测卡顿？其满足 2 个条件：

  • 若主线程办法执行产生卡顿，则 Looper Task 执行时长变长
  • 可通过 Looper.mLogging 监听每个 Task 执行时长

闲鱼线上应用 Android 帧回调代替 Looper Task 计划，同时满足以上 2 个条件：

  • 若主线程办法执行产生卡顿，则帧回调距离时长变长
  • 可通过注册帧回调监听每帧时长

此外，为防止 BlockCanary 计划提早工作触发和勾销的频率过高的问题，仅在帧回调处记录时间戳，不再勾销提早工作，但在提早工作执行时判断是否产生卡顿，同时记录主线程堆栈。

假如 500ms 以上为卡顿，整体计划流程图如下：

  • 无卡顿场景
  • 卡顿场景
  • 仅在频繁触发的帧回调处，记录时间戳，无性能耗费
  • 防止提早工作触发和勾销的频率过高的问题，500ms（卡顿阈值）最多执行 2 次提早工作
  • 不再勾销提早工作
  • 在工作执行时，判断以后工夫和上一帧工夫戳时间差。仅在产生卡登时，dump 主线程堆栈

定义 5s 以上卡顿为 ANR，为检测 ANR，同样通过 500ms 卡顿检测，并做卡顿堆栈聚合，当间断产生卡顿大于 5s 且堆栈信息不变，则认为产生 ANR。产生 ANR 时，记录以后设施 CPU 负载等信息。

检测成果

闲鱼首页卡片点击事件中成心制作 500ms 和 5s 卡顿查看卡顿检测后果。

// CardView61801.java

private void doOnClick(String redirectUrl, Map<String, String> trackParams) {if (null == mCardBean) return;

    try {Thread.sleep(500);
        // Thread.sleep(5000);
    } catch (Exception e) {e.printStackTrace();
    }
    ...
}

查看检测后果

  • Sleep 500ms
  • Sleep 5s

小结

以上是闲鱼 Android 线上卡顿检测计划，线上曾经运行超过 3 个版本，通过日志可发现用户反馈卡死、无反馈、闪退、黑屏等景象都有可能是 ANR 造成。整体计划有以下特点：

  • 线上卡顿检测无性能问题
  • 以 5s 以上卡顿当做 ANR
  • 相比 BlockCanary Looper Task 在 0.8* 卡顿阈值 时获取卡顿堆栈，本计划 500ms 卡顿检测有更高概率获取谬误堆栈。但通过间断卡顿堆栈比对，可确保 5s 卡顿堆栈的准确性。而 500ms 卡顿通过线上统计晋升准确性若业务须要，必须晋升 500ms 单次卡顿堆栈准确率，可简略批改计划：判断大于 250ms 获取一次卡顿堆栈，2 次连续雷同卡顿堆栈且卡登时长大于 500ms 作为最终卡顿判断

被动发现问题能力

因为闲鱼 App 反馈入口较深，因而相比上亿用户而言，每日技术舆情反馈量占比偏低，以此可知技术舆情反馈量并不能精确反馈线上品质状况。为此，咱们通过监控埋点构建线上要害舆情问题和根底性能大盘，同时通过监控大盘被动发现线上重点待解决问题，减速线上舆情收敛速度和品质晋升，流程图如下所示。

被动发现问题流程图

监控大盘

被动发现问题大盘示例

  • 业务舆情问题大盘
  • 通过统计一段时间的舆情问题，失去要害舆情问题，以此增加监控埋点并构建线上报表。通过大盘数据失去线上问题发生量和重要归因，通过重点解决排名前几的归因，达到舆情问题疾速收敛的目标。
  • 根底问题
  • 除了 Crash、Flutter 异样、性能等线上大盘，咱们构建了 5s 卡顿监控、网络申请失败、慢申请、谬误 toast 等根底监控大盘。

监控问题定位

基于大盘发现了问题，须要获取对应日志来定位问题，但问题对应的用户很可能并不会反馈舆情或反馈内容不是该问题，为此咱们构建了实时日志查问以及本地日志批量回捞能力。

实时日志查问平台

自建舆情追踪平台

针对要害监控问题，客户端减少对应的 SLS 实时日志，在自建舆情追踪平台获取用户的在线日志。平台反对用户名和工夫查问，同时反对用户行为、用户异样、舆情日志类型的组合查问。

本地日志批量回捞能力

在线日志难以避免日志内容有余的问题，如根底日志、其余要害模块日志等，然而单个用户的本地日志回捞胜利很低（起因见上文内容），为此构建舆情日志回捞平台，通过批量回捞的形式确保能获取到舆情问题某个用户的本地全量日志。

  • 输出舆情 IssueName 查问用户 id
  • 批量回捞后果查问

总结和瞻望

通过治理，整体线上技术类舆情占比从 10.5% 升高至 4.7%；基于被动发现问题和解决重点问题，每日上传图片失败数从 10W+ 次升高至小于 7K+ 次，其余数据不再列举。

初步建设的闲鱼舆情治理体系如下所示：

  • 日志类型：本地日志和在线日志；
  • 在线日志：实时在线 SLS 日志，用户行为日志，埋点 (t+1) 日志，高可用 SDK 日志（解体异样、白屏、性能）；
  • 日志查问：提供日志标准和日志过滤文档提供查问效率；
  • 日志内容：根底日志和业务日志；
  • 根底日志：logcat 日志，卡顿 /ANR 日志，高可用 SDK 日志（crash、异样等），设施信息、账号信息等；
  • 日志回捞：反馈时被动上传（TLog 平台和 OSS 平台），在线命令回捞（含 TLog 平台回捞，自建音讯通道回捞）；
  • 问题发现：用户反馈问题和被动发现问题
  • 反馈入口：一般客服反馈和灰度截屏反馈特地的，MIUI 零碎下的截屏事件可监听播送 miui.intent.TAKE_SCREENSHOT

此外，将来仍有很大的演进空间如下：

  • 日志可视化日志语义化形容展现用户行为、内存、CPU、流量等可视化闲鱼用户本地日志手动解析后的内存可视化举例
  • 日志智能解析要害日志和历史问题关联造成知识库
  • 要害日志反向回捞用户日志相似被动发现问题场景中的回捞能力，可依据配置下发或其余要害在线日志回捞用户日志
  • 日志关联聚合查问基于用户和工夫，聚合服务端、前端、客户端日志，聚合多种在线和本地日志。

作者：闲鱼技术——云从
原文链接
本文为阿里云原创内容，未经容许不得转载

正文完
jquery
发表至： jquery
2021-03-10
 0
关于jquery:低版本jQuery升级到高版本的jQuery
关于jquery:Query类操作是什么意思
关于jquery:戏说云栖如果这些名人参加云栖大会
关于jquery:云原生体系下的技海浮沉与理论探索