日志服务消费延迟问题排查

本文涉及的产品
日志服务 SLS,月写入数据量 50GB 1个月
简介: 日志服务中提供了消费组能够以流的方式获取日志,使用消费组获取日志的优点在于,用户无需关心日志服务的实现细节和消费者之间的负载均衡、failover等,只需要专注于业务逻辑即可。 一个消费组由多个消费者构成,这多个消费者共同消费一个Logstore中的数据,消费者之间不会重复消费数据。

日志服务中提供了消费组能够以流的方式获取日志,使用消费组获取日志的优点在于,用户无需关心日志服务的实现细节和消费者之间的负载均衡、failover等,只需要专注于业务逻辑即可。
一个消费组由多个消费者构成,这多个消费者共同消费一个Logstore中的数据,消费者之间不会重复消费数据。因为每个Shard只会分配到一个消费者,一个消费者可以同时消费多个Shard(当消费者数量超过Shard数量时,多余消费者就会被搁置)。消费者是消费组的基本构成单元,实际承担消费任务,同一个消费组下面的消费者名称必须不同。

常见的日志消费延迟有以下三个原因:

  1. 消费速度跟不上日志写入的速度
  2. 从历史数据开始消费,短暂的消费延迟
  3. 保存 checkpoint 频率较低,在控制台查看时误认为是消费延迟

在下图所示的消费组状态中查看到某个Shard或整体消费进度与当前时间相差较多时可以根据该文档进行排查。
图中最近消费数据时间是指消费组获取到的 logGroup 中日志写入日志服务的时间,消费组也是根据日志中的时间调用 UpdateConsumerGroupCheckpoint 接口进行修改的,所以调用的频率低,也会造成消费延迟的错觉。
image.png

消费速度跟不上日志写入的速度

消费、写入速度需要开通服务日志之后查看自动生成的 logstore: internal-operation_log 
消费流量查询:

Method: pulldata | SELECT sum(NetOutFlow)/1024.0/1024.0 AS NetOutFlowMB, time_series(__time__, '1m', '%H:%i:%s', '0') as time GROUP BY time ORDER BY time

写入流量查询:

Method: PostLogstoreLogs | SELECT sum(NetInflow)/1024.0/1024.0 AS NetInFlowMB, time_series(__time__, '1m', '%H:%i:%s', '0') as time GROUP BY time ORDER BY time

比较上面两个SQL流量大小。
1) 首先需要排查process调用里面是否存在阻塞(比如写入到数据库的操作是否较慢等),有可能阻塞了消费进程。
检查消费流量是否达到上限:

Method: pulldata | SELECT Shard, count(1) as count, sum(NetOutFlow)/1024.0/1024.0 AS NetOutFlowMB, time_series(__time__, '1m', '%H:%i:%s', '0') as time GROUP BY time, Shard ORDER BY time

2) 当消费组比较多、且数据量较大时也会出现消费速度跟不上写入速度的情况,单个Shard每秒消费流量超过或接近10兆时,需要手动分裂Shard,shard读写能力参考文档
3) 数据量过大,机器少时,处理负载过重(网络、cpu或内存上都会有瓶颈导致消费速度慢)
4) java 进程 GC 重启导致重复消费且延迟。

消费历史数据,短暂的延迟

创建消费组开始消费数据时,可以传递消费开始位置。
如果设置的beginCursor,会从最早的数据开始消费,保存的checkpoint 就是历史数据写入的时间点;这时可以参考上面SQL查询消费、写入的速度,如果消费速度远高于写入速度,之后是会追上最新数据的。

保存checkpoint的频率较低

通过下面SQL在 internal-operation_log 中查询保存消费位点的频率。

Method: ConsumerGroupUpdateCheckPoint | SELECT time_series(__time__, '1m', '%H:%i:%s', '0') as time, COUNT(*) as count, Shard GROUP BY time, Shard ORDER BY time

消费组代码中默认的保存频率是30秒一次,不过可以根据需求进行修改。保存 checkpoint 使用的时间是消费到数据FastLogGroup中的 tags 系统字段中 receive_time 字段,消费过程中可以打印该字段查看消费位置;该字段是消费到的最新位置。

消费延迟监控

首先,需要开启服务日志。消费延迟相关的信息在重要日志中,如果需要查看消费或写入速度,还需要开启详细日志。服务日志开启之后自动会创建消费组监控仪表盘,如下图: 
image.png
可以使用上面的图表设置告警,由于默认的图表中字段别名使用了中文,告警条件中不能直接使用,需要将中文字段改为英文,然后在告警条件中使用。该日志内容是两分钟更新一次的,所以查询范围、告警条件等都需要大于120秒。
image.png

image.png
取消中文别名,然后修改Y轴字段、点击预览,最后点确定就可以了。告警条件设置为 MaxBehindLatest > 1800 ,即延迟超过半小时触发告警,查询区间和间隔都设置为 1小时。
image.png

