通过 SLS 实现日志大数据入湖 OSS

简介: 数据湖技术在日志生态中扮演不可或缺的角色,而打通日志从生产端到数据湖的链路却比较复杂。本文将介绍基于 SLS 方案为日志入湖提供端到端(End-to-End)支持,帮助用户提升接入效率,并在费用、运维上有效降低成本。

1. 目标读者

对日志数据做采集并投递 OSS 进行存储或构建数据湖的用户。

2. 方案背景

近年来,日志数据的规模、种类在快速增长。围绕企业的生产、运营,大量的 IT 系统依赖日志数据作为生产资料。数据湖技术在日志生态中扮演不可或缺的角色:

  • 日志数据种类繁多,缺乏 schema 规划,湖有较强的灵活性。

  • 大量的日志具有写多读少的特性,湖上有很多 schema-on-read 分析工具。

  • 伴随着日益严格的合规要求、业务日志数据精细化分析需求,一些日志数据未来可能是十年留存,极低成本的存储底座是湖的强项。

  • 过去研发、运维才关心的日志,现在分析师、运营等新角色也加入到使用者行列,湖上广泛的生态可以应对更多样化的计算需求。

  • 存、算分离在大规模数据集上获得成功,数据湖做大池子规模释放成本红利,可以匹配日志的急速增长趋势。

打通日志从生产端到数据湖的链路却比较复杂,有以下挑战:

  • 类型众多,分布在异构数据源。例如:落盘存储的程序日志,云服务(IaaS、PaaS、SaaS)产生日志、监控数据,K8s 应用的 stdout/Log/Metric,自建软件(MySQL、Hadoop、Kafka、Elasticsearch 等)数据迁移等。

  • 日志数据产生的环境复杂、多样。例如:移动端设备数据采集覆盖率面临复杂环境(弱网、机器时钟错误等)挑战,Trace 数据自动化埋点,嵌入式设备的设计功耗低、内存小等等情况。

  • 流量大、呈现周期性波动。日志流量特征与业务是强关联的,峰、谷可能相差 5 倍以上,入湖链路需应对流量高峰,保障数据完整接入。大规模(百 TB/day)数据下会放大开源软件的性能、可靠性不足,也对运维人力、硬件供应链提出更苛刻要求。

  • 数据不规整,需要预处理。日志前期缺乏规划,导致多个版本的格式定义,如何以统一的数据模型入湖做分析。一些应用可能出现多种类型日志混在一起,需要清理、丰富再分门别类入湖。

3. 使用场景

阿里云提供了企业级数据湖解决方案,存储底座基于阿里云对象存储(OSS)构建。

对于散落各处的日志数据,如何以高效、可靠、经济的方式完成入湖 OSS:

  1. 从企业的各个角落采集、摄取数据,包括程序运行日志、app 埋点、Trace 数据、设备指标、数据库业务数据、SaaS 服务数据等。

  2. 清理、丰富源数据并将其转换为可满足不同业务方需求的高价值数据。

  3. 将数据以统一方式投递到 OSS 存储,提供多样化入湖模板匹配数据湖的存储、分析需求。

4. 方案介绍

4.1 技术方案选型

将日志数据投递 OSS 构建数据湖,有以下常见方案:

  1. 采集器直接入湖。在日志产生的地方将数据直传 OSS,例如基于云厂商提供的 Open API(SDK)开发程序实现或使用开源采集软件(Flume/Logstash/Beats 等)。该方案需要业务方在自己程序里定制数据处理与上报逻辑、处理异常重试,并且需要花费精力来处理可靠性、性能问题。

  2. 计算引擎入湖。例如通过 Flink/Spark 等计算引擎的 connector 能力,读取源数据后写到对象存储。该方案适合处理云存储服务、数据库等 API 友好的数据源,对于其它数据源无法支持。

  3. 迁移工具。应对自建或混合云场景数据上云、迁移需求。例如部署 ossimport 工具将 AWS S3 数据迁移到 OSS,对于 Hadoop 生态数据源使用 DistCp 复制数据。

  4. 队列存储入湖。借助持久化的 Queue 解决数据入湖的可扩展性、容错性、集中化需求,方便构建统一的数据接入中台。例如基于开源 Kafka、阿里云 SLS 的方案。

