五年双十一:SLS数据管道发展之路

  • 时间:
  • 浏览:0
  • 来源:神彩大发欢乐生肖_彩神大发欢乐生肖官方

SLS 第一版本支持一类数据源-- 飞天格式的日志文件,在五年中逐步扩展到各语言SDK,移动端,嵌入式芯片,物联网和云原生等环境:



管道好多好多 概念非常简单,以至于每个开发者都能用20行代码写如果原型出来:

补救日志消费疑问报告 还是还要从应用场景出发,SLS作为实时管道,绝大偏离 消费场景都是实时消费,SLS针对消费场景提供了一层Cache,但Cache策略单一,随着消费客户端增多、数据量膨胀等疑问报告 而原因命中率越来越 低,消费延迟越来越 高。如果亲戚亲戚我们我们我们儿重新设计了缓存模块:

SLS服务端支持HTTP协议写入,也提供了众多SDK和Agent,但在好多好多 场景下还是和数据源间有巨大鸿沟,這個:

自动负载均衡

SLS从源身旁禁止同一文件的重复埋点,日志统一埋点到SLS后,亲戚亲戚我们我们我们儿为用户提供ConsumerGroup用于实时消费。但伴随着日志的细分化以及日志应用场景的富足化,SLS的数据消费逐渐暴露出了如果疑问报告 :

SLS起源与阿里云的飞天项目,当时亲戚亲戚我们我们我们儿飞天有如果基础的日志模块,几乎所有的系统都是使用好多好多 模块打印日志,好多好多 最刚开始了了亲戚亲戚我们我们我们儿开发了Logtail用于埋点飞天日志,当时的Logtail还可是如果阿里云飞天系统内部人员使用的工具。

亲戚亲戚我们我们我们儿对Agent(Logtail)进行了一系列多租户隔离优化:

在阿里深层虚拟化的场景中,一台物理机将会运行上百个容器,传统的日志落盘埋点最好的办法对物理机磁盘的竞争很大,会影响日志写入性能,间接影响应用的RT;一块儿每天物理机还要为各个容器准备日志的磁盘空间,造成巨大的资源冗余。

如果 亲戚亲戚我们我们我们儿和蚂蚁系统部合作协议开展了日志无盘化项目,基于用户态文件系统,为应用虚拟出如果日志盘,而日志盘的身旁直接通过用户态文件系统对接Logtail并直传到SLS,以最快的最好的办法实现日志可看、可查。



随着非阿里云团队使用,好多好多 亲戚亲戚我们我们我们儿扩展了Logtail,支持通用的日志格式,比如正则、Json、分隔符等等。一块儿还有好多好多 应用不希望落盘,如果 亲戚亲戚我们我们我们儿提供了各种语言的SDK用于日志上传的代码集成。

随着移动互联网兴起,亲戚亲戚我们我们我们儿专门针对移动端开发了Android、IOS的SDK,便于用户快速接入日志;好多好多 时间点阿里也刚开始了了了微服务改造、pouch刚开始了了上线,Logtail刚开始了了兼容pouch,一块儿亲戚亲戚我们我们我们儿还专门为Java微服务提供Log4J、LogBack的Appender,提供数据直传的服务。

对ARM平台、嵌入式系统、国产化系统也定制适配客户端进行接入。



针对热点疑问报告 ,亲戚亲戚我们我们我们儿在系统中增加了调度角色,通过实时数据埋点和统计后,自动做出调整,来消除系统中居于的热点,主要有以下如果手段:



针对单消费者能力不足的疑问报告 ,亲戚亲戚我们我们我们儿对ConsumerGroup进一步增强,开发了Fanout消费模式,在Fanout模式下,如果Shard中的数据可交由多个消费者补救,将Shard与消费者解耦,彻底解生产者消费者能力不匹配的疑问报告 。一块儿消费端不会关心Checkpoint管理、Failover等细节,Fanout消费组内部人员详细接管。

传统的最好的办法粗暴简单,还要日志的人个人去机器上埋点,最终一份日志将会被重复埋点几十遍,严重浪费客户端、网络、服务端的资源。

SLS对外SLA承诺99.9%服务可用性(实际99.95%+),刚开始了了的如果亲戚亲戚我们我们我们儿越来越达到如果的指标,每天收到好多好多 告警,一直深夜被电话Call醒,疲于补救各种疑问报告 。总结下来主要的原因有2点:



