转转B2C一站式服务告警治理的背后-51CTO.COM

1 为什么写这篇文章

转转B2C技术部主要负责商详、商列等BFF层核心页面业务，单接口甚至需要开线程池并行调用二十多个依赖服务，因此依赖的服务以及执行线程池的稳定性也就成为了B2C关注的重点。

那么站在技术视角看调用链路，会发现几个特点：

CPU使用率高，线程池大量使用
RPC调用多，稳定性指望依赖的服务方
业务调用链路较长，无法精细化控制

本文就针对如何快速定位常见问题，以及后续日志的进一步治理计划来进行讲解。

2 现状与问题

目前转转各个排查问题的工具是统一开放给公司的所有业务使用的，因此每次告警，都需借助统一的平台如服务治理平台、Grafana、Log日志平台等工具进行排查，不完全贴合B2C常见问题排查场景，比如上游调用异常、超时等问题。

B2C技术部告警定位问题会遇到如下几个问题：

线上常见告警问题无法快速识别

线上内置告警无法一眼定位出问题，需要根据业务新增新的Promtheus PromQL展示调用服务超时、异常榜单。

公司统一平台无法快捷跳转

发生紧急问题时，只能从收藏夹中选中公司各个公用平台，然后手动输入服务名称、时间范围、粘贴查询语句等，效率较低。

户外环境下无法定位常见问题

办公设备不在身边时，一旦发生告警，无法像在公司一样方便的打开各个平台进行问题定位。

3 解决方案

上面提出了几个问题，那怎么进行监控治理呢。比如，怎么快速识别出问题的类型？怎么快捷跳转对应的平台？以及在户外如何进行问题定位呢？针对这些问题提出了如下解决方案。

总架构设计图如下

如图可拆分为四部分，执行步骤为：规范梳理及调整 -> 日志收集 -> 日志告警及定位 -> 告警感知

3.1 规范梳理及调整

日志打印规范化：梳理项目不合理日志打印输出。

日志打印级别优化：如输入密码为空日志级别由error降为warn级别。
该打的日志没打：领券、预约、秒杀成功等关键节点操作需要输出日志。
不该的打日志别打：移除掉定位问题无关的大日志，如打印整个商详返回值。

类型与阈值规范：规范异常抛出类型及调整业务系统告警阈值。

无效错误堆栈日志屏蔽：如timeoutException异常的堆栈日志打印无效，可直接省略。
告警阈值过于固定：根据各业务调整阈值，达到99.99%系统稳定性告警阈值标准即可。

3.2 基于Apollo自定义日志Agent拦截(日志收集)

日志收集

Apollo配置中心控制异常+日志打印维度配置。
根据配置屏蔽无用Exception，并上报到Promtheus，以Grafana报表展示。
通过JavaAgent根据配置的业务、类、方法级别拦截日志打印，伪代码如下。

public MethodVisitor visitMethod(int access, String name, String descriptor, String signature, String[] exceptions) {
            MethodVisitor methodVisitor = super.visitMethod(access, name, descriptor, signature, exceptions);
            if (STR_V.equals(descriptor) && infoLevel.contains(name)) {
                //  此处省略。。拦截日志处理逻辑----------
                return new LogMethodInsnVisitor(methodVisitor, className, name);
            } else {
                return methodVisitor;
            }
        }