日志服务SLS焕新升级：卓越性能、高效成本、极致稳定与智能化
内容介绍：
一、日志服务的新功能特性分享
二、Project回收站功能介绍
三、ELasticsearch兼容方案与日志服务优化
四、日志服务全链路数据处理能力提升
五、案例分析
本次分享的是日志服务还支持扫描计算模式，能够在兼容方案里面去使用，这样可以达到一个更好的成本效果。通过数据加工把客户不同端之间的数据完成了一个孵化串联，实现了一个全链路的数据处理的能力。
一、日志服务的新功能特性分享
分享日志服务在近期的一些新功能特性。通过刚积分的介绍，大家对于可观测也有一定的了解，然后日志服务的话是一站式的原生可观测的数据存储分析的平台是可观测的数据底座。我们也发现可观测在随着各个行业可数字化的经营程度的不断加深的过程里面，其实受到了越来越多的重视，同时技术领域也在不断的成熟。
在近期我们发现可观测呈现四个大的趋势。
第一趋势是整个的协议在标准化，随着 Open TeLemetry 的协议的推出，现在越来越多的厂商在兼容和适配 Open TeLemetry 协议。
第二趋势是数据统一化是在协议标准推出的基础上，数据的格式在不断的统一，同时也在往统一存储统一接入以及统一处理的方向上发展。
第三趋势是数据类型的丰富化，随着EBPF等技术的推出，可观测的数据类型在不断的丰富，同时它的数据量级也在不断的增长。
第四趋势是数据分析智能化，在AI的加持下，可观测的数据分析在往自动化和再往自动化和智能化的方向发展，日志服务是一站式的原生可观测数据分析平台，它一站式的支持的可观测的 Log 、Trace 以及 Matric 数据的统一接入统一处理和统一分析的能力。
同时也支持了一站式的从数据采集到数据加工到数据分析到可视化到告警到投递分析这样一站式的数据，全电路社会数据生命周期的能力。现在看到的是日志服务的简单功能架构图，从下往上开始看最下方是日志服务目前支持的两种后付费的计费方式，按功能计费是按照实际使用到的功能计费按写入量计费的话是按照数据写入量计费。
在此模式中，对于日志服务的一些真实能力，比如说数据加工是不会产生额外的费用的，适合于有一些复合型需求的一些客户场景。再往上一层是数据采集以及电路层，包含了支持丰富数据源的采集能力，以及通过数据写入处理器。数据加工以及规则消费形成的全链路的数据处理能力，数据写入处理器支持的数据写入日志服务之前的数据处理能力。数据加工是数据落盘后的数据处理能力规则，消费是数据读出之前，也就是在消费路径里面的数据处理能力，他们共同构成了日志服务目前全链路的数据处理能力。
再往上一层是日志服务的存储平台层日志服务目前支持热低频归档三类型的存储层，用户可以根据它的数据存储周期，以及对于延迟的容忍度，选择合适的存储层。
同时，日志服务也支持标准型以及查询型两种格式的 Long Stone 并且分别对应查询分析的场景，以及查询比如说 TroubLe Shooting 的场景。今年日志服务也即将推出 Project 回收站的功能。Project回收站可以有效的防止重要 Project 误删的情况，再往上一层是计算引擎日志服务，目前的话是支持两种模式，第一种模式的话是索引计算模式，通过索引的加速日志服务，目前能够支持千亿级数据的秒级查询。同时，日志服务也支持扫描的计算模式，无需预见索引，可就可以通过扫描的方式实现查询和分析，适合于一些低频查询分析的场景。
再往上一层目前日志服务也在基于大模型去做一些新的数据探索范式的摸索。我们基于通用模型训练，基于日志还有持续的垂直化场景基础模型同时以CopiLot作为载体。实现新的数据探索的方式，可以通过自然语言交互的方式进行数据的探索。最后的一层是应用层，包含了所有以日志服务作为底座的场景化应用，包含了已经提过的可观测家族里面的云监控ARMS、Prometheus、RUM全站可观测以及针对云产品观测的CLoud Lens应用,针对安全场景的日志审计应用等等。通过简要的功能架构，日志服务在今年其实是围绕在降低使用门槛，使用成本，提高性能，以及能够提高可靠性，同时探索的范式进行迭代和演进。
二、Project回收站功能介绍
接下来将展开它的功能，Project回收站可能在10月份跟大家见面的。Project回收站可以有效的防止重要Project的误删情况。Project回收站的需求背后是我们收到了很多的用户反馈，包括一些工单或者说直接联系他由于各种原因，比如说他是一些误删除，删掉了一些重要Project时候，他希望通过各种方式帮他找回数据，但是在之前的逻辑里面，其实日志服务如果说大家通过二次确认去删除掉了，Project是真正的去执行了数据删除的操作是没有办法去进行找回的，但是在Project回收站功能推出之后，问题就可以能够有比较有效的防护方式，建议大家对于所有的Project都开启重要的Project都开启回收站的能力，开启了Project回收站的Project在执行删除指令的时候，会先将Project放到回收站中，进入回收站的Project，它会进入静默下线的状态。静默下线代表Project是没有办法进行任何读写的，同时，它的所有作业，包括所有的加工投递，下载的作业都会进入暂停的状态。
静默状态如果说一旦有任何的业务跟Project有依赖，就会很快的发现这报错，就可以通过回收站的恢复功能把Project状态进行恢复，它的读写状态以及所有的作业状态都会恢复到运行态。Project回收站可以通过Project属性页面去启停，同时在进入Project回收站的Project默认保存七天。如果明确没有任何的业务依赖的话，也可以再次执行删除的指令，把Project彻底删除掉，Project回收站的功能没有任何的额外费用。如果我们的Project开启能力，但是没有进入删除状态的话，不会有任何的影响。删除后的Project也只对于这些数据保存下来的存储去进行计费。扫描查询是日志服务在去年推出的能力，它是Schema on Read的一种计算模式，不去预见索引就可以通过扫描的方式去做查询和分析，适合一些Schema的数据场景，以及说一些落低频查询的分析场景。今年我们通过数据模型的优化以及算子的下推，对于扫描性能进行了大幅度的优化，目前已经达到了单单能够达到1GB以上的扫描性能，此性能基本上说能够通过时间戳一些索引字段的过滤，把数据范围缩小的话，是能够提高延迟体验。
三、ELasticsearch兼容方案与日志服务优化
这种功能推出的背后实际上有很多客户一份日志里面可能不同的字段，他的查询频次以及需求是不一样的，有一些字段是高频查询的，有一些字段可能是低频查询的，客户有一些查询的需求，所以通过这样的方式能够给大家提供更高性价比的方案。我们来假设现在有一份日志，它有两个字段，其中的字段是 Request ID 字段，另外字段是Message字段。
其中 Request ID 字段经常会在运维过程中使用到 Message 字段里面有部分的关键字，在部分问题里面也是需要的时候可以通过对于 Request ID 字段去创建索引，然后对于 Message 字段通过扫描的方式去做查询分析，通过这样的组合兼顾效率与成本，通过时间戳是因为我们一般问题都有明确的时间范围，我们通过时间戳以及 Request ID 字段把需要的 Message 圈选出来之后，其实是可以把我们需要扫描的数据量圈选在非常小的范围中。
一方面整体的扫描延迟能够得到比较好的保障。
另外一方面，整个的扫描消耗的计算成本也会非常的低。ELasticsearch 兼容是因为目前开源的ELasticsearch还是一种比较主流的方案，我们其实也收到了很多的客户反馈，他们可能已经使用很多年ELasticsearch自建的方案。他们对于ES的DSL用法很熟悉，同时也有很多的仪表盘放在Kibana或者Grafana上，在使用的过程中，可能由于各种各样的原因，比如说集群规模，成本，查询性能等各种方面的原因，会导致他们可能需要迁移到日志服务里面。那在迁移的过程中，他们可能会遇到DSL语法，需要重写 query ，以及说他们的很多的仪表盘需要去迁移的问题。在此情况之下，我们去让大家比较友好的去做迁移动作，推出了ELasticsearch的兼容方案，通过兼容方案，可以在把日志服务作为平台存储计算底座的情况，不需要去修改的ES的DSL语句，同时新的语句也可以继续通过语法书写，同时我们也兼容了Kibana跟Grafana的报表，能够无缝的去迁移，在此之前编写好的这一些报表，从去年推出功能，到现在跟客户一起不断的去迭代跟完善，目前已经基本上做到了能够百分百的去兼容ES的方案，已经累计支持的数百家客户无缝去迁移他们的自建ES，迁移了大概数万张的仪表盘。社区兼容方案目前根据客户反馈，整个的成本降幅可以达到30%以上。同时今年也支持了扫描计算模式，能够在兼容方案里面去使用，这样可以达到更好的成本效果。
数据级Store功能是今年日志服务重磅发布的功能，功能主要实现的是跨地域跨Kibana的查询分析的能力，我们接触的很多客户的业态也是这样的模式，可能是多地域部署的业态，甚至是全球的业态，在这样的业态下，不管是基于合规的考虑，还是基于成本的考虑，通常都会把数据落盘在本地，那这样就会导致问题，当有些时候需要去做全局的。
聚合分析的时候，经常需要在本地把这些数据聚合完之后再做一次二次的人工聚合。过程其实相对来说是比较麻烦的，那当Store View的功能推出之后，可以通过来创建视图关联多个Store View，这些Store可以是同地域的Store也可以是跨地域的Store。剩下所有的查询分析的操作都可以在Store View的视图里面去实现。我们来看具体的例子，现在有两个Lock Store，这两个Lock Store分别是在北京和上海地域这两个Low Store里面的话都有Request ID和message的字段。如果我们想要去查询某Request ID的所有的日志，在Store的视图里面，它会把跨地域的两个Store的所有数据在同视图里面去展示。如果需要去统计Request ID里面的字数也可以通过Store view去做全局的聚合，就是目前能够带给我们的全局视角的查询分析的能力。Store view目前已经支持了查询的能力也即将支持分析能力，能够同时支持我们的日志型的Store view，也能够同时支持持续型的matrix。大模型的出现给各行各业都带来了很大的变化，在可观测领域，大模型其实为我们提供了更多的数据探索的方式，也可以辅助我们更好的去解读数据。
四、日志服务全链路数据处理能力
在这一方面，日志服务其实做了以下几个事情。第一事情的话是我们通过通易的大模型，基于日志数据还有时序数据的特点训练，属于可观测的日志还有时序的基础模型，同时通过微调的方式解决了多模态数据融合的问题。另外基于可观测团队自主研发的U modeL系统将可观测实体之间的数据关联关系变成了具象化的实体关系，可以通过同接口去解读不同的数据之间的实体关系。具备这两个条件便已经有了基础模型，也具备数据之间的关联关系，我们就具备了让AI帮我们解读数据的基础能力。
日志服务以CopiLot作为载体，通过多Agent协作的思想，利用它的工具专注的去解决某领域里面的问题去减少幻觉的产生。通过这样的方式，已经实现了这个设想。在比如NLC安全领域以及根因分析领域的各种场景的数据探索的能力。通过这样的方式，能够为大家带来更好的数据探索的效率以及更好的体验。
全链路的数据处理能力是在日志服务原先的数据加工的能力上的增强。今年一共发布了三个功能，构成全链路数据的处理能力，首先是数据写入处理器处理的是写入日志服务之前的数据,是服务端的处理能力，所以大家不需要去关心数据处理能力会不会消耗客户端的一些资源，通过这些能力可以对日志落盘之前的数据进行比如说过滤，脱敏这样子的效果，假设我们现在可能是运维同学，我们对接的公司十几个业务方时，我们可能有业务方的同学，他写了日志，日志里面有十个字段，这十个字段里面只有三个字段是有效字段，其中的七个字段是无效字段。在以前我们要去解决问题，可能需要去电话会议，然后去把业务方的同学拉上来去告诉他，这样打日志会造成我们运维时很困难，因为很多的字段无效，会导致整个的查询性能降低，也可能会导致我们的成本大幅度的增加，需要他们去改一下代码去把日志的输出格式给换一下。然后时候通常我们的业务方同学会跟我们说东西他们需要排期，整个推动起来会很困难。如果说业务在高速发展的情况下，事情可能也不在他们的主路径里面，这样推动就会特别困难，现在我们有了数据写入处理器之后，我们就多了一种选择，可以选择把数据在写入日志服务之前，通过规则把其中的七个无效字段过滤，可以大幅度减少真正落盘到日志服务里面的数据量，很大幅度的减少成本，数据加工。今年推出了新版本，做了很多的优化，基于新版数据加工的计算引擎，首先我们解决的是处理效率的问题，通过新版引擎，对于数据加工的处理效率有大幅度的提升，目前已经达到了TB级，每分钟处理性能够大大的缓解在大规模数据处理场景下面的延迟问题。同时以前的数据加工的语法，现在已经合并成了日志服务统一的SPL的语法。数据写入处理器查询采集规则进行统一嵌套式的语法更容易编排，也能更容易去上手。另外在数新版数据加工里也进一步去把计算引擎的升级的红利做了释放，单GB的数据加工处理的成本消耗在新版本中，相比于旧版本下降了60%。
最后规则消费是数据读出之前的处理能力，因为经常会遇到客户需要把数据导出到下游的一些大数据的平台里面去做一些离数据计算。而大数据的平台对于数据Schema on Read通常都会有一定的要求。可能需要把数据读出之后，在一些其他平台里面去做处理，现在可以通过规则消费，先把数据处理好，然后再去读，一方面可以去减少下游的一些计算性能的消耗。另一方面，如果说有一部分数据能够去过滤掉的话，也可以去减少中间传输的网络成本。
接下来看例子，现在有一份数据，这份数据里面有200状态码的正常日志，也有500状态码的异常日志。此时可能出于成本的考虑，只希望把异常的日志给保留下来，此时通过数据写入处理器，把200状态码的数据过滤，同时丢弃。只把500状态码的数据落盘，这样对于整个数据量级是会有非常大程度的减少，可以去减少需要的成本。
在真正数据使用的过程中，可能会有一些客服的同事，需要拿数据给用户排查问题，可能就需要能够去把日志和用户的USER ID关联，此时可以用数据加工的功能把可能存在mysqL里面的一些USER ID孵化出来之后，运维同事就可以去拿到一份完整的数据，能够去更好的给用户解决问题，数据在最后可能还需要去落盘到我们的一些离线系统里面做进一步的处理。与此同时USER ID作为用户的信息，正常来说是属于敏感数据，并不希望它在系统中流转，所以可以通过规则消费把数据给脱敏，或者将它过滤。通过三个能力的组合，组成目前的日志服务全链路的数据处理的能力。
五、案例分析
最后介绍客户案例，客户是我们国内top的车企，对使用日志服务之前，可能是通过自己的方式实现一套系统。那在这一套系统中，他们遇到了一些问题，第一个问题，就是他们的整个的数据量大了之后，查询延迟比较大，同时成本也比较高，另外每天采集的数百TB数据并不稳定。在此过程中，还遇到数据分析，目前来说是一代的是BI的系统，所以有T+1的数据延迟。
另外，整个的运维团队的能力也是比较紧张的，所以真正要去优化这一套系统对他们来说代价比较大。日志服务其实是给他们提供了一套完整的解决方案，我们通过LoongCollector采集器部署了数万个节点的LoongCollector的Agent满足用户每天数百TB数据的采集。同时能够做到不丢不错，同时也通过专线的方式把客户不管是在专有云，私有云还是在公共云上的数据全部落盘到就近的日志服务的集群里，并且通过Store view实现了全局数据的统一的查询的方式。最后，我们通过数据加工去把客户不同端之间的数据完成孵化串联，实现全链路的数据处理的能力。
通过日志服务的这一套方案数，客户相当于实现了跨云跨地域，并且是跨服务端，跨app端，跨车机端的全链路的数据处理能力，大大的去提高了用户对于问题以及一些异常情况下的处理性能。当然也是我们日志服务本身去做产品的初衷。
本次分享到此结束。