为此SLS开展了通用协议适配计划,除HTTP外还兼容Syslog,Kafka、Promethous和JDBC五种协议来兼容开源生态。用户现有系统只还要修改写入源即可实现快速接入;已有的路由器、交换机等能也能直接配置写入,不会代理转发;支持众多开源埋点组件,這個Logstash、Fluentd、Telegraf等。

和Kafka一样,SLS目前支持At Least Once写入和消费最好的办法,但好多好多 核心场景(交易、结算、对账、核心事件等)还要要求Exactly Once,现在好多好多 业务不到通过在上层包装一层去重逻辑来Work around,但实现代价以及资源消耗巨大。

在2017年前后,亲戚亲戚我们我们我们儿遇到了另外如果挑战:单机Agent的多租户流控,举如果例子:

在2018年初,为了应对繁杂的需求,亲戚亲戚我们我们我们儿为Logtail增加了插件功能,有自定义需求的用户能也能通过开发插件的最好的办法扩展Logtail,实现各种富足的功能;一块儿亲戚亲戚我们我们我们儿也紧跟时代步伐,支持云原生、智能设备、IoT等新兴领域的数据埋点

数据管道是哪几条?

为了便于水平扩展亲戚亲戚我们我们我们儿引入了Shard的概念(這個Kafka Partition),用户能也能通过分裂Shard、合并Shard来实现资源的伸缩,但哪几条概念也会为用户带来好多好多 使用上的困扰,用户还要去了解Shard的概念、还要去预估流量分配Shard数、好多好多 如果将会Quota限制还还要手动分裂...

亲戚亲戚我们我们我们儿在使用SLS中遇到的任何疑问报告 ,请加钉钉群,亲戚亲戚我们我们我们儿有专门的日志女仆24小时在线答疑,还有火锅哥和烧烤哥专业支持!~

借助此种最好的办法大大缩短了亲戚亲戚我们我们我们儿疑问报告 调查的时间,在报警时亲戚亲戚我们我们我们儿会自动带上根因分析结果,好多好多 如果收到告警时就将会也能定位具体是哪个用户、哪台机器还是哪个模块引发的疑问报告 。

另外欢迎对大数据、分布式、机器学习等有兴趣的同学加入,转岗、内推,来者不拒,请用简历狠狠的砸我!~

上述优化上线后,集群日志平均消费延迟从5ms降低到了1ms以内,有效缓解双十一数据消费压力。

Project全局流控最主要的目的是限制用户整体资源用量,在前端就拒绝掉请求,补救用户实例的流量穿透后端把整个集群打爆。真正做到流控更加精细、语义更加明确、可控性更强的是Shard级别流控。

实际场景下有好多好多 状况还要特殊考虑,這個颠簸状况、异构机型、并发调度、迁移的负面影响等,这里就不再展开。

该功能上线后,经过不断调优,较好补救了单机上多个数据源(租户)公平分配的疑问报告 。

数据管道概念诞生在5009年,提出的是LinkedIn工程师Jay Krep,Jay也是Apache Kafka作者+Confluent公司CEO。2012年他在文章《The Log: What every software engineer should know about real-time data's unifying abstraction》中提到设计管道设施的如果初衷:

如样例中,将出先错误(status >= 5000)的访问数据集,定义为异常集合A,在好多好多 集合发现90%的请求,都是由ID=50002引起,好多好多 值得怀疑,当前的错误和ID=50002有关,一块儿为了减少误判,再从正常的数据集合B(status <5000)中,查看ID=50002的比例,发现在集合B中的该ID比例较低,好多好多 更加强系统判断,当前异常和好多好多 ID=50002有非常高的相关性。

目前SLS线上埋点了数千种实时指标,每天的访问日志有上千亿,出先疑问报告 时纯粹手工调查难度非常大。为此亲戚亲戚我们我们我们儿专门开发了根因分析相关算法,通过频繁集和差异集的最好的办法,快速定位和异常最相关的数据集合。

马上亲戚亲戚我们我们我们儿会支持写入和消费的Exactly Once语义,且Exactly Once语义场景下也将支持超大流量和高并发。

