日志服务SLS_个人页_阿里云开发者社区

基于IoT全链路实时质量-魔洛哥

1 背景伴随着物联网(IoT)的快速发展，软硬件交互场景越来越普及，在自用和商用的空间场域中，我们智慧园区、未来酒店的智能化场景也得到了极大的丰富，打造出多款智能有科技感的产品，如人脸门禁、云前台、入住自助机、无线AP、云打印等等。空间域中围绕“人”、“设备”、“空间”打造的“智能化场景”有着特殊的物理空间上的分散和连接，硬件终端的异地分散部署、终端与云端（或边缘端）的连接通信，服务端-云端-硬件终端的远程指令控制等。物理空间上的分散和连接，增加了监控运维的难度，时常出现用户的各种问题反馈：设备离线固件升级后服务不可用终端应用升级后服务不可用卡死、白屏、样式错乱业务功能异常、服务异常上游依赖应用系统服务异常基于阿里巴巴最佳实践打造的智慧园区和未来酒店产品，已逐步走向商业化输出，问题也从内部用户反馈扩大到外部客户反馈，如果问题总是通过客户反馈才能被动感知到，必然会导致客户对我们的产品逐渐失去信心。如何才能变被动为主动，使得运维、开发和测试同学具备感知线上问题、诊断定位根因、快速应急止血的能力，是一件很必要的事情。附拓扑结构图2 核心问题&挑战基于IoT打造的交互场景，从部署架构看，除了长链路的特性外，还有大规模分散部署的硬件终端，以及跑在终端上的软件系统。通常来说，智能终端软硬件交互系统是交付和长期运维的重难点，一方面存在硬件的不同厂商、不同型号、物理性损耗、ROM升级、摩尔定律等引发的五花八门的偶现问题，另一方面存在软件升级、依赖不可用等引发的重大问题。我们从日常具体问题中抽象提炼出2大核心问题：终端问题难感知：终端日志缺失、偶发难发现、质量度量视图缺失长链路问题难定位：质量分析模型不准确、端到端的日志断连全链路日志和质量度量视图，是解决问题的关键所在。但要在智能终端软硬件交互系统中建设全链路日志和通用质量度量视图有一定的挑战，具体挑战如下：3 解决方案基于IoT的智能终端交互系统，设备终端一般由交付同学来运维和升级，终端软件由客户端开发同学运维和升级，服务端由后端开发运维和升级。系统问题可能发生在硬件终端上、可能发生在终端应用软件上、也可能发生在服务端依赖上。多职能角色的协同，长链路的调用，导致问题“发现-定位-止血”的耗时远高于纯软件系统。结合日常问题的分析经验，我们期待的问题发现定位方式是：首先能够实现终端问题的快速准确感知，其次基于业务场景指标呈现质量概览，并通过不同维度的质量分析模型进行下钻，最终通过全链路的调用日志明细确定根因。这样从业务场景出发，发现异常问题，串联全链路，任何职能角色都可以方便易懂的感知，关注和分析系统质量情况。同时我们的解决方案要满足以下要求才能真正的解决用户的难度和痛点。针对上述的问题解决方式和要求，通过调研分析发现集团内普遍存在服务端应用的长链路监控预警和分析诊断工具，但串联终端应用在内的端到端的长链路诊断分析工具比较少。终端应用和服务端应用使用的技术栈差别很大，即使在同一个业务场景的逻辑实现中，日志也是独立埋点的，调用链路也是断开的。要建设一套各种技术栈兼容的通用埋点工具成本很高，经过内外部的多方调研，我们选择在自有业务中引入“狄仁杰”——它是专注于业务场景的全链路日志分析，轻量级的sdk接入，通过一行代码即可将系统中基于slf4j接口的业务日志全部用鹰眼traceId串起来，还支持“业务场景”语义的标识传递，可实现从终端到服务端的全链路染色。使用狄仁杰将日志进行全链路串联后，一键接入基于IoT的实时质量工具魔洛哥，可实现基于专家经验设计的业务质量大盘等质量视图，以及自动配置的终端异常感知预警模版，整个方案采用魔洛哥产品化接入和数据服务（参考5.2 数据服务）的能力实现不同产品通用质量视图的分钟级创建，同时根据质量大盘指标自动配置预警规则和模版，做到终端异常的实时准确感知和问题的快速定位分析，整体方案如下：整体方案以上2个核心问题的解决方案，已在“魔洛哥”承载的多个业务产品中应用实践，详见4.1和4.2。为了支撑不同IoT产品的实时质量建设的差异化诉求，“魔洛哥”平台本身的基础能力也在持续打磨中。4 “魔洛哥”中的落地策略&最佳实践4.1 终端异常感知智能终端系统由于其特殊性有很多偶现性的"疑难杂症"，同时"疑难杂症"难发现难定位。经过分析发现导致这一问题的两个因素：基于终端的质量度量视图缺失（终端链路质量，终端设备质量等）智能终端多职能角色的协同（客户端开发、前端开发，算法开发，硬件开发，硬件供应商，硬件部署运维团队等）因此我们需要一种工具能够像服务端的Sunfire、云监控、eagleeye工具平台一样，能够快速感知智能终端异常，同时精准定位出异常的链路模块，使得异常模块的负责人可快速的进行问题的接手和处理。通过调研我们开发了基于IoT的实时质量工具-魔洛哥，针对智能终端异常难感知采用了以下策略：智能终端监控预警通过基于专家经验定义终端系统的异常指标来实时监控异常并触发预警。首先将种类繁多且分散的智能终端系统日志进行SLS云化存储，其次借助魔洛哥平台的数据服务能力，直接通过SLS编写指标查询SQL来生成HSF/HTTP服务，最后使用魔洛哥平台配置基于专家经验且通用的终端预警模版和规则，最终实时匹配预警规则产生告警。魔洛哥平台详细实践操作流程如下：智能终端实时质量首先智能终端系统存在多角色的协调，一旦发现了终端异常后，需要多角色参与进行分析，导致问题的止血时间较长，因此我们需要一种工具除了能够反馈终端异常外，还能返回终端链路的过程质量，使得问题发生后，通过链路模块实时质量，能够精准的感知到异常链路模块，以此来提升异常的感知能力。其次智能终端系统还存在很多偶发性问题，而偶发性问题很难触发预警，但确非常影响用户使用体验（例如一台门禁设备人脸识别成功率低，导致高峰通行时段极差的通行体验），因此也需要一种工具能够及时透出偶发的设备异常问题，通知运维或者开发同学进行优化，提升终端用户的体验。综上分析，我们需要提供一种标准化的运维工具，将终端硬件和系统的质量情况实时透出，帮助开发和运维同学快速感知问题，首先将种类繁多且分散的智能终端系统日志进行SLS云化存储，然后定义出基于硬件智能终端的链路质量度量模型，借助魔洛哥平台的数据服务能力，直接生成基于智能终端系统的实时质量。详细方案如下：魔洛哥平台详细实践流程如下：4.2 基于业务场景的全链路实时质量通用实时质量视图实时质量的度量分析已经存在很多成熟的产品，比如主要用于服务端的Sunfire、云监控、eagleeye和用于前端的体验+等，那为什么我们不直接使用这些平台，而要着重提到基于业务场景的全链路实时质量呢？在我们实践业务质量保障的过程中，发现单纯的服务端和前端实时质量度量及监控不能完全满足我们想从用户实际体验的角度来度量和发现质量问题的诉求，主要体现在以下方面：产品视角维度：割裂的服务端和前端实时质量，从技术栈上就天然的把产品分开了，但是对于用户来说，不论是服务端问题、前端问题或者设备问题，都可能造成用户有损的体验。因此，我们需要一个和用户视角一致的维度来"看见"产品的质量。业务场景视角维度：举个例子，用户在长链路场景中，会访问多个前端页面和服务端接口，前置步骤操作成功(包含接口及页面)是最终业务成功的必要条件。按照比较常规的做法，我们会去看最后一个接口的成功率，但是这样就过滤掉了前面失败的用户。优化一下，我们用最后一个接口成功的数量比上业务起始接口的调用数量，但是如果前端出现了一些不影响流程但是确实影响用户体感的问题(比如：最后一个接口调用成功跳转的提示页面展示错误)，也就无从感知了。因此，我们需要一个涵盖前后端的业务场景质量视角。当然，除了我们定义的产品视角和业务场景视角，基础的服务端和前端应用视角对于完整的质量全方位保障也是必不可少的，所以我们提炼了如下产品模块：产品质量概览：从业务场景入手，通过业务实时成功率，平均耗时以及日环比和周环比来反馈业务的整体质量情况；同时产品质量概览中细分出了服务端和前端实时质量概览大盘，服务端和前端质量主要是通过展示应用的接口调用成功率和耗时来进行实时质量的反馈。通过点击详情可以对单应用的质量指标进行详细分析。业务场景质量：业务场景的实时质量情况，以及异常的页面列表和错误码分布，同时根据错误码进行明细日志查询，最后进行全链路Trace分析。服务端实时质量：基于单应用一段时间内的服务端质量情况，包括接口异常率，异常率趋势，异常API分布等，通过异常API分布情况可进行异常API的详细分析，包括耗时和错误码分布等，根据错误码分布可直接进行明细日志查询，以及全链路Trace查询。前端实时质量：基于单应用一段时间内的前端质量情况，包含API，JS等的异常数，以及异常页面排行。业务应用实践使用狄仁杰埋点的业务，一键接入魔洛哥，分钟级透出通用实时质量视图，包含产品质量、业务场景质量分析、服务端质量分析、前端质量分析、质量查询、多维分析（建设中）等，目前菲住布渴、餐配中台等多个业务已经接入使用。菲住布渴产品在接入平台后，经过对业务场景数据的分析发现：在小程序入住办理场景中，真正能走到最后一步且成功的用户占比很低，很多用户被前置流程的规则阻断了。再深入下去，发现酒店房间未准备好的问题最多，反馈业务方之后，正在进一步讨论优化方案。餐配中台在接入平台后，经过对业务场景数据的分析发现消费退款失败较多，一部分失败是因为在之前就餐消费失败时，会直接去调退款接口，近期迭代做了优化，代扣结果未返回支付成功便直接异步调用撤销支付请求，并返回代扣失败。订单实际上支付未成功，因此去调用退款接口无可退订单，导致大量退款异常。另一部分失败是因为查询到订单状态是否支持退款的逻辑判断不精准，部分订单状态无法调用退款。5 技术架构根据上述的目标，在业务接入时，我们需要实现低成本快速接入，同时展示业准确的全链路实时质量情况，因此从技术角度出发要解决的问题有三点：低成本快速接入实时数据全链路指标串联根据上述的三点，从技术实现上来说有一定的复杂度，首先要解决实时性，其次要能够将全链路日志进行串联，最后还要实现低成本接入，最终通过一定的调研分析，整体的技术方案如下：5.1 狄仁杰为了能够将全链路指标进行串联，我们需要在业务应用中引用狄仁杰SDK，通过一行代码即可将系统中基于slf4j接口的业务日志全部用鹰眼traceId串起来，并将收集到的日志发送到应用自定义的SLS中。5.2 数据服务为了降低接入成本，我们开发实现了基于SLS的数据服务工具，通过一条SQL即可将SLS数据查询结果生成一个可调用的API。数据服务能力参考了DFaaS（Data Function As Service）的数据服务能力，提供数据函数即服务，使用户无需编码而直接可生成服务，降低研发门槛、实现低成本接入，使得开发同学更快捷、持续的交付业务以及产品需求。6 总结和展望通过基于IoT的全链路实时质量，业务使用狄仁杰进行全链路埋点后，可一键接入魔洛哥平台，实现终端问题的实时感知和链路分析，以及智能终端系统业务场景的全链路实时质量。整体方案接入成本低（分钟级别接入），可实现全链路的实时质量分析，以及精准的终端预警能力。帮助开发运维同学实时发现问题，快速问题的定位分析。但目前整体方案还在持续建设中，还有部分能力需要持续进行迭代优化：离线加速：目前采用的数据服务直接调用sls SDK进行全链路日志实时查询以及生成可调用API，对于数据量较大的业务（亿级数据量的查询）查询时间较长，正在优化中，预计本月底可上线预警规则模版自动生成：业务接入魔洛哥后，直接具备基于专家经验配置的预警模版和规则，该方案还在迭代实现中，预计下个月可上线多维分析：基于业务场景任意指标和维度的分析能力，目前正在开发实现中。

