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

  • 时间:
  • 浏览:37
  • 来源:uu直播快3平台_UU快3直播官方

为了便于水平扩展我们都歌词 引入了Shard的概念(相似Kafka Partition),用户还还后能 通过分裂Shard、合并Shard来实现资源的伸缩,但哪此概念也会为用户带来过多过多使用上的困扰,用户还要去了解Shard的概念、还要去预估流量分配Shard数、这名 并且原困Quota限制还还要手动分裂...

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

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

和Kafka相似,SLS支持的消费是Logstore级别的全量消费方法,原困业务只还要其中的一次责数据,也还要将这段时间的所有数据全量消费也能得到。所有的数据都是从服务端传输到计算节点再进行补救,这名 方法对于资源的浪费极其巨大。

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

目前SLS线上派发了数千种实时指标,每天的访问日志有上千亿,出先 问题报告 图片时纯粹手工调查难度非常大。为这名 我们都歌词 专门开发了根因分析相关算法,通过频繁集和差异集的方法,快速定位和异常最相关的数据集合。

只要未来我们都歌词 会支持计算下推到队列内部管理,还还后能 直接在队列内进行无效数据过滤,大大降低无效的网络传输和上层计算代价。



针对单消费者能力严重不足的问题报告 图片,我们都歌词 对ConsumerGroup进一步增强,开发了Fanout消费模式,在Fanout模式下,好几次 多Shard中的数据可交由多个消费者补救,将Shard与消费者解耦,彻底解生产者消费者能力不匹配的问题报告 图片。同时消费端不需要关心Checkpoint管理、Failover等细节,Fanout消费组内部管理完全接管。

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

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

在阿里高度虚拟化的场景中,一台物理机原困运行上百个容器,传统的日志落盘派发方法对物理机磁盘的竞争很大,会影响日志写入性能,间接影响应用的RT;同时每天物理机还要为各个容器准备日志的磁盘空间,造成巨大的资源冗余。

只我应该 们都歌词 和蚂蚁系统部公司公司合作 开展了日志无盘化项目,基于用户态文件系统,为应用虚拟出好几次 多日志盘,而日志盘的手中直接通过用户态文件系统对接Logtail并直传到SLS,以最快的方法实现日志可看、可查。



借助此种方法大大缩短了我们都歌词 问题报告 图片调查的时间,在报警时我们都歌词 会自动带上根因分析结果,过多过多并且收到告警时就原困也能定位具体是哪个用户、哪台机器还是哪个模块引发的问题报告 图片。

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

自动分裂



针对热点问题报告 图片,我们都歌词 在系统中增加了调度角色,通过实时数据派发和统计后,自动做出调整,来消除系统中处于的热点,主要有以下好几次 多手段:

数据管道是哪此?

SLS对外SLA承诺99.9%服务可用性(实际99.95%+),刚结束的并且我们都歌词 比较慢达到原来的指标,每天收到过多过多告警,总是深夜被电话Call醒,疲于补救各种问题报告 图片。总结下来主要的原困有2点:

在以微服务、云原生为主导的大背景下,应用被切分的越来越 细、整个链路也越来越 简化,其中产生的日志种类和数量也过多;同时日志的重要性也越来越 强,同好几次 多日志原困会有好几次甚至数好几次 业务方还要消费。

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

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



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

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

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





针对日志细分场景下的资源映射和权限归属管理等问题报告 图片,我们都歌词 和蚂蚁日志平台团队公司公司合作 开发了View消费模式(思路来源于数据库中View),也能将不同用户、不同logstore的资源虚拟成好几次 多大的logstore,用户只还要消费虚拟的logstore即可,虚拟logstore的实现以及维护对用户完全透明。该项目原困在蚂蚁集群正式上线,目前原困有数千个View消费实例在工作中。

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



我们都歌词 对Agent(Logtail)进行了一系列多租户隔离优化:

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

随着移动互联网兴起,我们都歌词 专门针对移动端开发了Android、IOS的SDK,便于用户快速接入日志;这名 时间点阿里也结束微服务改造、pouch结束上线,Logtail结束兼容pouch,同时我们都歌词 还专门为Java微服务提供Log4J、LogBack的Appender,提供数据直传的服务。

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

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

传统的方法粗暴简单,还要日志的人这名 人去机器上派发,最终一份日志原困被重复派发几十遍,严重浪费客户端、网络、服务端的资源。



数据管道(Data Pipeline)是实现系统之间数据迁移的载体,只要包括数据的派发、传输链路、存储队列、消费/转储等都属于数据管道的范畴。在SLS这里,我们都歌词 专为数据管道相关的功能集合起了好几次 多单独的名称:LogHub,LogHub提供数400+种数据接入方法、提供实时数据管道、对接各类下游系统等功能。

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

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

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

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

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

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

随着非阿里云团队使用,过多过多我们都歌词 扩展了Logtail,支持通用的日志格式,比如正则、Json、分隔符等等。同时还有过多过多应用不希望落盘,只我应该 们都歌词 提供了各种语言的SDK用于日志上传的代码集成。

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

在2019双十一中:

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

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

在2017年前后,我们都歌词 遇到了另外好几次 多挑战:单机Agent的多租户流控,举好几次 多例子:

SLS从源手中禁止同一文件的重复派发,日志统一派发到SLS后,我们都歌词 为用户提供ConsumerGroup用于实时消费。但伴随着日志的细分化以及日志应用场景的充裕化,SLS的数据消费逐渐暴露出了好几次 多问题报告 图片:

自动负载均衡

在2018年初,为了应对简化的需求,我们都歌词 为Logtail增加了插件功能,有自定义需求的用户还还后能 通过开发插件的方法扩展Logtail,实现各种充裕的功能;同时我们都歌词 也紧跟时代步伐,支持云原生、智能设备、IoT等新兴领域的数据派发

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

原来例子每天都是处于,咋样把简单的管道做得不简单,还要少许的工作,在下面篇幅中我们都歌词 娓娓道来。

SLS起源与阿里云的飞天项目,这名 我们都歌词 飞天好几次 多多基础的日志模块,几乎所有的系统时会使用这名 模块打印日志,过多过多最结束我们都歌词 开发了Logtail用于派发飞天日志,当时的Logtail还只要好几次 多阿里云飞天系统内部管理使用的工具。