如果例子每天都是居于,如可把简单的管道做得不简单,还要大量的工作,在下面篇幅中亲戚亲戚我们我们我们儿娓娓道来。

自动分裂

优秀的产品应该对用户暴露尽将会少的概念,未来亲戚亲戚我们我们我们儿会弱化甚至去除Shard概念,对于用户而言,SLS的数据管道只还要声明一定的Quota,亲戚亲戚我们我们我们儿就会按照对应的Quota服务,内部人员的分片逻辑对用户彻底透明,做到管道能力真正弹性。

但在现实过程中,维护如果每天读写百亿次,几十PB数据流量,如果 被万级用户依赖的管道是一件很有挑战的事情,举几条例子:

除了客户端流控外,亲戚亲戚我们我们我们儿在服务端也支持五种不同的流控最好的办法(Project级、Shard级反压),补救单实例异常在接入层、或后端服务层影响好多好多 租户。亲戚亲戚我们我们我们儿专门开发QuotaServer模块,提供了Project全局流控和Shard级流控两层流控机制,在百万级的规模下也能实现秒级的流控同步,保证租户之间的隔离性以及补救流量穿透原因集群不可用。

日志服务SLS是一款飞天团队自研产品,服务云上云下3W+客户,并在阿里经济体中作为日志数据的基础设施,在过去几年中经历多次双十一、双十二、新春红包锤炼。

在2019双十一中:

在以微服务、云原生为主导的大背景下,应用被切分的越来越 细、整个链路也越来越 繁杂,其中产生的日志种类和数量可是要 ;一块儿日志的重要性也越来越 强,同如果日志将会会有好几条甚至数5个业务方还要消费。

通过shard级别流控,好处非常明显:

如果 未来亲戚亲戚我们我们我们儿会支持计算下推到队列内部人员,能也能直接在队列内进行无效数据过滤,大大降低无效的网络传输和上层计算代价。

和Kafka這個,SLS支持的消费是Logstore级别的全量消费最好的办法,将会业务只还要其中的一偏离 数据,也还要将这段时间的所有数据全量消费也能得到。所有的数据都是从服务端传输到计算节点再进行补救,好多好多 最好的办法对于资源的浪费极其巨大。

随着云原生落地,Logtail的数据埋点在18年初就刚开始了了全面支持Kubernetes,并提供了CRD(CustomResourceDefinition)用于日志和Kubernetes系统的集成,目前这套方案将会应用在了集团内、公有云几千个集群中。



这如果核心痛点的补救+实时系统的兴起使得Kafka类产品在几年间有了如果量的飞跃,成了脍炙人口的基础软件。随着数据分析系统成为企业标配,各大厂商也逐步将数据管道产品化成服务互联网的服务,比较有代表性的有:



数据管道(Data Pipeline)是实现系统之间数据迁移的载体,如果 包括数据的埋点、传输链路、存储队列、消费/转储等都属于数据管道的范畴。在SLS这里,亲戚亲戚我们我们我们儿专为数据管道相关的功能集合起了如果单独的名称:LogHub,LogHub提供数500+种数据接入最好的办法、提供实时数据管道、对接各类下游系统等功能。

然而数据管道因足够底层,在企业数字化过程中担任重要的业务,还要足够可靠、足够稳定、确保数据的通畅,如果 也能弹性满足流量变化需求。亲戚亲戚我们我们我们儿把过去5年来亲戚亲戚我们我们我们儿遇到的挑战展开,和亲戚亲戚我们我们我们儿回顾下。

也能服务好多好多 体量和用户规模,对产品的功能、体验、系统的稳定性和可靠性的要求是很高的。感谢阿里经济体独一无二的环境与挑战,使得亲戚亲戚我们我们我们儿过去五年中持续不断地对产品与技术进行考验与磨炼。



针对日志细分场景下的资源映射和权限归属管理等疑问报告 ,亲戚亲戚我们我们我们儿和蚂蚁日志平台团队合作协议开发了View消费模式(思路来源于数据库中View),也能将不同用户、不同logstore的资源虚拟成如果大的logstore,用户只还要消费虚拟的logstore即可,虚拟logstore的实现以及维护对用户详细透明。该项目将会在蚂蚁集群正式上线,目前将会有数千个View消费实例在工作中。