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

本文涉及的产品
日志服务 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

相关实践学习
通过日志服务实现云资源OSS的安全审计
本实验介绍如何通过日志服务实现云资源OSS的安全审计。
目录
相关文章
|
10月前
|
XML 安全 Java
【日志框架整合】Slf4j、Log4j、Log4j2、Logback配置模板
本文介绍了Java日志框架的基本概念和使用方法,重点讨论了SLF4J、Log4j、Logback和Log4j2之间的关系及其性能对比。SLF4J作为一个日志抽象层,允许开发者使用统一的日志接口,而Log4j、Logback和Log4j2则是具体的日志实现框架。Log4j2在性能上优于Logback,推荐在新项目中使用。文章还详细说明了如何在Spring Boot项目中配置Log4j2和Logback,以及如何使用Lombok简化日志记录。最后,提供了一些日志配置的最佳实践,包括滚动日志、统一日志格式和提高日志性能的方法。
2865 31
【日志框架整合】Slf4j、Log4j、Log4j2、Logback配置模板
|
9月前
|
监控 安全 Apache
什么是Apache日志?为什么Apache日志分析很重要?
Apache是全球广泛使用的Web服务器软件,支持超过30%的活跃网站。它通过接收和处理HTTP请求,与后端服务器通信,返回响应并记录日志,确保网页请求的快速准确处理。Apache日志分为访问日志和错误日志,对提升用户体验、保障安全及优化性能至关重要。EventLog Analyzer等工具可有效管理和分析这些日志,增强Web服务的安全性和可靠性。
244 9
|
7月前
|
存储 SQL 关系型数据库
MySQL日志详解——日志分类、二进制日志bin log、回滚日志undo log、重做日志redo log
MySQL日志详解——日志分类、二进制日志bin log、回滚日志undo log、重做日志redo log、原理、写入过程;binlog与redolog区别、update语句的执行流程、两阶段提交、主从复制、三种日志的使用场景;查询日志、慢查询日志、错误日志等其他几类日志
593 35
MySQL日志详解——日志分类、二进制日志bin log、回滚日志undo log、重做日志redo log
|
11月前
|
XML JSON Java
Logback 与 log4j2 性能对比:谁才是日志框架的性能王者?
【10月更文挑战第5天】在Java开发中,日志框架是不可或缺的工具,它们帮助我们记录系统运行时的信息、警告和错误,对于开发人员来说至关重要。在众多日志框架中,Logback和log4j2以其卓越的性能和丰富的功能脱颖而出,成为开发者们的首选。本文将深入探讨Logback与log4j2在性能方面的对比,通过详细的分析和实例,帮助大家理解两者之间的性能差异,以便在实际项目中做出更明智的选择。
1032 3
|
6月前
|
监控 Java 应用服务中间件
Tomcat log日志解析
理解和解析Tomcat日志文件对于诊断和解决Web应用中的问题至关重要。通过分析 `catalina.out`、`localhost.log`、`localhost_access_log.*.txt`、`manager.log`和 `host-manager.log`等日志文件,可以快速定位和解决问题,确保Tomcat服务器的稳定运行。掌握这些日志解析技巧,可以显著提高运维和开发效率。
468 13
|
6月前
|
缓存 Java 编译器
|
7月前
|
存储 缓存 关系型数据库
图解MySQL【日志】——Redo Log
Redo Log(重做日志)是数据库中用于记录数据页修改的物理日志,确保事务的持久性和一致性。其主要作用包括崩溃恢复、提高性能和保证事务一致性。Redo Log 通过先写日志的方式,在内存中缓存修改操作,并在适当时候刷入磁盘,减少随机写入带来的性能损耗。WAL(Write-Ahead Logging)技术的核心思想是先将修改操作记录到日志文件中,再择机写入磁盘,从而实现高效且安全的数据持久化。Redo Log 的持久化过程涉及 Redo Log Buffer 和不同刷盘时机的控制参数(如 `innodb_flush_log_at_trx_commit`),以平衡性能与数据安全性。
257 5
图解MySQL【日志】——Redo Log
|
8月前
|
SQL 关系型数据库 MySQL
MySQL事务日志-Undo Log工作原理分析
事务的持久性是交由Redo Log来保证,原子性则是交由Undo Log来保证。如果事务中的SQL执行到一半出现错误,需要把前面已经执行过的SQL撤销以达到原子性的目的,这个过程也叫做"回滚",所以Undo Log也叫回滚日志。
331 7
MySQL事务日志-Undo Log工作原理分析
|
6月前
|
SQL 存储 关系型数据库
简单聊聊MySQL的三大日志(Redo Log、Binlog和Undo Log)各有什么区别
在MySQL数据库管理中,理解Redo Log(重做日志)、Binlog(二进制日志)和Undo Log(回滚日志)至关重要。Redo Log确保数据持久性和崩溃恢复;Binlog用于主从复制和数据恢复,记录逻辑操作;Undo Log支持事务的原子性和隔离性,实现回滚与MVCC。三者协同工作,保障事务ACID特性。文章还详细解析了日志写入流程及可能的异常情况,帮助深入理解数据库日志机制。
648 0
|
7月前
|
存储 关系型数据库 MySQL
图解MySQL【日志】——Undo Log
Undo Log(回滚日志)是 MySQL 中用于实现事务原子性和一致性的关键机制。在默认的自动提交模式下,MySQL 隐式开启事务,每条增删改语句都会记录到 Undo Log 中。其主要作用包括:
243 0