相关

最新 checkpoint 保存位置查看: 
https://sls.console.aliyun.com/lognext/project/${替换projectName}/logstore/${替换LogstoreName}/consumergroup/${替换消费组名称}/consumergroupList

相关实践学习
日志服务之使用Nginx模式采集日志
本文介绍如何通过日志服务控制台创建Nginx模式的Logtail配置快速采集Nginx日志并进行多维度分析。
目录
相关文章
|
2月前
|
Kubernetes Ubuntu Windows
【Azure K8S | AKS】分享从AKS集群的Node中查看日志的方法(/var/log)
【Azure K8S | AKS】分享从AKS集群的Node中查看日志的方法(/var/log)
|
28天前
|
Java
日志框架log4j打印异常堆栈信息携带traceId,方便接口异常排查
日常项目运行日志,异常栈打印是不带traceId,导致排查问题查找异常栈很麻烦。
|
1月前
|
存储 监控 数据可视化
SLS 虽然不是直接使用 OSS 作为底层存储,但它凭借自身独特的存储架构和功能,为用户提供了一种专业、高效的日志服务解决方案。
【9月更文挑战第2天】SLS 虽然不是直接使用 OSS 作为底层存储,但它凭借自身独特的存储架构和功能,为用户提供了一种专业、高效的日志服务解决方案。
79 9
|
2月前
|
数据采集 监控 数据安全/隐私保护
掌握Selenium爬虫的日志管理:调整–log-level选项的用法
在Selenium Web数据采集时,日志管理至关重要。通过调整`–log-level`参数可优化日志详细度,如设置为`INFO`记录一般操作信息。结合代理IP、Cookie及user-agent配置,不仅能提高采集成功率,还能规避反爬机制。合理选择日志级别有助于调试与性能平衡,在复杂的数据采集任务中保持程序稳定与可控。
掌握Selenium爬虫的日志管理:调整–log-level选项的用法
|
2月前
|
开发框架 .NET Docker
【Azure 应用服务】App Service .NET Core项目在Program.cs中自定义添加的logger.LogInformation,部署到App Service上后日志不显示Log Stream中的问题
【Azure 应用服务】App Service .NET Core项目在Program.cs中自定义添加的logger.LogInformation,部署到App Service上后日志不显示Log Stream中的问题
|
2月前
|
存储 监控 安全
|
2月前
|
XML Java Maven
log4j 日志的简单使用
这篇文章介绍了Log4j日志框架的基本使用方法,包括在Maven项目中添加依赖、配置`log4j.properties`文件以及在代码中创建和使用Logger对象进行日志记录,但实际打印结果中日志级别没有颜色显示。
log4j 日志的简单使用
|
2月前
|
XML Java Maven
Spring5入门到实战------16、Spring5新功能 --整合日志框架(Log4j2)
这篇文章是Spring5框架的入门到实战教程,介绍了Spring5的新功能——整合日志框架Log4j2,包括Spring5对日志框架的通用封装、如何在项目中引入Log4j2、编写Log4j2的XML配置文件,并通过测试类展示了如何使用Log4j2进行日志记录。
Spring5入门到实战------16、Spring5新功能 --整合日志框架(Log4j2)
|
2月前
|
API C# 开发框架
WPF与Web服务集成大揭秘:手把手教你调用RESTful API,客户端与服务器端优劣对比全解析!
【8月更文挑战第31天】在现代软件开发中,WPF 和 Web 服务各具特色。WPF 以其出色的界面展示能力受到欢迎,而 Web 服务则凭借跨平台和易维护性在互联网应用中占有一席之地。本文探讨了 WPF 如何通过 HttpClient 类调用 RESTful API,并展示了基于 ASP.NET Core 的 Web 服务如何实现同样的功能。通过对比分析,揭示了两者各自的优缺点:WPF 客户端直接处理数据,减轻服务器负担,但需处理网络异常;Web 服务则能利用服务器端功能如缓存和权限验证,但可能增加服务器负载。希望本文能帮助开发者根据具体需求选择合适的技术方案。
75 0
|
2月前
|
C# Windows 监控
WPF应用跨界成长秘籍:深度揭秘如何与Windows服务完美交互,扩展功能无界限!
【8月更文挑战第31天】WPF(Windows Presentation Foundation)是 .NET 框架下的图形界面技术,具有丰富的界面设计和灵活的客户端功能。在某些场景下,WPF 应用需与 Windows 服务交互以实现后台任务处理、系统监控等功能。本文探讨了两者交互的方法,并通过示例代码展示了如何扩展 WPF 应用的功能。首先介绍了 Windows 服务的基础知识,然后阐述了创建 Windows 服务、设计通信接口及 WPF 客户端调用服务的具体步骤。通过合理的交互设计,WPF 应用可获得更强的后台处理能力和系统级操作权限,提升应用的整体性能。
77 0