解决方案:共同打造专业的云端知识库，沉淀知识资产！“语雀”正在强大！

　　解决方案:共同打造专业的云端知识库，沉淀知识资产！“语雀”正在强大！

　　之前介绍工具【窗帘】的时候，有读者和我们反映这个软件的部分功能开始收费，向我们推荐了【雨雀】。了解之后发现这个软件真的很强大，现在推荐给大家！

　　一、语雀简介

　　【鱼阙】是一个专业的云知识库，孵化自蚂蚁金服（你想到支付宝了吗？）。10万阿里巴巴员工书写文档，积累知识。

　　【语言】一词来源于【语言】，一般指人类交流的方式。语雀的核心是通过将知识以文字、图片、表格等形式承载交流过程中需要用到的载体，让人与人之间的交流更加高效。

　　“云雀”一词来源于“云雀”，在雪莱的代表作《致云雀》中象征着“欢乐、光明和美丽”。

　　官网介绍视频

　　二、案例效果

　　很多老师会问，为什么要为这些花里胡哨的东西烦恼呢？

　　当文件堆积如山，没有条理，查找起来很麻烦。当文件存储没有组织有序时，工作效率很低。

　　经雨阙编辑后，左侧为全书目录，可分类；右边是章节中自动生成的内容大纲。

　　像一本书，整齐有序，一目了然！

　　三、功能介绍

　　1.丰富的应用场景。拥有多种典型模板，包括项目文档、学习笔记等。

　　2.专业编辑。自研编辑器，支持Markdown、脑图、代码块、公式等专业版块的输入，也支持本地视频、Office文件、PDF的在线阅读。

　　

　　3. 结构化的知识库。拥有大量的知识库排版模型，快速形成像一本书一样清晰易读的知识库。

　　4.系统协调。基于团队的知识管理，使团队能够一起在线。实现团队之间知识的自由流动，创造更大的价值。

　　5、同时，所有公立医院、公立学校、非营利组织均可申请长期免费使用【鱼雀空间】，长期免费使用的知识库和文档数量不限。

　　四、功能介绍

　　1.个人用户进行个人创作，写生活日记。建立个人秘密仓库，存放个人笔记。使用它来采集和组织数据并建立自己的知识库。

　　2. 小型组织适合社团、学习小组、一群人一起创建知识库。集体编写和翻译书籍。分工写文件和制作手册。

　　五、操作指南

　　去鱼雀官方网站注册使用，或者在电脑上下载软件。

　　网址：

　　您可以选择手机号、钉钉或微信登录。

　　客户端界面

　　页面端工作界面

　　1. 创建新的文件和表格

　　在任何带有顶部导航的页面上，单击右侧的“+”以启动新文档和表格的创建。

　　进入编辑器后，无论是文档还是表格，每隔1分钟就会开启一次自动保护。内容仅在没有帖子或更新时对您或您的团队成员可见。

　　

　　当然，手动保护也是可以的。

　　2.资源知识库文件上传

　　第一步是选择“新建知识库”，在新建知识库页面选择“资源知识库”。

　　第二步，点击右上角的“上传文件”，一次最多可以同时上传10个文件。

　　以前的教案和知识总结文件可以统一上传，组织成知识体系框架，构建知识库，方便又安全。

　　3.组建团队共同编辑

　　第一步，在第一个飞行栏上，点击“+”并选择New Team。

　　第二步：在弹出的页面中，选择需要的类型模板，点击下一步。

　　第三步：在弹出的信息输入页面，输入团队信息，选择需要的套餐。

　　基本模型有50个团队成员，这已经足够庞大了！

　　教学视频：

　　用户手册：

　　如果喜欢今天的文章，请留言告诉小编！

　　本文为实用教育技术原创，作者蛋挞。

　　解决方案:阿里本地生活全域日志平台 Xlog 的思考与实践

　　作者 | 王宇（奥天）

　　来源 | 阿里云日志服务团队

　　1. 背景

　　程序员通过打印“hello world”来学习每一种语言。这种启发性的探索正在向我们传递一个信息：“当你踏入编程领域时，代码和日志将是你最重要的伙伴”。在代码部分，有了越来越多强大的idea插件和快捷键，大大提高了开发者的编码效率。在日志部分，各个团队也在朝着调查的方向进行创新尝试。这也是研发有效性领域的重要组成部分。

　　阿里集团的本地生活，在支持多生态公司、多技术栈的背景下，逐渐沉淀出跨应用、跨域的日志排查解决方案——Xlog。目前还支持icbu、本地生活、新零售、盒马、蚂蚁、阿里cto、阿里云、淘特、灵曦互娱等团队。也获得了sls开发团队的好评。

　　希望这篇文章能给正在使用或打算使用sls的同学带来一些投入，帮助团队尽快落实日志排查计划。第一部分重点介绍微服务框架下日志排查面临的挑战以及我们是如何解决的。第二部分从细节的角度谈了程序设计的几个难点和克服策略。第三部分是关于 Xlog 目前的能力。第四部分，主体能力，如何建设生态能力。

　　1.1 Xlog解决的问题

