共计 9469 个字符，预计需要花费 24 分钟才能阅读完成。
简介：作者：王宇 (御田)。当你踏进了编程的畛域，代码和日志将是你最重要的搭档”。基于日志的问题排查是研发效力畛域的重要局部，阿里团体本地生存在撑持多生态公司、多技术栈的背景下，逐步积淀了一款跨利用、跨域的日志排查计划 -Xlog。本文给正在或行将应用 SLS 的同学提供一些参考，帮忙更好地落地日志排查计划。1. 背景 程序员学习每一门语言都是从打印“hello world”开始的。这个启蒙式的摸索，在向咱们传递着一个信息：“当你踏进了编程的畛域，代码和日志将是你最重要的搭档”。在代码局部，随同着越来越弱小的 idea 插件、快捷键，开发同学的编码效率都失去了较大的晋升。在日志局部，各个团队也在排查方向进行翻新和尝试。这也是研发效力畛域重要的组成部分。阿里团体本地生存，在撑持多生态公司，多技术栈的背景下，逐步积淀了一款跨利用、跨域的日志排查计划 -Xlog。目前也反对了 icbu、本地生存、新批发、盒马、蚂蚁、阿里 cto、阿里云、淘特、灵犀互娱等团队。也取得了 sls 开发团队的点赞。心愿本文能够给正在应用或筹备应用 sls 的同学带来一些输出，帮忙团队尽快落地日志排查计划。其中第一局部重点讲了在微服务框架下，日志排查面临了怎么的挑战，以及咱们是如何解决的。第二部从细节角度讲了方案设计的几个难点和攻克策略。第三局部讲的是 Xlog 以后具备的能力。第四局部是在围绕次要能力，如何进行生态能力建设的。1.1 Xlog 解决的问题在通过日志进行问题排查的时候，置信有几个步骤大家再相熟不过：1. 登陆跳板机。2. 切换跳板机。3. 登陆阿里云平台 sls。4. 切换阿里云 sls project logstore。周而复始。举个例子，上面这张图显示了一个长链路零碎的片段(实在链路会简单更多)：Application1, Application2, Application3。其中 Application1 与 Application2 是同一个域(相似于：一个子团队)，Application3 属于另外一个域。那本次查问就波及到跨利用查问，跨域查问两个场景。Application1 的负责人接手了该问题后，通过跳板机或者 sls 日志，发现须要上游同学帮忙帮助排查。这个时候无论是切换跳板机还是 sls，亦或分割 Application2 的负责人帮助查问，都须要 1min->3min 的响应工夫。如果是从 Application2 的负责人寻找 Application3 的负责人将会更难，因为可能不分明 Application3 的 sls 信息(咱们 bu 就有十万级别的 logstore 信息)，又没有跳板机登陆权限，又不晓得 Application3 的负责人。于是排查工夫大幅度减少。环境筹备的工夫(有效排查工夫) 甚至远大于无效排查的工夫。
方才的例子只展现了 3 个利用的查问场景，往往实在链路要比这个简单很多很多。所以是不是有一个平台，能够一键式、一站式地查问出须要的日志呢？于是致力于解决长链路下，跨利用和跨域搜素频繁切换的 Xlog 就诞生了！1.2 Xlog 反对的场景微服务框架下的跨利用查问，跨域交融背景下的跨域查问。- 如果你们的团队应用了 sls，或者筹备将日志采集到 sls；- 如果你们的心愿能够领有更好的日志检索、展现能力；- 如果你们心愿能够跨利用，跨域搜寻日志；本文为大家介绍 xlog，帮忙团体内业务构建更大生态的，简便易用无侵入，并且随着越来越多的域接入之后，能够连点成线、并线为面，独特打造一个经济体，或者更大生态的日志全链路计划。1.3 Xlog 以后体系建设
针对曾经采集到 sls 的利用，咱们能够做到对代码零革新、对部署环境无侵入，并且采集的构造、采集的渠道都是自在的。基本上，只有曾经接入了 sls 的，就能够接入 Xlog 了。通过对构造的归一、格局归一、和跨域能力买通，Xlog 反对了排查问题最常应用的几个场景：利用内跨文件搜寻，域内跨利用搜寻，跨域搜寻。《继续交付 2.0》的作者乔梁提到：一致性，是研发效力晋升必经之路。整个经济体倒退 20 多年，一致性的全量笼罩难如登天，但 Xlog 翻新地提出了一种计划，将不统一转化成统一，无论对查问还是对其余基于日志的技术体系建设，都有里程碑的意义。2. 方案设计这个段落将会具体讲述 Xlog 的设计思维和倒退过程，如果是曾经接入 sls 的能够间接跳到 2.2；如果以后还未接入 sls，能够读 2.1 会有一些翻新的思路。2.1 最后的计划：翻新与独善其身 2019 年 saas 刚成立，很多根底建设都有待欠缺，与很多团队一样过后咱们查问日志次要通过两种形式：1. 登陆跳板机查问：应用 Traceid-> 鹰眼 -> 机器 ip-> 登陆跳板机 ->grep 关键字 的查问链路。毛病：每次查问 4 - 6 分钟，日志检索和可视化差，无奈跨利用查问，历史日志无奈查看。2. 登陆阿里云 sls web 控制台查问：登陆 sls-> 关键字查问。毛病：每次查问 1 - 2 分钟，日志可视化差，无奈跨利用查问，无奈跨域查问。基于这样的背景，咱们做了 3 件事来晋升查问效率：- 日志格局对立: 针对 logback 中的 pattern 应用了一套规范。%d{yyyy-MM-dd HH:mm:ss.SSS} {LOG_LEVEL_PATTERN:-%5p}{LOG_LEVEL_PATTERN:-%5p}{PID:-} — [%t] [%X{EAGLEEYE_TRACE_ID}] %logger-%L : %m%n 其中：%d{yyyy-MM-dd HH:mm:ss.SSS}：工夫准确到毫秒 ${LOG_LEVEL_PATTERN:-%5p}：日志级别，DEBUG，INFO，WARN，ERROR 等 ${PID:-}：过程 id—：分隔符无特地意义[%t]：线程名[%X{EAGLEEYE_TRACE_ID}]：鹰眼跟踪 id%logger：日志名称 %m%n：音讯体和换行符一个域内应用雷同的日志格局，事实证明这带来的收益远超出预期。对全链路的剖析，监控，问题排查，甚至对未来的智能排查都带来极大便当。sls 结构设计与对立：将域内所有利用的采集格局对立成一套构造，和正则形式提字段，不便采集和配置。在 docker 的根底镜像外面生命 logtail 的配置，这样域内所有利用能够继承同样的日志采集信息。sls 采集构造下沉：这里咱们翻新的提出了一个概念下沉的理念。并通过这样的形式能够十分便捷的实现跨利用查问。如下图所示，sls 构造能够了解为 4 层：account, project, logstore, logtail。其中 logstore 这一层很要害，关系着关系查问的维度。常见的计划是应用一个利用对应一个 losgtore，这就导致在多个利用查问的时候，须要频繁切换 logstore。因而咱们翻新的提出了概念下沉的理念。让每一个环境对应一个 logstore，这样只须要确定了查问的环境，就能分明的晓得在哪个 logstore 中查问，从而实现跨利用查问的成果。
这套计划在解决单利用、域内跨利用有着十分好的性能体现，只须要实现一次 api 的调用。如果你所在的团队正在筹备应用 sls，如果 sls 的数据只用于做排查 (监控类的 sunfire 能够间接读服务器本地日志) 咱们仍然倡议采纳这样的计划。能够很好的实现排查的须要。同样基于这样几个条件的解决方案曾经积淀到 Xlog 中，能够间接接入 Xlog，从而享有 Xlog 全套的能力。2.2 当初的计划：翻新与兼济天下方才的计划在解决本人域的排查问题的时候有着很好的体现。但 2020 年，saas 开始撑持多个生态公司，面临的场景不再是本人域内的，还须要多个域独特串联。这时咱们面临着两大考验：接入老本：咱们规定了一套 sls 采集形式和日志格局，依照这样的模式能够不便的进行数据的采集和高效的查问、展现。然而在其余部门进行接入的时候发现，因为已有零碎曾经配置了监控、报表等模块，导致日志格局不能批改。因为有些零碎之前曾经采集到 sls 导致采集构造也不能批改。这两个信息不统一导致接入老本很大。
跨域场景：在零碎日趋简单的状况下，跨域场景也越来越多。拿本地生存的业务场景举例。在入淘的大背景下，局部零碎实现淘系迁徙，仍有局部零碎在蚂蚁域；两个域的买通须要通过网关。在口碑和饿了么深度交融的状况下，相互调用也须要通过网关。目前也在和收买的 isv 买通，同样须要通过网关。因为各个公司采纳的链路追踪计划不通，导致 traceid 等信息不统一，无奈全链路排查。所以如何解决跨域场景日志搜寻成为第二大问题。
因而，在之前的计划上，咱们把 Xlog 进行了降级，从新定义了指标：- 外围能力：利用 -> 跨利用 -> 跨域 -> 全域多场景日志排查。从只能查一个利用的日志，到能够在域内查一条链路的日志开启真正全链路日志排查的大门。- 接入老本方面：十分钟接入。通过代码逻辑升高对现有日志格局和采集形式的改变。反对 logtail、produce、sdk 等多种采集形式。- 侵入性方面：零侵入，对利用代码无侵入，间接与 sls 交互，实现解耦。- 自定义方面：反对查问界面自定义，展现后果界面自定义。2.2.1 模型设计因为调用 sls api 查问日志的单元是 logstore，咱们能够将多种多样的采集构造拆结为一下 3 种单元的组合（当然绝大多数域可能就是其中一种构造）。- 1. 一个环境对应一个 logstore，（比方：在这个域内，所有利用在日常环境的日志都在一个 logstore 中）。如下图所展现的域 A。- 2. 一个利用对应一个 logstore，（比方 A 利用日常环境对应 logstore1，A 利用预发环境对应 logstore2，B 利用日常环境对应 logstore3）。如下图所展现的域 B。- 3. 一个文件对应一个 logstore，（比方 A 利用的 a 文件在日常环境对应 logstore1，A 利用的 b 文件在日常环境对应 logstore2）。如下图所展现的域 C。
有了这样的原子结构，只须要在 xlog 上配置的时候，创立好一个域、环境、利用、文件 => logstore 的映射关系即可。这样就能够在域内进行利用粒度、文件粒度的查问。同样在不通过网关跨域场景能够通过组合两个域的 logstore 实现跨域的查问。如上图所示：在域 A 中指定两个利用，能够转换成 logstore 加过滤条件。在域 B 中指定两个利用，能够转换成两个 logstore。在域 C 中指定两个利用能够先寻找利用下的文件，而后找到文件对应的 logstore 汇合。至此就有了须要在阿里云 sls 查问日志的所有 logstore。将查问后果进行组合和排序就可失去最终的后果。同理，如果想进行跨域的搜寻，只须要将多个域的 logstore 进行拼接。而后进行查问即可。2.2.2 性能优化通过 2.2.1 模型设计的讲述，无论是环境类型的、利用类型的还是文件类型的 sls 构造，以及单利用、多利用、多个域的查问都能够转换成一组 logstore，而后遍历执行 logstore。然而这样就会引入新的问题，如果 logstore 很多，如何能力提效。举个例子，在对接某团队日志的时候发现，他们的 logstore 有 3000 个，每个环境有 1000 个利用。假如每次查问须要 150ms，1000 个利用须要执行 150s(2.5 分钟)。试想如果不指定利用在全域搜寻一次日志都须要 2.5 分钟，那将是多大的老本。针对这样的问题，咱们进行了性能方面的优化。次要采纳了以下几个形式，如下图所示：- Logstore 链接池预加载：将 logstore 进行去重和链接，缩小每次查问创立链接的工夫。针对活跃度不高的 logstore 进行降级，惰性加载。- 多线程并发：针对多个 logstore 的场景进行并发查问，缩小查问工夫。- 算法优先队列：针对查问人员进行亲疏算法优化，精简 logstore 查问数量，从而缩小开销。- 前端组合排序：后端只做查问操作，排序和查找等操作均在前端实现，缩小后端并发压力。
如上图所示，当用户通过前端抉择对应的操作域，以及查问条件之后。后端剖析获取须要查问的 logstore 列表（图中 A,B,C,D,E 所示）。再通过剖析用户的密切利用来进行排序和筛选，从而失去优先级队列（图中 B,A,C）。针对优先级队列应用曾经创立好的链接池进行并发查问，从而失去一组日志后果。最初由前端实现排序和组装，并渲染进去，实现一个周期。本文次要解说其中线程池并发和算法优化模块。2.2.3 线程池并发相较于传统的线程池并发执行没有太大差别。将须要查问的 logstore，依照程序插入到线程池队列。通过该伎俩能够在单次查问 logstore 数量较小 (小于外围线程数) 的时候，无效的升高查问工夫。针对数量较大的场景，由算法优化进行反对。针对查问后的弥补操作，也应用异步的解决形式，缩小查问耗时。- 构造后处理：在环境构造的域中，配置过程无需配置利用和文件。这些数据来源于每次查问之后，一直将缺失的数据主动填充进构造的解决操作。针对这些不影响当次查问后果的操作，作为后处理增加到异步线程池中。- 算法后处理，在解决人员亲疏关系和利用亲疏关系的评分逻辑中，应用的是一直训练的形式。该局部也不影响当次查问的后果，也放到异步线程池中。
2.2.4 算法优化针对满足条件的 logstore 较多 (超过外围线程数) 的场景，通过线程池并发进行查问也不能较快的拿到后果。通过日志快排一年数据的积攒和剖析，咱们发现即使是没有指定利用和搜寻条件，也能够通过查问人员的操作习惯或者关注利用习惯，定位到最有可能的 logstore 序列。举个例子，在商家 saas 核心，利用数量有 500 个左右。同学 A 负责的零碎是 Application1，查问次数较多的利用还有 Application11，Application12。除此之外，与 Application1 处于严密上下游关系的利用是 Application2，Application3。如果是这样，咱们能够认为同学 A，对利用 Application1，Application11，Application12，Application2，Application3 的关注度会高于其余利用。针对这几个利用，能够进行优先查问。从而将的 500 个查问工作升高成 5 个。联合日常生活中的情况，每个开发同学关注的利用数量大概率会管制在 30 个以内。通过以上的剖析，咱们建设了两套亲疏关系网络用于定位查问批次和梯队。- 人员亲疏关系当用户每次调用的时候，都能够将查问条件，查问后果和用户进行剖析和关系创立。因为查问条件中能够指定利用，也能够不指定利用。如果是指定利用的，阐明用户明确查问该利用内容。将该用户和该利用的亲密度加 5 分。如果没有指定利用，依据关键字查问，能够剖析查问出的后果。将查问后果的各条日志对应的利用提取进去，而后加 1 分（因为不是明确指定的，而是依据关键字辐射到的）。至此，通过屡次的用户操作，就能够获取到用户与各个利用的亲密度。当遇到多 logstore 查问的场景，能够依据用户筛选出与之亲密度最高的 15 个利用。作为第一批查问对象。- 利用亲疏关系：利用之间也存在着亲密度关系。亲密度越高的利用，被关联搜寻进去的概率就越大。举个例子，center 与 prod 两个利用在零碎设计上就有这严密的关联关系。如果用户 A 的亲属关系中蕴含利用 center，那么在其查问日志的时候就有较大概率辐射到利用 prod。基于这样的思路，就能够通过剖析每次查问日志的后果进行关系矩阵的创立。在每次获取通过关键字查问的日志后果之后，将波及到的利用进行两两亲密度加 1。相当于在一个链路上的利用亲密度都加 1。不便当前查问时不会因为人员亲密度丢失利用亲密度的信息，导致链路失真。
下面大抵概括了一下，咱们是如何训练亲疏关系矩阵的，上面讲一下如何通过这个矩阵进行查问算法优化的。如下图，左上角是咱们记录的人 - 利用，利用 - 利用的亲疏关系矩阵。具体来讲，用户和利用 A、利用 B、利用 C 等关系，咱们会用一个分数度量他们的亲疏关系，次要能够形容人对利用的关注度。在利用 - 利用之间，咱们记录了彼此的耦合度。右上角是查问条件，依据查问条件以及各个域的采集构造，能够疾速的计算出须要查问的 logstore 的列表。但并不是所有的 logstore 都须要查问，这里会将亲疏关系矩阵和 logstore 的列表取交加，而后排序进行搜寻。如下图所示，针对交加命中的利用，会先依照人 - 利用的亲疏关系进行计算，选出分值比拟高的。而后有余 30 个阈值的应用利用 - 利用的亲疏关系进行补充。这里就波及到一个比拟逻辑，会依照人和利用的比例分值 * 利用与利用比例的分值，相似于哈夫曼编码中的门路权重的意思。最初失去须要查问的 30 个 logstore 的列表。
2.2.5 跨域映射进行全链路的排查，跨域是必须面对的挑战。在实现原理上讲，跨域有两种场景：通过网关、没有通过网关。- 不通过网关的场景，如：淘系不同域的相互调用。这个场景其实实质上与域内搜寻没有太大区别，这里不多介绍。- 通过网关的场景，如：淘系与蚂蚁系相互调用，因为每个域应用的链路追踪计划不同，无奈应用一个 traceId 将整个链路串联起来。这里次要讲一下这种场景的解决形式。
如上图所示，展现了域 1，域 2，域 3，域 4 的调用链路。其中域 1 调用域 2，域 3 调用域 4 不通过网关，traceId 不产生扭转。在域 2 调用域 3 的时候须要通过网关，并且 traceId 产生扭转。咱们能够将查问形式分为两种。1. 关键字查问，比方输出订单号。这种其实并不受链路追踪计划影响，也不受网关影响。所以还是在各个域依据关键字查问即可。2. 通过 traceId 查问。这种首先须要通过网关信息获取到映射关系。也就是 traceId1->traceId2。而后别离用这两个 traceId 到各自的域中进行搜寻即可。3. 现有能力通过对原有飞云日志快排性能的欠缺，以及接入老本的改进。Xlog 曾经实现次要性能的开发和实现。链接：Xlog.
跨域查问操作：
多场景笼罩：通过对用户应用习惯的剖析，目前反对了单个利用、域内跨利用、跨域。依照文件，日志等级，关键字，工夫等搜寻。同时反对用户操作习惯保留。多模式反对：对阿里云 sls 采集构造进行反对，只有能够拆解为以上三种模式的采集形式都能够反对，如果极非凡状况可分割 御田进行定制化。零老本接入：对于曾经接入 sls 的零碎，无需改变 sls 配置，只需在 Xlog 上进行配置即可。对于 sls 采集日志保留工夫，采集形式，估算等散发到各个业务团队，可依据本人理论状况进行调整。自定义界面：针对不同的域，可能对一些关键字段的敏感度不同。比方有些须要应用 traceid，有些须要应用 requestid，游戏须要应用 messageid，针对这种场景，反对自定义搜寻框，和展现日志的时候对关键字段高亮。性能保障：通过以上多种手段的性能优化，目前性能指标如下：单个利用查问 150ms。32 个利用 400ms。超过 50 个利用，进行算法优化，工夫在 500ms。4. 生态建设本章节记录了，在此体系上进行的日志层面的优化和建设。大部分思维和策略是能够复用的，心愿能够给雷同诉求的同学带来帮忙。4.1 老本优化 Xlog 体系搭建实现之后，如何降低成本成为了新的挑战。通过以下形式的落地，老本升高 80%。这里也把次要的几个操作列举进去，心愿能够给雷同在应用 sls 的用户一些帮忙。- 域外日志间接上传到域内：阿里云对外部账号绝对于内部账号是有额定的优惠的。所以如果有弹外部署的部门，能够思考把日志间接上传到域内的账号，或者把账号申请成为域内账号。- 单利用优化：其实打印日志的时候，往往没有思考到老本起因，很多都是顺手就打了。因而咱们给每个利用依照交易量进行了域值设计，超过指标的须要进行优化。- 存储工夫优化：优化存储工夫是最简略，最间接的一个形式。咱们将线下 (日常和预发) 的日志存储升高到了 1 天，线上的升高到了 3 天 ->7 天。而后再配合应用归档能力，进行老本的优化。- 索引优化：索引优化相对来说比较复杂，然而也是成果最显著的。通过剖析，咱们大部分老本开销散布在索引、存储、投递。其中索引占了 70% 左右。优化索引的操作，其实就是将索引所占的日志比例升高。比如说只反对前多少字节的一个查问能力，前面的详情局部是从属的详细信息。因为咱们域内有对立的日志格局，所以在域内的日志中只留了 traceid 的索引，同时对摘要日志放弃了全索引。所以后续的查问形式变成先通过摘要日志查问 traceid，再通过 traceid 查详情。4.2 归档能力在搭建整个架构的同时，咱们也思考了老本的因素。在降低成本的时候，咱们把存储工夫进行了缩短。然而缩短存储工夫，必然会导致历史问题的排查能力缺失。所以咱们也提出归档能力的建设。在 sls 的 logstore 中，能够配置数据投递：https://help.aliyun.com/docum…。这一步操作其实是讲 sls 中的信息，存储到 oss。艰深的讲，就是把数据库的表格，用文件的模式保留下来，删掉索引的能力。在投递过程中会进行加密，目前 Xlog 反对了在界面上进行下载归档的日志，而后在本地进行搜寻。后续能够按需将 oss 数据从新导入到 sls，参考：https://help.aliyun.com/docum…。4.3 异样日志扫描借助于之前的架构，其实能够很清晰的晓得每条日志的内容局部是哪里，也能够精准的查问出记录了 error 日志的文件内容。所以每 10 分钟巡检一次，将每个利用中的异样日志聚合起来，就能够获取到这段时间异样信息的数量。而后在于之前的比拟就能够晓得，是不是有新增的谬误，暴增的谬误等等。
如上图所示，拿到所有异样日志后，会依照一个规定进行 md5 的计算。堆栈类的和异样日志类的，针对两类的算法不同，然而实质指标是一样的就是取其中最有可能重读的段落计算 md5，而后进行聚类。聚类实现之后，就能够获取差别，进行比拟，从而判断是不是新增或者暴增。5. 布局目前 Xlog 的根底组件和性能曾经实现结束。在各个利用和域的接入中，整个链路将会越来越全。接下来将向全链路，可视化排查、智能排查和问题发现方面进行补充。
异样定位辅助：在可视化链路上，将含有异样的利用标红，不便疾速查到谬误日志。线上典型问题聚合：日志巡检。线下谬误捕捉护航：在业务测试的时候常常不会实时的查看日志中的错误信息，开启护航模式，将舰艇利用谬误，一旦线下执行过程中呈现，将会推送。信息查问：与钉钉买通，用于快捷查问。钉钉 @机器人，发送关键字，钉钉将最近执行后果返回。智能排查：@钉钉输出 traceid，订单号等，返回检测到的异样利用和异样栈。业务流程编排核查：容许利用日志流程编排，依据关键字串联的链路流程日志须要满足肯定规定。用此规定进 - 核查。=> 针对实时性要求不高，仅对流程进行验证。公布门禁：线下用例回放无业务异样，线上平安生产无业务异样 => 容许公布 6. 应用与共建参考很多其余团队的采集构造、日志模式、查问形式、展现款式的要求，在接入老本上升高和自定义方面进行了晋升。针对曾经满足条件的团队，能够不便的接入。针对还有一些非凡，或者定制化的需要，Xlog 进行了拓展模块的预留，不便共建。
如上图，图中绿色组件均可复用，只须要针对本人的域进行构造自定义和跨域映射自定义即可。只须要依据定义好的策略模式的接口进行实现即可。
原文链接：https://click.aliyun.com/m/10…
本文为阿里云原创内容，未经容许不得转载。