一个系统，搞定闲鱼服务端复杂问题告警-定位-快速处理（二）_文化 & 方法_淘系技术



 写点什么

系统架构

我们认为这样一套问题自动定位的系统一定要满足 4 个目标，这同时也是整个系统的难点所在。

围绕着这 4 大目标，我们实现了上面这样一套完整的定位系统，实现了从告警->定位->快速处理这样一套完整闭环。自下而上划分为 4 个模块，下面讲一下每个模块解决的问题以及其难点。

数据采集模块主要负责埋点数据的采集与上报，需要解决两个问题：

海量数据。线上的埋点数据每时每刻都在产生，其数据量可达到 80G/ 分钟。
采集时延。快作为整个系统追求的一大目标，数据采集需要满足低时延。
可扩展指标。随着模型的不断演进完善，需要实现灵活的增加采集指标( cpu/gc/gc 耗时/线程数等)。
采用 SLS+ 自定义插件库来实现线上流量埋点数据的采集与上报。SLS 是阿里云研发针对日志类数据的一站式服务，其生命周期管理( TTL )以及极低的存储成本可以很好的解决海量数据带来的成本问题。

实时计算以数据采集的输出作为输入，负责对数据进行一轮预处理，包括链路数据的关联(请求都有唯一标识，按照标识 group by )，数据清洗(只选取需要的数据)以及事件通知。

当收到事件通知后根据实时计算产出的有效数据进行自动化的分析，输出问题的发生路径图。需要解决：

实时拓扑 vs. 离线拓扑。实时拓扑对埋点数据有要求，需要能够实时还原调用链路，但依赖采集数据的完整度。离线拓扑离线生成，不依赖采集数据的完整度，但不能准确反应当前拓扑。最后选择了实时还原拓扑方式保证准确率。
数据丢失。虽然实时计算中有解决数据协同等待的问题，但无法彻底解决数据的丢失问题(数据延时过大/埋点数据丢失)，延时以及丢失数据需要采取不同的处理策略。
分析准确率。影响准确率的因素很多，主要包括数据完整度以及分析模型的完备度。

按照时间窗口对问题发生路径进行实时聚合，还原问题发生时的现场。将监控，告警和诊断链路进行了互通，最大化的缩短从问题发现到结果展现的操作路径。

实时聚合 vs. 查询时聚合。查询时聚合性能差但是很灵活(可以根据不同的条件聚合数据),反之实时聚合牺牲了灵活性来保证查询性能。这里我们选择保证查询性能。
*并发问题。采用实时聚合首先要解决的是并发写(线上集群对同一个接口的聚合结果进行修改)。最后采取将图拆解成原子 key，利用 redies 的线程安全特性保证线上集群的写并发问题。
*存储成本 vs. 聚合性能。为了解决并发问题，我们利用 redis 的线程安全特性来解决，但带来的一个问题就是成本问题。分析下来会发现聚合操作一般只会跨越 2～5 个窗口，超过之后聚合结果就会稳定下来。所以可以考虑将聚合结果持久化。

系统上线以来经受住了实践的检验，故障以及日常问题的定位效率得到显著提升，并获得了稳定性的结果。将日常问题/故障定位时间从 10 分钟缩短到 5s 以内，以下是随机选取的两个真实 case 。

案例 1：闲鱼发布受影响，监控系统发现商品发布接口成功率下跌发出来告警信息，点击告警诊断直接跳转到问题现场，发现是因为安全某个服务错误率飙升导致，整个过程不到 5s。

案例 2: 首页因为单机问题受到影响，闲鱼首页因为单机 gc 问题抖动触发大量告警信息，秒级给出问题发生路径。根据诊断路径显示搜索单机出现大量异常。

目前整个系统主要聚焦服务稳定性相关的问题定位，仍然有许多场景有待覆盖，信息有待补全，措施有待执行，定位只是其中的一环。最终目的一定是建设问题定位，隔离，降级，与快速恢复这样一个完整闭环。要想实现这样一个完整闭环，离不开底层各个子系统的数据建设，核心在于两点一面的建设：

底层数据建设。完备的数据支持一定是整个系统能够发挥价值的前提，虽然现阶段很多系统在产出这方面的数据，但仍然远远不够。

完备的事件抽象。数据不仅仅局限于请求产生的埋点数据，其范围应该更为广泛(应用发布，线上变更，流量波动等)，任意可能对线上造成影响的操作都应该可以抽象成一个事件。

知识图谱的建立。仅仅有完备的事件并没有多大的价值，真正的价值在于把这些事件关联起来，在问题/故障发生时第一时间还原现场，快速定位问题。

本文转载自淘系技术公众号。

原文链接：https://mp.weixin.qq.com/s/gDlCjHv4AovLvP-4veYojw

发布

暂无评论