阿里本地生活全域日志平台 Xlog 的思考与实践

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/document_detail/371924.html。这一步操作其实是讲sls中的信息，存储到oss。通俗的讲，就是把数据库的表格，用文件的形式保存下来，删掉索引的能力。在投递过程中会进行加密，目前Xlog支持了在界面上进行下载归档的日志，然后在本地进行搜索。后续可以按需将oss数据重新导入到sls，参考：https://help.aliyun.com/document_detail/147923.html。4.3 异常日志扫描借助于之前的架构，其实可以很清晰的知道每条日志的内容部分是哪里，也可以精准的查询出记录了error日志的文件内容。所以每10分钟巡检一次，将每个应用中的异常日志聚合起来，就可以获取到这段时间异常信息的数量。然后在于之前的比较就可以知道，是不是有新增的错误，暴增的错误等等。如上图所示，拿到所有异常日志后，会按照一个规则进行md5的计算。堆栈类的和异常日志类的，针对两类的算法不同，但是本质目标是一样的就是取其中最有可能重读的段落计算md5，然后进行聚类。聚类完成之后，就可以获取差异，进行比较，从而判断是不是新增或者暴增。5. 规划目前Xlog的基础组件和功能已经实现完毕。在各个应用和域的接入中，整个链路将会越来越全。接下来将向全链路，可视化排查、智能排查和问题发现方面进行补充。异常定位辅助：在可视化链路上，将含有异常的应用标红，方便快速查到错误日志。线上典型问题聚合：日志巡检。线下错误捕获护航：在业务测试的时候经常不会实时的查看日志中的错误信息，开启护航模式，将舰艇应用错误，一旦线下执行过程中出现，将会推送。信息查询：与钉钉打通，用于快捷查询。钉钉@机器人，发送关键字，钉钉将最近执行结果返回。智能排查：@钉钉输入traceid，订单号等，返回检测到的异常应用和异常栈。业务流程编排核对：允许应用日志流程编排，根据关键字串联的链路流程日志需要满足一定规则。用此规则进- 核对。=>针对实时性要求不高，仅对流程进行验证。发布门禁：线下用例回放无业务异常，线上安全生产无业务异常=> 允许发布6. 使用与共建参考很多其他团队的采集结构、日志形式、查询方式、展示样式的要求，在接入成本上降低和自定义方面进行了提升。针对已经满足条件的团队，可以方便的接入。针对还有一些特殊，或者定制化的需求，Xlog进行了拓展模块的预留，方便共建。如上图，图中绿色组件均可复用，只需要针对自己的域进行结构自定义和跨域映射自定义即可。只需要根据定义好的策略模式的接口进行实现即可。

日志服务SLS_个人页

个人介绍

擅长的技术

基于IoT全链路实时质量-魔洛哥

阿里云数据存储生态计划发布，助力伙伴数据创新

阿里本地生活全域日志平台 Xlog 的思考与实践

Exabeam的UEBA调研

New Relic 可观测平台调研

浏览器端 RUM 调研

三款“非主流”日志查询分析产品初探

SLS控制台日志下载功能全新升级

阿里云日志服务SLS携手观测云发布可观测性解决方案，共建可观测应用创新

基于IoT全链路实时质量-魔洛哥

阿里云数据存储生态计划发布，助力伙伴数据创新

阿里本地生活全域日志平台 Xlog 的思考与实践

Exabeam的UEBA调研

Session Replay产品调研分析

New Relic 可观测平台调研

浏览器端 RUM 调研

三款“非主流”日志查询分析产品初探

可观测公司新秀：OpsCruise介绍

从50家值得关注的数据领域创业公司，简单解读“最新数据基础设施”

SLS控制台日志下载功能全新升级