　　通过日志排查的时候，相信有几个步骤大家都很熟悉： 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.2 Xlog支持的场景

　　微服务框架下的跨应用查询，跨域集成环境下的跨域查询。

　　本文向大家介绍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->Eagle->机器ip->登录跳板->grep关键字的查询链接。缺点：每次查询4-6分钟，日志检索和可视化较差，无法跨应用查询，无法查看历史日志。

　　2.登录阿里云sls web控制台查询：登录sls->keyword查询。缺点：每次查询1-2分钟，日志可视化较差，无法跨应用跨域查询。

　　基于这样的背景，我们做了3件事来提高查询效率：

　　统一的日志格式：一组标准用于 logback 中的模式。

　　%d{yyyy-MM-dd HH:mm:ss.SSS} {LOG_LEVEL_PATTERN:-%5p}{LOG_LEVEL_PATTERN:-%5p}{PID:-} --- [%t] [%X{EAGLEEYE_TRACE_ID}] %记录器-%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: 消息正文和换行符

　　在域内使用相同的日志格式被证明比预期更有利可图。对整个链路的分析、监控、故障排除，甚至未来的智能故障排除，都将带来极大的便利。

　　

　　该方案在解决域内单应用和跨应用方面都有非常好的表现，只需要完成一次API调用。如果你的团队准备使用 sls，如果 sls 的数据只是用来排查问题（监控类的 sunfire 可以直接读取服务器的本地日志），我们还是推荐这个方案。它可以很好地完成调查的需要。基于这些条件的解决方案已经存入Xlog，可以直接接入Xlog，享受Xlog的全套能力。

　　2.2 当前计划：创新助世界

　　刚才的解决方案在解决自己域的排错问题上表现不错。但2020年，SaaS开始支持多个生态公司，面临的场景不再是自己的领域，需要将多个领域打通。在这一点上，我们面临两个主要挑战：

　　因此，在之前的方案中，我们升级了Xlog，重新定义了目标：

　　2.2.1 模型设计

　　由于调用sls api查询日志的单元是logstore，所以我们可以将各种采集结构拆分成以下三个单元的组合（当然大部分域可能是这些结构之一）。

　　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有3000个，每个环境有1000个应用。假设每个查询需要 150ms，1000 个应用程序需要执行 150s（2.5 分钟）。试想一下，如果在不指定应用程序的情况下搜索整个域以查找日志需要 2.5 分钟，将会花费多少。针对这个问题，我们对性能进行了优化。主要使用以下方法，

　　如上图所示，当用户通过前端选择对应的操作域和查询条件时。后端分析得到需要查询的logstore列表（如图A、B、C、D、E所示）。然后通过分析用户的私密应用进行排序和过滤，得到一个优先级队列（图中B、A、C）。使用创建的链接池对优先级队列进行并发查询，得到一组日志结果。最后前端完成排序组装，渲染完成一个循环。本文主要讲解线程池并发和算法优化模块。

　　2.2.3 线程池并发

　　与传统的线程池并发执行相比，并没有太大的区别。将要查询的logstore按顺序插入到线程池队列中。通过这种方式，在每次logstore查询次数较少（小于核心线程数）的情况下，可以有效减少查询时间。对于大量场景，有算法优化支持。

　　对于查询后的补偿操作，也采用异步处理的方式来减少查询时间。

　　2.2.4 算法优化

　　对于满足条件的logstore较多（超过核心线程数）的场景，通过线程池并发查询无法快速得到结果。经过一年的日志快速排序数据积累和分析，我们发现即使不指定应用和搜索条件，通过查询人员操作习惯或关注应用习惯，也能定位到最可能的日志存储顺序。

　　例如，在商家 saas 中心，大约有 500 个应用程序。同学A的负责系统是Application1，查询较多的应用程序是Application11和Application12。另外，与Application1上下游关系密切的应用是Application2和Application3。如果是这样，我们可以认为A同学会比其他应用程序更关注应用程序Application1、Application11、Application12、Application2和Application3。对于这些应用程序，可以执行优先级查询。从而将 500 个查询任务减少到 5 个。

　　结合日常生活中的情况，每个开发者关注的应用数量极有可能控制在30个以内。

　　通过以上分析，我们建立了两组亲和网络来定位查询批次和梯队。

　　用户每次调用时，都可以分析查询条件、查询结果和用户，建立关系。因为可以在查询条件中指定应用程序，所以也不需要指定应用程序。

　　如果是指定的应用程序，则表示用户显式查询了应用程序的内容。给用户与应用的亲密度加 5 分。

　　如果不指定应用，可以根据关键字查询来分析查询结果。提取查询结果的每条日志对应的应用，然后加1分（因为没有明确指定，而是根据关键字进行辐射）。

　　至此，经过多次用户操作，即可获得用户与各个应用之间的亲密度。当遇到多个logstore查询时，可以根据用户过滤掉亲密度最高的15个应用。作为第一批查询对象。

