作者：闲鱼技术-迎墨

神探产品定位

神探是一款面向服务端稳定性问题自动定位并辅助快速解决故障的线上排查工具。
软件工程领域存在一个共识：维护代码所花费的时间要远多于写代码。而整个代码维护过程中，最惊心动魄与扣人心弦的部分，莫过于问题排查，线上问题持续发生，带来的问题，一方面是大量时间投入和繁复操作，另一方面是低效率解决问题导致的用户体验和公司利益的持续受损。无论从业务稳定性还是业务的快速开发迭代，都需要提高底层效率，提高问题定位能力，使开发人员注入更多的精力在开发和业务本身。

神探目标

神探围绕四大指标解决线上故障问题，分别为：

• 准 - 定位准确率不亚于开发人员。
• 快 - 系统目标定位结果要早于监控发现。
• 简单 - 沉淀出从问题发现到定位结果之间，最短的链路，尽可能缩减定位时间和定位成本。
• 自动化 - 神探系统的开发旨在解放人力，全程不需要开发人员参与。自动定位到具体链路环节，打通告警、预警、故障链路

竞品分析

为响应故障报警最快解决，集团内部很多团队都在做故障定位系统，这里简单比较常见的解法。
1、基于专家经验的决策树模式
目前最成熟，做的最多的方案是基于专家经验，对以往排查路径进行沉淀收敛，以决策树模型进行上钻下钻分析。但这种模型具有先天的缺陷，即专家经验的真实性、时效性、体系化等方面的欠考量。神探系统区别于传统决策树模型，将专家经验沉淀转化为一种分析范式，通用性、扩展性方面表现良好。
2、基于监控平台优化/基于报警信息
部分团队故障定位是基于监控平台做优化，调整阈值使之成为高敏感度监控平台，带来的问题是大量无效报警。基于报警信息的模式本质上，发现故障要晚于监控报警，神探可做到故障定位早于报警信息，对系统安全方面，具有更高价值。**
3、基于机器学习的根因下钻算法
这种方案，特色在于上下游调用以及因果关系影响是通过严谨的逻辑关系证明而来，比常见的推测法更具说服力，因此，这种方案准确率高达95%以上。其因果关系下钻分析使用KMeans等机器学习算法给出最佳波动组合。这种方案模型复杂，必须依靠强大的分布式时序数据库来保证系统的快速查询能力，且采用全链路数据成本高。神探也是基于逻辑证明去推测因果关系，因果逻辑算法部分与此系统互为补充。

神探整体架构

神探实现原理

线上环境中，全面了解应用运行状况，需要：
1、掌控上下级调用关系链路中所有入口服务的【耗时、状态】
2、掌控每个入口服务关联资源的【耗时、状态】
针对以上问题排查思路并非无迹可寻，其排查思路和手段可以沉淀出一套经验模型。将故障简单归结为【慢调用】和【异常】，根据日常排查思路可以总结出以下分析范式：

上图范式模型，使用完备的数据埋点体系，可以很清晰的做到：准确界定慢调用/异常；生成上下游调用链路；本身和下游准确界定是谁的问题；下游异常时准确区分线程池满、超时、未捕获异常。
除此之外，系统设计模型还满足以下两点：

1. 模型覆盖线上复杂多变的场景。包括流量波动、发布波动、机器问题、代码异常、依赖异常等；区分可容忍异常和不可容忍异常；兼容异常一直上报导致请求直接失败退出的场景；兼容异常在底层被吞掉，请求不会失败，但会导致业务异常的场景。
2. 模型是易于扩展的。可以实时根据要求将经验添加到模型之中

整体结构图

本系统做到从告警/预警/故障->定位->快速处理这样一套完美闭环，自上而下分为数据采集、实时计算、实时分析、聚合展示四大模块。神探采用决策树模型来进行故障分析定位，通过对排查思路的归纳总结将决策树体系化成一套通用范式。

模型抽象-基于决策树模型

模型基于决策树机制实现，整个系统中模型原子节点抽象为：

• 监控对象：即关注的监控实体抽象，例如，某个服务、一个主机、数据库、jvm实例、中间件服务、日志、网络等，监控对象之间存在关联关系。
• 指标：指监控对象本身携带的监控特征，例如，系统负载（Load）、CPU利用率、内存使用率、网络I/O、磁盘利用率、服务是否超时、日志特点。
• 规则：指构建决策逻辑的最小单位，由指标和逻辑组成。
• 知识库：指专家经验的总结沉淀，即系统最终异常的根因分析。

决策树推理过程可以总结为：

• 监控数据实时采集聚合，存储统计数据到TSDB
• 根据要定位的对象找到决策树根节点
• 判断当前决策树节点对应规则是否满足
• 判断规则游走路径，下钻到下一个决策节点
• 如果是知识库则输出

具体推理过程自下而上，可以由采集数据拿到具体异常监控指标值，最终通过上下游调用关系，聚合成拓扑链路，直观显示故障位置，如下图所示。

范式异常情况扩展

【多方佐证分析】
正常情况下，这两个耗时由客户端建立请求、服务端发出响应和客户端接受响应的具体耗时简化而来，可现实项目中，存在许多异常情况，很多场景下我们不能完全取到这三个指标，我们将采用多方佐证来辅助给出定位结果。
场景举例：

• 多方佐证是针对数据丢失来校准诊断，数据丢失情况经过系统罗列，也可以总结出一套分析模型，以tddl为例，当DB库出现问题，会有部分等待排队耗时埋点丢失，服务端耗时丢失时，下钻分析当前节点有没有明确的客户端耗时，若存在大量客户端耗时高事件，则判断是当前节点问题，若没有，则判断是依赖方问题。

当前效果显示