4.2 基于 SLS 的方案

SLS 提供基于队列存储的数据入湖 OSS 方案。包括四个关键能力:

  1. 统一接入数据源覆盖服务器与应用、开源软件、物联网、移动端、标准协议、阿里云产品等多种来源的数据。

  2. 弹性、低成本存储。开箱即用的队列存储衔接日志生产与数据入湖过程。实例级 QoS 流量控制,分布式存储冗余更可靠。例如下图峰谷流量相差 10 倍,SLS 按量收费模型可以大大降低使用成本。

2021-11-21-18-22-45.png

  1. Serverless 预处理。对于归档存储需求,非结构化数据做个压缩就可以入湖。而结构化数据入湖,有许多数据清洗、规整需求,SLS 提供全托管、免运维的 ETL 服务可以简化数据准备过程。

  2. 投递 OSS 入湖。以 SLS Logstore(日志库)为数据接入抽象层,屏蔽了数据源复杂性,Logstore 数据以统一的方式入湖,具有以下特点:全托管服务,按量付费,一键配置向导。

4.3 SLS 方案优势

SLS 的队列功能及上下游生态为日志入湖提供端到端(End-to-End)支持,有省级公路(连接 PaaS/SaaS 数据源),也有“村村通”(连接端、开源软件采集)。帮助用户提升接入效率,并在费用、运维上降低成本

2021-11-23-11-32-19.png

5. 案例实践

5.1 需求描述

某点播服务,在技术架构上分为客户端和服务端:

  • 客户端部署在三种操作系统(iOS/Android/Windows)上,app 会记录应用的埋点数据到服务端存储,有一次开发、多处部署的跨平台需求。

  • 服务端以 Nginx AccessLog 为主,记录用户操作行为(点击、登录、购买等操作),单台机器上的日志量较大(10+MB/s)。

业务上需求:

  • 搭建统一的日志分析平台,支持最近 30 天的关键词搜索(问题调查)、SQL 统计与报表查看。

  • 日志数据量大,考虑到对 30 天前数据的交互式分析需求弱,可以将历史数据归档到 OSS 存储一年(审计用途)。

5.2 方案架构

基于需求制定了以下方案:

  • 业务程序集成 SLS 的 C Producer Library 发送数据到 SLS,最小化系统资源占用(避免影响手机设备性能、续航),且可以用一套代码上在 Android / iOS / Windows 三个平台上发布。

image.png

  • 通过 Logtail 客户端采集服务器上的 Nginx AccessLog,Logtail 直接读取日志文件,业务上不需要任何适配修改。且 Logtail 对比开源同类软件有 5 倍以上性能优势,大大降低对业务服务器 CPU、内存资源的占用。

  • Logstore(日志库)存储周期设置为 30 天并开启索引,支持关键词搜索、交互式 SQL 分析与可视化。如下是通过 SLS 交互式分析能力计算高延时请求的热力图。

  • 将 Logstore 数据开启投递 OSS,配置 Snappy 压缩格式(降低 OSS 存储空间与成本)、文件目录按照设备平台、日期分区(方便后续快速查找):

2021-11-22-21-56-35.png

整体架构图如下:

image.png

5.3 实施步骤

前提条件

用户已开通阿里云 SLS、OSS 两个产品,并且准备好 OSS Bucket。

创建 SLS 项目与日志库

步骤一:登录 SLS 控制台创建 Project。

image.png

注意:选择所属地域建议和阿里云 ECS 一致(可以使用 Logtail 走内网采集数据,网络延时更稳定)。

步骤二:进入 Project,继续创建 Logstore。

Logstore 用于存储从移动端、服务器采集到的数据,根据数据流量设置 Shard 数目(也可以在创建 Logstore 后再修改数目),每个 Shard 支持 10MB/s 的数据写入能力。

image.png

采集数据到 SLS

采集移动端数据到 SLS:这一部分是在业务程序中集成 SLS 提供的 Library,有详细的说明与样例代码,本文不再赘述。

接下来重点介绍采集服务器上 Nginx AccessLog 到 SLS 步骤。

步骤一:进入 Logtail 采集配置向导。

选中 Logstore,依次点击数据接入>logtail配置>新建