　　应用程序之间也存在亲和力。应用的亲密度越高，被关联搜索的概率就越大。例如，应用中心和产品这两个应用中心在系统设计上就有这种密切的关系。如果用户A的亲属关系中收录application center，那么在查询log的时候很有可能会辐射到application prod。基于这个思想，可以通过分析每个查询日志的结果来创建关系矩阵。

　　每次获取关键字查询的日志结果后，涉及的应用的成对亲密度加1。相当于在一个链接上应用亲密度加1。方便日后查询，不会因人员亲密度丢失应用亲密度信息，导致链接失真。

　　以上是我们如何训练亲和矩阵的一般概述。下面说说如何通过这个矩阵来优化查询算法。如下图，左上角是我们记录的人-应用和应用-应用的关系矩阵。具体来说，对于用户与应用A、应用B、应用C等的关系，我们会用一个分数来衡量他们的亲和度，主要可以描述人们对应用的关注度。在 app-app 之间，我们记录了彼此的耦合程度。右上角是查询条件。根据查询条件和各个域的采集结构，可以快速计算出要查询的logstore列表。但并非所有日志存储都需要查询。这里，

　　如下图所示，对于命中路口的应用，会根据人和应用的关系进行计算，选择得分高的。然后，那些低于 30 阈值的人会得到应用与应用亲和力的补充。这里涉及到一个比较逻辑，会根据人与应用的比例得分*应用的得分与应用比例，类似于霍夫曼编码中路径权重的含义。最后得到一个需要查询的30个logstore的列表。

　　2.2.5 跨域映射

　　跨域是进行全链路故障排除时必须面对的挑战。在实现原理上，跨域有两种场景：通过网关和不通过网关。

　　如上图所示，分别为域1、域2、域3、域4的通话链接。域1调用域2，域3调用域4不经过网关，traceId不变。域2调用域3时，需要经过网关，traceId发生变化。

　　我们可以将查询方法分为两种。1.关键字查询，如输入订单号。这实际上不受链路跟踪方案的影响，也不受网关的影响。因此，您仍然可以按每个域中的关键字进行搜索。2.通过traceId查询。这首先需要通过网关信息获取映射关系。即traceId1->traceId2。然后使用这两个 traceId 在各自的域中进行搜索。

　　3. 现有能力

　　通过对原有飞云日志快速排序功能的改进和访问成本的提高。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 log查询traceid，再通过traceid查询明细。

　　4.2 归档能力

　　在构建整个架构时，我们还考虑了成本因素。在降低成本的同时，我们缩短了存储时间。但是，缩短存储时间必然会导致对历史问题的排查能力不足。因此，我们也提出了归档能力的建设。

　　在 sls 的 logstore 中，可以配置数据下发： . 这一步其实就是讲sls中的信息，存到oss中。通俗的讲，就是将数据库表以文件的形式保存，删除索引的能力。在交付过程中将执行加密。目前，Xlog 支持在界面下载和归档日志，然后在本地搜索。

　　后期可以根据需要重新导入oss数据到sls，参考：.

　　4.3 异常日志扫描

　　借助之前的架构，其实可以清楚的知道每条日志的内容在哪里，可以准确的查询到记录错误日志的文件内容。因此，每10分钟进行一次检查，汇总各个应用程序中的异常日志，获取此期间异常信息的数量。然后通过之前的对比就可以知道是否有新的错误，爆炸错误等等。

　　如上图所示，获取所有异常日志后，会按照规则计算md5。堆栈类型和异常日志类型对这两种类型有不同的算法，但本质目标是相同的，都是计算最有可能被重读的段落的md5，然后进行聚类。聚类完成后，可以得到差异并进行比较，从而判断是新增还是突然增加。

　　5. 规划

　　目前，Xlog的基本组件和功能已经实现。在各种应用和域的访问中，整个环节会越来越完整。接下来，将补充全链路、视觉检查、智能检查和问题发现。

　　6. 使用和共建

　　参考很多其他团队对采集结构、日志格式、查询方式、呈现方式的要求，降低了访问成本，提高了定制化。满足条件的团队，可轻松接入

　　对于一些特殊或定制化的需求，Xlog预留了扩展模块，方便共建。

　　如上图所示，图中绿色的组件是可以复用的，只需要为自己的领域定制结构和跨域映射即可。只需要根据定义的策略模式的接口来实现即可。

　　‍

　　参与话题互动赢阿里科技定制口袋！

　　互动文章：《6大论坛，30+技术话题，2022首届阿里巴巴开源开放周来了！》

　　好的技术文章

　　灰度接口迁移方案千万级可观测数据采集器 - iLogtail 代码完整开源全链路压力测试：影子库与影子表之战 全链路灰度 数据库上怎么做？

　　企业案例

　　企业上云| 阿里云长春数字化转型经验分享：助力“专、专、新”，数字科技伴随企业成长

　　云柱

　　三星堆梦幻之旅：只有云计算才能带来的体验，不仅可以在路上，还可以提供良好的服务：自动驾驶产品的规模问题，定义了自动驾驶，未来的移动智能载体？如何提出关键问题，支持10万人同时在线互动，是实现元界的基本前提？返回搜狐，查看更多