介绍：作者：王宇（于田）。当你踏入编程领域，代码和日志将是你最重要的伙伴。”基于日志排错是研发效率领域的重要内容。-技术栈，逐步沉淀出一个跨应用、跨域的日志排查解决方案-Xlog，本文为正在或即将使用SLS的同学提供一些参考，帮助更好的实现日志排查解决方案。1.后台程序员学习每一种语言都是从打印“helloworld”开始的，这种启蒙探索正在向我们传递一个信息：“当你踏入编程领域时，代码和日志将是你最重要的伙伴。”在代码部分，有更多和更强大的idea插件和快捷键，大大提高了开发者的编码效率，在日志部分，各个团队也在朝着调研的方向进行创新和尝试。这也是研发效率领域的重要组成部分。阿里集团本地生活在支持多生态公司、多技术栈的背景下，逐渐沉淀出一个跨应用、跨域的日志排查方案——Xlog。目前还支持icbu、本地生活、新零售、盒马、蚂蚁、阿里cto、阿里云、淘特、灵犀互娱等团队也获得了sls开发团队的好评。希望本文能给正在使用或计划使用sls的同学带来一些投入，帮助团队尽快落地Log排查方案。第一部分重点介绍微服务框架下日志排查所面临的挑战以及我们是如何解决的。第二部分从细节的角度谈了解决方案设计的几个难点和攻克策略。Part2第三部分是Xlog目前的能力。第四部分是主要能力以及如何打造生态能力。1.1Xlog解决的问题通过日志排查问题，相信有几个步骤大家都很熟悉：1.登录跳板机。2.切换跳板机。3.登录阿里云平台sls。4.切换到阿里云sls项目logstore。反复。例如下图是一个长链接系统的片段（真正的链接会更复杂）：Application1、Application2、Application3。其中，Application1和Application2属于同一个域（类似于：一个子组），Application3属于另一个域。那么这个查询涉及到跨应用查询，跨域查询两种场景。Application1的负责人接手问题后，发现需要上游同学通过跳板机或者sls日志帮助排查。这时候无论是切换跳板还是sls，还是联系Application2的负责人协助查询，都需要1min->3min的响应时间。从Application2的负责人找Application3的负责人会比较困难，因为可能不清楚Application3的sls信息（我们在bu有10万级别的logstore信息），没有跳板登录权限，我们不知道Application3主体的sls信息。结果，调查时间大大增加了。环境准备时间（无效调查时间）甚至比有效调查时间还要长很多。前面的例子只展示了三个应用的查询场景，真正的环节往往比这复杂得多。那么有没有可以一键一站式查询所需日志的平台呢？于是，致力于解决长链接下跨应用、跨域搜索频繁切换的Xlog诞生了！1.2Xlog支持的场景微服务框架下的跨应用查询，跨域融合背景下的跨域查询。-如果你的团队使用sls，或者打算收集日志到sls；-如果你想有更好的日志检索和展示能力；-如果您想跨应用程序和域搜索日志；本文为大家介绍xlog，帮助群内业务构建更大的生态，简单易用，无侵入性，随着越来越多的域连接起来，点连成线，线连成面，共同创造一个经济体，甚至多个大生态的日志全链路解决方案。1.3Xlog目前的系统搭建对于已经采集sls的应用，我们可以做到代码零修改，不侵入部署环境，采集结构和采集通道都是免费的。基本上只要连上了sls，就可以连上Xlog了。通过规范结构、格式和跨域能力，Xlog支持最常用的排错场景：应用内跨文件搜索、域内跨应用搜索、跨域搜索。《持续交付2.0》的作者乔梁提到：一致性是提高研发效率的唯一途径。整个经济发展了20多年，很难涵盖全量的一致性。而Xlog创新性地提出了一种将不一致转化为一致的解决方案，这对于查询和其他基于日志的技术系统来说都是一个里程碑。意义。2.方案设计本段将详细描述Xlog的设计思路和开发过程。如果已经连上了sls，可以直接跳到2.2；如果你还没有连接到sls，你可以阅读2.1来获得一些创新的想法。2.1原计划：创新自立SaaS2019年刚刚成立，很多基础设施需要完善。和很多团队一样，我们当时主要使用两种方式查询日志：1、登录跳板查询：使用Traceid->Hawkeye->机器ip->登录跳板机器->grep关键字查询链接。缺点：每次查询4-6分钟，日志检索和可视化较差，无法跨应用查询，无法查看历史日志。2、登录阿里云slsweb控制台查询：登录sls->关键字查询。缺点：每次查询耗时1-2分钟，日志可视化差，不能跨应用跨域查询。基于这样的背景，我们做了三件事来提高查询效率：-统一的日志格式：logback中的pattern使用了一套标准。%d{yyyy-MM-ddHH:mm:ss.SSS}{LOG\_LEVEL\_PATTERN:-%5p}{LOG\_LEVEL\_PATTERN:-%5p}{PID:-}---[%t][%X{EAGLEEYE\_TRACE\_ID}]%logger-%L:%m%n其中：%d{yyyy-MM-ddHH: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，使得域内所有应用都可以继承相同的日志采集信息。slsacquisitionstructure下沉：这里我们创新性的提出了下沉的概念。并且通过这种方式，可以非常方便的实现跨应用查询。如下图所示，sls结构可以理解为四层：account、project、logstore、logtail。其中logstore层非常重要，关系到关系查询的维度。一种常见的解决方案是一个应用对应一个logstore，这就导致多个应用查询时需要频繁切换logstore。因此，我们创新性地提出了概念下沉的想法。让每个环境对应一个logstore，这样你只需要确定查询环境，就可以清楚的知道在哪个logstore中查询，从而达到跨应用查询的效果。该方案在解决单应用和域内跨应用方面有很好的性能，只需要完成一次API调用。如果你的团队准备使用sls，如果sls的数据只是用来排查问题（监控sunfire可以直接读取服务器本地日志），我们还是推荐这个方案。可以很好的完成调查需要。基于这些条件的解决方案已经存入Xlog，可以直接接入Xlog，享受Xlog的全套能力。2.2当前方案：创新，造福世界刚才的方案在解决自身领域的故障排除问题上有很好的表现。但2020年，SaaS开始支持多个生态公司，它面对的场景不再是自己的域内，需要多个域连接在一起。这个时候我们面临两大挑战：接入成本：我们指定了一套sls采集方式和日志格式，方便数据采集和高效查询展示。但是，当其他部门对接时，发现无法修改日志格式，因为现有系统已经配置了监控、报表等模块。因为有些系统之前已经采集过sls，所以不能修改采集结构。两条信息的不一致导致访问成本很高。跨域场景：随着系统越来越复杂，跨域场景也越来越多。以本地生活的业务场景为例。在进入淘宝的背景下，部分系统已经完成了淘宝的迁移，部分系统还在蚂蚁域；两个域之间的连接需要通过网关。在口碑与饿了么深度融合的情况下，相互调用也需要通过网关。目前也在和收购的ISV打通，同样需要通过网关。由于各个公司采用的链路跟踪方案不一致，导致traceid等信息不一致，无法查看整个链路。那么如何解决跨域场景日志查找就成了第二大难题。因此，在之前的方案中，我们升级了Xlog，重新定义了目标：-核心能力：应用->跨应用->跨域->全局多场景日志排查。从只能查看一个应用的日志，到可以查看域内一个链接的日志，打开了真正全链路日志查看的大门。-访问费用：10分钟访问。通过代码逻辑减少对现有日志格式和采集方式的改动。支持logtail、produce、sdk等采集方式。-侵入方面：零侵入，不侵入应用代码，直接与sls交互，实现解耦。-自定义：支持查询界面自定义和显示结果界面自定义。2.2.1模型设计由于调用slsapi查询日志的单元是logstore，所以我们可以将各种集合结构拆解成以下三种单元的组合（当然大部分领域可能是其中一种结构）。-1.一个环境对应一个logstore，（例如：在这个域中，日常环境应用的所有日志都在一个logstore中）。域A如下图所示。-2、一个应用对应一个logstore（比如应用A的日常环境对应logstore1，应用A的预发布环境对应logstore2，应用B的日常环境对应logstore3）。域B如下图所示。-3、一个文件对应一个logstore（比如应用A的文件a对应日常环境的logstore1，应用A的文件b对应日常环境的logstore2）。域C如下图所示。有了这样的原子结构，只需要在xlog上配置的时候建立domain,environment,application,file=>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列表（图中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个应用。作为第一批查询对象。-应用亲和关系：应用之间也存在亲和关系。应用的亲密度越高，被联想搜索出来的概率就越高。比如applicationscenter和prod这两个，在系统设计上就有这么密切的关系。如果应用中心包含在用户A的亲属关系中，则用户A在查询日志时大概率会辐射到应用prod。基于这种思想，可以通过分析每个查询日志的结果来创建关系矩阵。每次获取关键词查询的日志结果后，相关应用的pairwise亲密度加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个应用程序为400毫秒。50多个应用的??算法优化耗时500ms。4.生态建设本章记录日志级别在本系统上的优化和建设。大部分思路和攻略都可以复用，希望对有相同诉求的同学有所帮助。4.1成本优化Xlog系统建成后，如何降低成本成为新的挑战。以下方法实施后，成本降低80%。主要的操作也列在这里，希望能给同样在使用sls的用户一些帮助。-将域外日志直接上传到域内：阿里云内部账户相对于外部账户有额外优惠。所以，如果有部门部署在项目外，可以考虑将日志直接上传到域内账号，或者申请账号成为域内账号。-单应用优化：其实在打印日志的时候，往往不考虑成本，很多都是随便打的。因此，我们根据交易量为每个应用设计了阈值，并对其进行了优化以满足超指标的需求。-存储时间优化：优化存储时间是最简单直接的方法。我们将离线（每日和预发）日志存储减少到1天，在线日志存储减少到3天->7天。然后结合使用归档功能来优化成本。-索引优化：索引优化相对复杂，但也是最有效的。经过分析，我们的大部分成本都分布在索引、存储和交付上。其中，指数约占70%。优化索引的操作其实就是降低索引占用日志的比例。例如只支持前几个字节的查询能力，后面附上详细信息。由于我们域有统一的日志格式，所以域内的日志只保留traceid索引，summary日志维护全索引。所以后续的查询方式就变成了先通过summarylog查询traceid，再通过traceid查看详情。4.2归档能力在构建整个架构的同时，我们也考虑了成本因素。在降低成本的同时，我们缩短了存储时间。但是，缩短存储时间必然会导致历史问题的排查能力不足。因此，我们也提出归档能力的建设。在sls的logstore中，可以配置数据下发：https://help.aliyun.com/document\_detail/371924.html。这一步其实就是将sls中的信息存储到oss中。通俗地说，就是能够将数据库的表以文件的形式保存下来，删除索引。加密将在交付过程中执行。目前Xlog支持在界面上下载并归档日志，然后在本地进行搜索。后面可以根据需要重新导入oss数据到sls，参考：https://help.aliyun.com/document\_detail/147923.html。4.3异常日志扫描借助前面的架构，其实可以知道每条日志的内容在哪里，也可以准确的查询到记录错误日志的文件内容。因此，每10分钟进行一次巡检，可以汇总各个应用中的异常日志，得到这段时间的异常信息量。然后通过之前的对比就可以知道有没有新的错误，有没有急剧增加的错误等等。如上图所示，在获取到所有的异常日志后，会按照一定的规则计算md5。stack类型和exceptionlog类型这两种类型的算法不同，但是本质目标是一样的，就是计算出最有可能被重读的段落的md5，然后进行聚类。聚类完成后，可以得到差异并进行比较，判断是新增还是突增。5.规划目前Xlog的基本组件和功能已经实现。在各种应用和领域的接入中，整个链路会越来越完整。接下来补充全链路、可视化排障、智能排障和问题发现。异常定位帮助：在可视化链接上，将出现异常的应用标记为红色，便于快速查找错误日志。线上典型问题汇总：日志检查。离线错误捕获护航：业务测试时，往往没有实时查看日志中的错误信息，开启护航模式，将错误应用到船上。离线执行一旦出错，就会被推送。信息查询：连接钉钉快速查询。钉钉@机器人，发送关键字，钉钉会返回最新的执行结果。智能排查：@dingding输入traceid、订单号等，返回检测到的异常应用和异常堆栈。业务流程编排检查：允许应用日志流程编排，按照关键字串联的链路流程日志需要满足一定的规则。使用此规则进行检查。=>实时性要求不高，只验证流程。发布权限控制：线下用例回放无业务异常，线上安全生产无业务异常=>允许发布降低成本，提升定制化。对于已经满足条件的队伍，可以轻松获取。针对一些特殊或者定制化的需求，Xlog预留了扩展模块，方便共建。如上图所示，图中绿色组件是可以复用的，只需要为自己的域自定义结构和跨域映射即可。只需要按照定义好的策略模式的接口来实现即可。版权声明：本文内容由阿里云实名注册用户投稿，版权归原作者所有。阿里云开发者社区不拥有自己的版权，也不承担相应的法律责任。具体规则请参考《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如发现本社区涉嫌抄袭内容，请填写侵权投诉表进行举报，一经查实，本社区将立即删除涉嫌侵权内容。
