SLS数据处理实践:加工延迟篇

本文涉及的产品
对象存储 OSS,20GB 3个月
对象存储 OSS,恶意文件检测 1000次 1年
文件存储 NAS,50GB 3个月
简介: 在日志服务,数据加工功能(功能介绍)用于完成对Logstore数据的预处理,为后续的分析阶段准备数据。本文主要介绍数据加工实践中可能遇到的延迟问题,帮助大家理清延迟现象背后的原因,以及如何去监控、解决延迟问题。

在日志服务,数据加工功能(功能介绍)用于完成对Logstore数据的预处理,为后续的分析阶段准备数据。本文主要介绍数据加工实践中可能遇到的延迟问题,帮助大家理清延迟现象背后的原因,以及如何去监控、解决延迟问题。image.png

什么是加工延迟

Logstore

数据加工作业是衔接源Logstore到目标Logstore的一个管道,在这个管道上完成富化、预处理、清洗等工作。
日志服务的Logstore首先是一个流式数据的存储,在Logstore下有多个Shard(Shard可以类比为Kafka的Partition概念)。每个Shard即是一个数据分片,像是一个无限大队列(基于落盘文件),它是FIFO的:

  • 当生产者向Logstore写入数据的时候,数据默认会随机选择一个Shard做存储(追加到Shard的末尾,每个数据包在Shard上有一个位置,定义为Cursor)。
  • 在读Logstore的时候,消费者选定一个位置(Cursor)开始,按从头到尾的方向顺序读出数据。

时间定义