钉钉链路打通，告警链路实时定位

1. 神探目前针对日常故障/问题排查，定位时间可以达到5s以内。
2. 与告警以及预警平台进行打通，做到监控和预警出来的故障、异常能够秒级定位到根因。
3. 神探具备下游依赖、DB、容器（CPU、LOAD、线程池满）、单机异常、多原因综合定位，满足日常绝大部分故障、日常定位需求。

实际案例

XXXX年X月XX日**引起的故障

XXXX年X月XX日全站交易下跌超过20%，闲鱼也受影响。报警群“闲鱼-发布”，“闲鱼-留言”等多接口下跌，神探系统秒级定位异常导致闲鱼多个服务受到影响，继而第一时间对进行了降级。
发现路径(最短路径): 打通告警信息,告警群出告警后,可直接点击卡片,打开诊断页面

日常单机问题排查，解决人工排查难区分单机还是集群问题

搜索单机问题(11.15..这台机器)导致首页接口异常,直接定位到

故障定位结果提供快恢预案，保驾故障快速恢复

系统展望优化

神探系统目前已经稳定运行，主要聚焦服务稳定性相关问题定位，仍然有许多场景未覆盖，要实现问题定位->隔离->降级->快速恢复完整闭环，还需要更完备的底层数据建设、完备的事件抽象、以及将事件关联起来的知识图谱。

1. 数据成本控制

   • 问题描述：海量数据问题——线上埋点数据可达80G/分钟，多租户模式匹配后带来成本指数增长问题，数据成本问题优化需要保证埋点定位准确度不变的前提下，优化数据存储。

   • 数据清洗方案：【粗过滤】基于自定义的阈值过滤规则

     • 神探支持粗过滤场景。自定义阈值过滤规则是基于某些中间件服务调用，例如，RPC、MQ、数据库访问、缓存等，可以明确规定出响应时间 > x ms =>异常响应的场景，可以高效率进行数据过滤。

   • 数据清洗方案：【自动化阈值】基于自动化阈值维护的清洗规则

     • 自动化阈值维护是根据前N-1个正常阈值，经过严谨的逻辑计算得来。维护规则根据数据规模有所不同，N取太大，则对第N个阈值影响微乎其微，所以N的选择根据系统数据规模得出。
     • 自动化阈值理论上计算强依赖于前段时间正常的响应波动，目前采用动态均值算法，定义如下：

  - 为了兼容异常情况导致的部分数据丢失，该系统采取动态阈值自动校正规则，当系统检测到存在部分响应数据明显低于动态阈值，将会自动拉平、校正当前阈值。
  - 【**二阶平滑算法**】神探2.0将继续优化数据清洗方案，保证故障定位准确率的同时，不让数据成为系统发展瓶颈，优化自动化阈值算法。均值算法对于短期预测表现较好，但对长期效果表现不友好，我们不仅要考虑历史均值，还要考虑阈值的历史变化趋势，对较久历史数据进行加权削弱，充分利用基线变化趋势，综合比较，神探2.0拟采用二阶指数平滑算法，预测下一阶段相关指标阈值，使阈值基于历史长短时间记忆计算得来。二阶指数平滑算法，降低阈值与实际数值差距，比目前方案中，自动校正动态阈值，适用性更强。

1. 拓扑补全

   • 异常和故障本质上属于小概率事件，某些场景下，异常信息数量有限，如果不能保证异常链路数据的完整性，分析就会中断。神探利用知识图谱模块，对数据缺失链路进行经验补全，提高系统可用性。

   • 举例—特定场景拓扑补全

     1. SYS_BUSY

        • 抛出系统繁忙异常的场景，由人工经验可知，90%以上是由线程池满所导致，对这部分可进行人工经验补充，加入知识图谱。

     2. 【正常业务拦截拓扑补全】

        • 业务本身会设置诸多拦截规则，比如图片违规屏蔽等，对于这部分的异常信息定位，进行节点信息补充。
        • 目前，神探系统最终根因定位，依据拓扑链路结果，如下图，GC导致线程池满，引起ServiceD异常，最终导致应用服务异常。根因定位的选取标准为拓扑链路中出错频次最高的链路——GC。这样的选举标准覆盖绝大部分异常链路。神探2.0将会把目光放至极少部分规则未命中的case。会继续优化正常业务拦截拓扑链路，明确区分出业务拦截，到底是干扰项？还是故障真实根因节点？进一步提高神探系统准确性。

1. 系统拓展至端

   • 神探系统接下来会接入终端数据，包括移动端APP，H5，PC端等，将系统拓展至端可以覆盖更全面的异常场景，例如，流量下跌/流量突涨，神探使用上钻分析，将现有拓扑进一步上钻补全，构造完整链路，端上流量汇集到故障入口，根据端上数据监控，可以明确给出：

     • 具体哪个端流量波动？
     • 端上哪个接口抖动？是否进行限流？
     • APP/PC端流量波动原因？是大促？还是异常？
     • 流量波动对本系统的整体影响链路？

2. 多租户扩展

   • 神探未来将会接入除闲鱼外的其他应用，做到多租户扩展，发展成为适用性强的一款故障定位工具。

3. 丰富DB指标

   • 神探目前针对DB抖动，只能定位到IP以及请求方IP，覆盖指标不够丰富。未来我们会接入新的数据源，接入DB库的监控信息，丰富定位指标，降低之前慢调用因信息不全而多方佐证带来的一定概率误差。DB库监控数据接入，将有效关联数据打通串联，快速应用到神探。DB监控数据的接入将丰富我们指标监控：

     • 可定位到故障机房
     • 可定位到故障IP，请求方IP，对数据丢失链路进行佐证定位
     • 可定位到故障具体数据库
     • 可定位到故障具体表