在闲鱼服务器上处理复杂问题的系统。告警-定位-快速处理吓人，但每天花大量时间处理问题也能吓人；另一方面，快速解决故障至关重要。那么目前排除故障最大的障碍是什么？我们认为有几个原因：大量警告信息。链接的复杂性。调查过程很复杂。靠经验。但是，实际工作中的调查过程并非无迹可寻，其调查思路和方法可以沉淀出一套实证模型。沉淀路径下面是对我的订单列表的简单抽象，它的执行过程就是先拿到我买的订单列表。订单列表中使用了卖家、商品、店铺信息服务，每一个服务都关联了一次请求中提供的服务对应的主机信息。以常见的在线服务超时为例。上图中因为127.123.12.12机器异常导致商品服务超时，进而导致我的订单列表服务超时。根据日常排查思路，可以归纳出如下分析范式：上述分析范式看似简单明了，但首先面临以下问题：如何准确定义超时/异常。如何生成上下游调用链接。自己和下游，如何判断谁的问题（timeout&exception）。下游异常时，如何区分超时/线程池满/未知异常。上述问题本质上是底层数据埋点问题。好在阿里集团完备的数据建设，使得这些问题都可以找到很好的解决方案。有了底层的数据支持和上层抽象出的一套分析模型，完全可以设计和实现一个完全自动化的问题定位系统。系统架构我们认为，这样一个自动问题定位系统必须满足四个目标，这也是整个系统的难点。准确（定位准确率不亚于开发者）即使定位结果与真实原因有细微的出入，也会影响开发者对系统本身的信心，所以准确是一个大前提。快速（定位结果早于监控发现）监控是发现问题最重要的手段。只有当监控发现问题，才能第一时间定位结果，才有真正的实用价值。简单性（从问题发现到定位结果的最短环节）在线问题/故障定位耗时长，操作路径越简单越有价值。在没有开发人员参与的情况下自动化整个过程。围绕这四个目标，我们实现了如上的完整定位系统，实现了报警->定位->快速处理的完整闭环。从下到上分为4个模块。下面说说各个模块解决的问题和难点。数据采集??数据采集模块主要负责埋点数据的采集和上报，需要解决两个问题：海量数据。在线埋点数据无时无刻不在产生，其数据量可达80G/分钟。采集延迟。数据采集??作为整个系统追求的主要目标，需要满足低时延。可扩展的指标。随着模型的不断演进和完善，需要灵活增加采集指标（cpu/gc/gc耗时/线程数等）。SLS+自定义插件库，用于实现在线流量埋点数据的采集和上报。SLS是阿里云针对日志数据开发的一站式服务。其生命周期管理（TTL）和极低的存储成本可以很好地解决海量数据带来的成本问题。实时计算实时计算以数据采集的输出为输入，负责对数据进行一轮预处理，包括链接数据的关联（请求有唯一标识，根据标识分组）、数据清理（??仅选择所需数据）和事件通知。计算延迟。从获取数据到最终过滤输出，都需要尽可能地压缩计算延迟，以提高整个系统的时效性。多个数据源的协作。数据来自底层不同的数据源。它们之前对应不同的到达时间，所以需要解决数据等待问题。数据清洗。需要通过一定的策略进行一轮数据清洗，过滤掉真正有效的数据，以减少计算量和后续的存储成本。存储成本。虽然经过一轮数据清洗后，还是会随着数据量的累积而线性增长。实时分析收到事件通知后，根据实时计算产生的有效数据进行自动分析，输出问题的输出路径图。需要解决：实时拓扑与离线拓扑。实时拓扑对埋点数据有要求，需要能够实时还原调用链路，但这取决于采集数据的完整性。离线拓扑是离线生成的，不依赖采集数据的完整性，但不能准确反映当前拓扑。最后，选择了实时拓扑恢复方法来保证准确性。数据丢失。实时计算虽然解决了数据协同等待的问题，但是并不能完全解决数据丢失的问题（数据延迟过大/埋点数据丢失），对于延迟和丢失的数据需要不同的处理策略。分析准确度。影响准确率的因素很多，主要包括数据的完整性和分析模型的完整性。聚合展示根据时间窗口对问题发生路径进行实时聚合，还原问题发生时的场景。监控、告警、诊断环节互联互通，最大限度缩短了从问题发现到结果展示的操作路径。实时聚合与查询时聚合。查询的聚合性能较差但非常灵活（数据可以根据不同的条件进行聚合），而实时聚合牺牲了灵活性来保证查询性能。这里我们选择保证查询性能。并发问题。使用实时聚合首先要解决的是并发写入（在线集群修改同一个接口的聚合结果）。最后将图拆解成原子键，利用redies的线程安全特性保证在线集群的写并发。存储成本与总体性能。为了解决并发问题，我们利用redis的线程安全特性来解决，但是它带来的问题之一就是成本问题。经过分析会发现，聚合操作一般只跨越2到5个窗口，超过之后聚合结果就会趋于稳定。所以可以考虑持久化聚合结果。效果系统上线以来，经受住了实践的考验。定位故障和日常问题的效率明显提高，并取得了稳定的效果。为了将每天的问题/故障定位时间从10分钟缩短到5秒以内，以下是随机抽取的两个真实案例。案例一：闲鱼发布受影响的监控系统，发现产品发布接口成功率下降，发送告警信息。点击告警诊断直接跳转到问题现场。发现某安全服务的错误率飙升。整个过程不到5秒。案例二：首页受单机问题影响。闲鱼首页因单机GC问题抖动并触发大量告警信息，并秒级给出问题路径。根据诊断路径，搜索单机出现大量异常。综上所述，整个系统目前主要集中在与服务稳定性相关的问题定位上。还有很多场景需要覆盖，信息需要完善，措施需要落实。位置只是其中的一部分。最终目标一定是构建问题定位、隔离、降级、快速恢复的完整闭环。要实现这样一个完整的闭环，离不开底层子系统的数据构建。核心在于两点一个方面的建设：底层数据的建设。完备的数据支撑一定是整个系统能够发挥价值的前提。虽然现阶段很多系统都在生产这方面的数据，但还远远不够。完整的事件抽象。数据不限于请求产生的埋点数据，其范围应该更广（应用发布、上线变更、流量波动等），任何可能影响上线的操作都应该抽象成一个事件。知识图谱的建立。仅仅拥有完整的事件并没有多大价值。真正的价值在于将这些事件关联起来，一旦出现问题/故障，第一时间还原现场，快速定位问题。