在定义加工延迟之前,再来看几个时间概念:

  • 数据时间(EventTime):在数据上可以选择一对Key/Value(例如是自定义的timestamp字段)存储业务上的时间;一般建议在日志服务的保留字段__time__上设置EventTime,在使用SLS的索引功能做业务时间筛选时会更加方便。(参考日志服务数据模型

image.png

  • 数据接收时间(ServerReceiveTime):生产者写出的数据被服务端接收的系统时间,随着数据的顺序写入,ServerReceiveTime总是在递增。
  • 数据消费时间(ProcessingTime):消费者读取这个数据做处理的系统时间。

ProcessingTime - ServerReceiveTime定义为加工延迟。在流计算的理论情况下,两者差值逼近0。在SLS实际的加工延迟可以做到1秒内,如果超出了一定阈值,即是加工延迟。

怎样发现延迟

确认目标写入情况

当加工发生延迟的时候,直观的情况是目标Logstore数据缺失。

  • 如果目标Logstore建立了索引,可以选择一个更大范围的时间窗口,隔几秒种查询一次,看日志条数据是否有变化。如果日志集中在之前的时间段且数据量有逐步增加,那比较大概率是发生了延迟(且加工在继续工作)。

image.png

  • 另一种情况,目标Logstore上没有索引,可以通过预览的方式,确认是否有新的数据在写入。重复查询几次,例如最近15分钟有数据写入且写入的数据EventTime比较老,也有可能是加工延迟的原因。

image.png
这两个方法,除了用于确认加工延迟以外,也推荐用来观察加工延迟的恢复进度、解决加工结果数据找不到的情况。

查看指标

数据加工默认包含一个诊断仪表盘(仪表盘介绍),登录SLS控制台,选择对应的加工作业进行查看。
下图就是一个延迟严重的情况:
image.png
而理想情况下加工延迟是:
image.png

配置告警

如果需要时刻关注加工延迟,可以配置一个告警,当延迟稳定发生时,SLS把告警推送钉钉群或者短信。
image.png
如何对加工配置告警,可以参考加工告警配置指南操作。
在告警通知策略上,设置连续N次触发再做消息推送,可以过滤偶尔抖动的情况。
image.png

加工全量数据导致的延迟

这是一种预期内的延迟现象,主要发生在作业刚创建时,有两种场景:

  • 保存加工作业时,选择从历史上一个时间点(按ServerReceiveTime是计算)开始处理数据

image.png

  • 保存加工作业时,选择处理Logstore中的全量数据

image.png
加工耗时取决于时间段内的数据规模,加工作业需要从旧数据开始直到追赶进度完成。在加工并发足够的情况下,会发现加工延迟有变小的趋势。
如果观察到加工追赶得比较慢,推荐对任务按照时间段做切分来实现加速。例如,要处理9/1到9/10的历史日志,则按照天将任务切分成9个,分治处理:
Job_1: [9/1, 9/2)
Job_2: [9/2, 9/3)
....
Job_9: [9/9, 9/10]

加工逻辑复杂导致的延迟

从Logstore的写能力来看,SLS对一个Shard提供5MB/s(原始数据)以上的写入能力,在日志服务集群资源允许时可能支持10MB/s或者更高的写入吞吐。
当真实的大量数据写入源Logstore的Shard后,加工的业务复杂度是不确定的,因此可能发生瓶颈:加工的速率跟不上数据写入的速率。
一个思路是降低加工的复杂度,从逻辑层面优化DSL代码:

  • 使用了e_regex,查看正则表达式的复杂度。对正则做优化往往收到不错的效果,尽量让匹配的边界明确化,可以参考如何优化正则表达式
  • 提前对不需要的数据做过滤:例如对e_drop相关代码做前置,在需要丢弃的数据上可以避免无意义的计算。
  • 对于一连串复杂操作,通过使用条件判断语句(例如e_if、e_switch等)设置分支条件。
  • 使用了e_split等函数对JSON数组进行分裂写出,1份输入对应10倍或更多的写出。
  • 其它情况,持续更新中。。。

如果在加工逻辑层面难以做优化,更直接的方式是按照下一节处理(对源Logstore做Shard分裂),加工会根据Shard数目增加并发度。

源Shard数不足导致的延迟

伴随着加工作业的在线上运行,业务流量变化也可能带来源Logstore的流量增长。对源Logstore做Shard分裂(Shard操作说明),可以让每个Shard上的数据量少一些,并有机会得到更多的加工并发。

分裂Shard的限制

分裂Shard不会对历史上已写入的数据做重分布,也就是说老的数据还在旧Shard上,只有新的数据会落到更多的Shard上。
因此,在分裂Shard后,观察加工延迟指标,可能会发现部分Shard的加工延迟高,部分低的情况:
image.png
较为可能的原因是老的Shard历史上积攒数据较多,追上进度需要时间,而新的Shard上的数据可以立刻被处理,从Logstore属性查看Shard创建时间可以确认这一点:
image.png

关注Shard的状态

源Logstore上,只有readwrite状态的Shard数目对于加工并发有意义,在执行操作时可以选择将Shard一次性分裂为N个。绝大部分情况下不用关注Shard上的BeginKey/EndKey,因为数据默认是随机Shard写入的。
image.png

关于自动分裂

Logstore设置的自动分裂属性,仅对数据写入生效,请仔细阅读该开关的说明。
从加工角度来说,加工延迟不会触发自动分裂。
image.png

写出目标受阻导致的延迟

SLS对Logstore写入有速率限制,例如有每秒钟要写入10万条日志(每条512 Bytes),则需要规划5~10个Shard。
当目标Logstore readwrite状态Shard数目不足时,加工有类似WriteQuotaExceed或QuotaExceed字样的报错,可以在诊断仪表盘中看到。
image.png
处理方法是:对目标Logstore做Shard分裂。解决写出瓶颈后,加工作业停止阻塞,自动恢复数据处理。

总结

参考加工性能指南,建议在部署加工作业之前,从三个层面进行规划:

  • 源Logstore,根据数据量调整Shard数目(readwrite状态),满足一定的加工并发度。
  • 加工DSL代码逻辑优化,例如对正则的优化、合理做条件剪枝、数据过滤尽量前置。
  • 目标Logstore设置足够的Shard数目(readwrite状态),避免加工写出数据受阻。
相关实践学习
日志服务之使用Nginx模式采集日志
本文介绍如何通过日志服务控制台创建Nginx模式的Logtail配置快速采集Nginx日志并进行多维度分析。
目录
打赏
0
0
0
0
3086
分享
相关文章
Apache Flink 实践问题之原生TM UI日志问题如何解决
Apache Flink 实践问题之原生TM UI日志问题如何解决
55 1
Django 后端架构开发:高效日志规范与实践
Django 后端架构开发:高效日志规范与实践
103 1
网络安全视角:从地域到账号的阿里云日志审计实践
日志审计的必要性在于其能够帮助企业和组织落实法律要求,打破信息孤岛和应对安全威胁。选择 SLS 下日志审计应用,一方面是选择国家网络安全专用认证的日志分析产品,另一方面可以快速帮助大型公司统一管理多组地域、多个账号的日志数据。除了在日志服务中存储、查看和分析日志外,还可通过报表分析和告警配置,主动发现潜在的安全威胁,增强云上资产安全。
Tauri 开发实践 — Tauri 日志记录功能开发
本文介绍了如何为 Tauri 应用配置日志记录。Tauri 是一个利用 Web 技术构建桌面应用的框架。文章详细说明了如何在 Rust 和 JavaScript 代码中设置和集成日志记录,并控制日志输出。通过添加 `log` crate 和 Tauri 日志插件,可以轻松实现多平台日志记录,包括控制台输出、Webview 控制台和日志文件。文章还展示了如何调整日志级别以优化输出内容。配置完成后,日志记录功能将显著提升开发体验和程序稳定性。
163 1
Tauri 开发实践 — Tauri 日志记录功能开发
云上数据安全保护:敏感日志扫描与脱敏实践详解
随着企业对云服务的广泛应用,数据安全成为重要课题。通过对云上数据进行敏感数据扫描和保护,可以有效提升企业或组织的数据安全。本文主要基于阿里云的数据安全中心数据识别功能进行深入实践探索。通过对商品购买日志的模拟,分析了如何使用阿里云的工具对日志数据进行识别、脱敏(3 种模式)处理和基于 StoreView 的查询脱敏方式,从而在保障数据安全的同时满足业务需求。通过这些实践,企业可以有效降低数据泄漏风险,提升数据治理能力和系统安全性。
云上数据安全保护:敏感日志扫描与脱敏实践详解
网络安全视角:从地域到账号的阿里云日志审计实践
日志审计的必要性在于其能够帮助企业和组织落实法律要求,打破信息孤岛和应对安全威胁。选择 SLS 下日志审计应用,一方面是选择国家网络安全专用认证的日志分析产品,另一方面可以快速帮助大型公司统一管理多组地域、多个账号的日志数据。除了在日志服务中存储、查看和分析日志外,还可通过报表分析和告警配置,主动发现潜在的安全威胁,增强云上资产安全。
阿里泛日志设计与实践问题之Grafana Loki在日志查询方案中存在哪些设计限制,如何解决
阿里泛日志设计与实践问题之Grafana Loki在日志查询方案中存在哪些设计限制,如何解决
阿里泛日志设计与实践问题之schema-on-read技术的发展对日志搜索的影响是啥,如何解决
阿里泛日志设计与实践问题之schema-on-read技术的发展对日志搜索的影响是啥,如何解决
云上数据安全保护:敏感日志扫描与脱敏实践详解
随着企业对云服务的广泛应用,数据安全成为重要课题。通过对云上数据进行敏感数据扫描和保护,可以有效提升企业或组织的数据安全。本文主要基于阿里云的数据安全中心数据识别功能进行深入实践探索。通过对商品购买日志的模拟,分析了如何使用阿里云的工具对日志数据进行识别、脱敏(3 种模式)处理和基于 StoreView 的查询脱敏方式,从而在保障数据安全的同时满足业务需求。通过这些实践,企业可以有效降低数据泄漏风险,提升数据治理能力和系统安全性。
iLogtail 开源两周年:UC 工程师分享日志查询服务建设实践案例
本文为 iLogtail 开源两周年的实践案例分享,讨论了 iLogtail 作为日志采集工具的优势,包括它在性能上超越 Filebeat 的能力,并通过一系列优化解决了在生产环境中替换 Filebeat 和 Logstash 时遇到的挑战。
158 13

云存储

+关注

相关产品

  • 日志服务