步骤二:在 ECS 上安装 Logtail 客户端。

如之前已安装,可以忽略该步骤继续。

image.png

步骤三:将 ECS 内网 IP 添加到机器组。

image.png

步骤四:填写 Logtail 采集配置。

包括 AccessLog 的文件路径等配置项。

image.png

至此,Logtail 采集配置与机器组关联成功,Logtail 在 15 秒后开始采集,你可以在 Logstore 中预览数据确认。

配置数据投递 OSS

步骤一:进入配置向导。

选中 Logstore,点击数据处理>导出>OSS(对象存储)>新建

步骤二:填写作业信息。

image.png

OSS Bucket:填写目标的OSS Bucket。

文件投递目录:数据将会放置在目标 Bucket 的文件目录下,也可以理解是一个文件路径的前缀。

文件后缀(可选):以此为后缀或由存储格式和压缩类型自动生成。

分区格式:支持自定义的时间格式来按照时间生成分区。

配置 RAM 角色:如该账号未创建过 RAM 角色,可以按照控制台引导来新建。使用 RAM 角色来配置好 LogStore 的读取权限和 OSS Bucket 写权限,也可以通过自定义角色配置粒度更细(如特定 Bucket 写权限,特定 Logstore 读权限等)。

投递大小:代表着会收集投递大小的日志数据量进行投递,可根据实际情况选择所需大小,对于一些计算引擎或者数据湖上层的数据管理系统,过大的文件会影响读写的延时,而投递大小设置偏小会导致文件数过多,会导致对元数据管理或对象存储的 List 等接口压力过大。

投递时间:决定任务的生成间隔,投递大小或者投递时间满足任一条件会完成一次投递,所以用户可以根据自己使用场景配置合理的投递时间,比如在用户流量较小的情况下,可选择偏长的投递时间,防止出现过多小文件。

压缩方式:压缩可以降低用户的存储成本。

JSON格式应用广泛,可读性好,本文以此为例。可以选择不投递日志中的 tag 字段减少日志大小。

image.png

开始时间:开始投递的起始日志收集的时间(SLS 服务端接收日志的系统时间)。

时区选择:时区选择会影响到最后通过日期表示的分区目录。

最后点击确定按钮,至此,投递作业创建完成。

步骤三:查看投递作业。

在 SLS 控制台左侧栏,点击作业>数据投递(找到创建的投递作业。也可以选中 Logstore,点击数据处理>导出>OSS(对象存储)找到作业。

在作业管理页面,可以修改投递配置,停止、启动作业。

image.png

投递作业提供统计报表,包含了流量信息、延迟信息、读写异常错误信息等内容。

image.png

6. 常见问题

  1. SLS 数据所在 Project 是否支持跨区域投递 OSS Bucket ?

SLS 投递 OSS 目前仅支持同区域进行,例如北京的 SLS Logstore 经过内网投递到北京区域 OSS Bucket,通过内网传输并不产生公网费用。

  1. 采集服务器上日志文件,是否有监控,如何诊断错误?

Logtail 默认只采集增量产生的实时数据,单条日志限制大小不超过 512 KB,更多请参考限制说明

Logtail 日志采集支持异常告警,请参考配置 Logtail 监控告警

其它 Logtail 采集异常诊断可以参考 Logtail FAQ

  1. 使用 SLS 队列方案入湖 OSS 会引入多少成本?

基于 SLS 队列入湖方案,可以借助完善的数据采集生态获取采集数据到阿里云,并通过持久化的存储、可重试的投递作业让整个入湖链路具备更高的容错性。

对于单纯的 OSS 入湖需求,可以在 Logstore 设置存储周期 1 天并关闭索引以降低费用。那么,对于 1 TB/day 流量的数据,每天 SLS 花费(写入流量、存储、投递)几十元。

  1. SLS 投递 OSS 作业怎样监控异常?

您可以在告警中心中找到SLS数据投递预置规则中添加和开启报警。系统内置了五条数据投递的监控报警规则,分别是:数据投递延迟监控、数据投递流量(绝对值)监控、数据投递异常报错监控、数据投递失败条数监控、数据投递流量(日同比)监控。请参考 OSS 投递作业告警配置

作者介绍
目录