协同消费延迟报警

协同消费库(ConsumerLibrary) 是并行对 LogHub 中日志进行消费的高级模式,提供了消费组(ConsumerGroup)概念对实时消费端进行抽象与管理。Spark Streaming、Storm、即将推出的 Flink SDK 都是基于这种模式的包装。

注意:有关 ConsumerGroup 概念及使用方法,参考下面的文档:
1. 通过 ConsumerLib 实现不丢、保序、去重
2. ConsumerLib 使用
3. 查看协同消费进度

消费组消费进度与报警

ConsumerGroup 是一个消费者组,包含多个 consumer,每个 consumer 消费 Logstore 中的一部分 shard。
shard 的数据模型可以简单理解成一个队列,新写入的数据被加到队尾,队列中的每条数据都会对应一个数据写入时间,下图是 shard 的数据模型。

要理解报警首先要理解下面几个概念:
消费过程:消费者从队头开始顺序读取数据的过程。
消费进度:消费者当前读取的数据对应的写入时间。
消费落后时长:当前消费进度和队列中最新的数据写入时间的差值,单位为秒。
ConsumerGroup 的消费落后时长取其包含的所有 shard 的消费落后时长的最大值,当超过用户预设阈值时,就认为消费落后太多,需要报警。

配置方法

  1. 登录 日志服务管理控制台,单击需要监控的 Logstore 的监控图标。
  2. 找到消费落后时长图表,单击进入云监控控制台。
  3. 该图展示了 Logstore 下所有 ConsumerGroup 的消费落后时长,单位为秒。红框中图例便是所有的 ConsumerGroup,单击右上角 创建报警规则 进入规则创建页面。
  4. 创建针对 ConsumerGroup spamdetector-report-c 的报警规则,5min 内只要有一次大于等于 600 秒就报警。设置生效时间和报警通知联系人,保存规则。

上面的操作完成后便成功创建了报警规则。有关报警规则配置的任何问题,可以直接提工单到云监控。

时间: 2024-11-03 18:52:59

协同消费延迟报警的相关文章

日志服务(原SLS)新功能发布(15)--控制台支持查看协同消费组(ConsumerGroup)消费进度

背景 日志服务中分区(Shard)是每个日志库下基本读写单元,每个分区能承载一定量的服务能力,随着日志数据不断增加,需要通过分裂增加Shard数量,对于多个Shard如果直接通过PullLogs接口拖取数据的话,需要处理负载均衡和故障恢复等各种问题,因此强烈建议使用Consumer Library(storm和spark streaming已支持通过conusmergroup消费数据),用户只需要关心数据处理逻辑,同时在控制台也提供协同消费进度查看功能供用户进行使用. 使用方式 查看Consum

日志服务(原SLS)新功能发布(3)--多实例协同消费库(loghub client library)

使用场景 loghub client library是对LogHub消费者提供的高级模式,解决多个消费者同时消费logstore时自动分配shard问题.例如在storm.spark streaming场景中多个消费者情况下,自动处理shard的负载均衡,消费者failover等逻辑.用户只需专注在自己业务逻辑上,而无需关心shard分配.CheckPoint.Failover等事宜. 举一个例子而言,用户需要通过storm进行流计算,启动了A.B.C 3个消费实例.在有10个shard情况下,

如何实现1080P延迟低于500ms的实时超清直播传输技术

再来当一次技术搬运工,内容来自高可用框架,学霸君工程师袁荣喜的如何实现1080P延迟低于500ms的实时超清直播传输技术.        导语:视频直播是很多技术团队及架构师关注的问题,在实时性方面,大部分直播是准实时的,存在 1-3 秒延迟.本文由袁荣喜向「高可用架构」投稿,介绍其将直播延迟控制在 500ms 的背后的实现.          袁荣喜,学霸君工程师,2015 年加入学霸君,负责学霸君的网络实时传输和分布式系统的架构设计和实现,专注于基础技术领域,在网络传输.数据库内核.分布式系

云数据库·ApsaraDB 产品7月刊

[重点关注]RDS for SQL Server2012 开启公测                                     1.第一款单机版产品 :价格比2008 R2降低近一半,这对于看重RDS产品功能,而对高可用要求稍低的用户来说是一个性价比很高的选择 2.权限系统更为开放 :用户可以通过一个初始数据库账号来方便的管理RDS 3.支持经典网络和VPC.账号管理.备份与恢复.监控报警以及安全白名单等功能 4.性能优秀,媲美当前的SQL Server 2008 R2, 性能白皮书

如何基于Spark Streaming构建实时计算平台

1.前言 随着互联网技术的迅速发展,用户对于数据处理的时效性.准确性与稳定性要求越来越高,如何构建一个稳定易用并提供齐备的监控与预警功能的实时计算平台也成了很多公司一个很大的挑战. 自2015年携程实时计算平台搭建以来,经过两年多不断的技术演进,目前实时集群规模已达上百台,平台涵盖各个SBU与公共部门数百个实时应用,全年JStorm集群稳定性达到100%.目前实时平台主要基于JStorm与Spark Streaming构建而成,相信关注携程实时平台的朋友在去年已经看到一篇关于携程实时平台的分享:

PP租车将启动首轮融资借私家车抢传统地盘

移动互联网不断渗透至汽车产业链的各个细分领域.6月6日,国内首个P2P(PeertoPeer,即个人对个人)互联网汽车租赁公司PP租车将在上海和广州同步启动业务.这家租车公司自去年10月份在北京开展业务后,正快速在国内各大城市跑马圈地.PP租车是国内P2P租车模式的先行者,但在汽车租赁市场只是一个后来者.此前,以神州.一嗨为代表的 租车企业已经进入这一市场,并不断扩大市场份额.EnfoDesk易观智库发布的数据显示,2014年一季度中国互联网租车市场规模达32.5亿元,环比增长19.9%.咨询机

EQueue性能测试计划

1.发送消息吞吐量的测试: 1)单台producer单个进程的发送消息tps 2)单台producer多个进程的发送消息tps 3)单台broker的接收消息tps,由于单台producer可能压不满,所以需要可能两台producer来发消息 2.消费消息吞吐量的测试: 1)单台consumer消费消息的tps 2)两台consumer消费消息的tps 3.同时发送和接收消息的吞吐量.消费延迟的测试: 1)单台producer发送消息,单台consumer消费消息 2)两台producer发送消

如何打造一款拼车APP的用户体验?

  今次的译文是我最喜欢的一类小菜,篇幅简短,实战性强.原文作者是Frog的一名交互设计师,讲述了她与朋友在共同设计开发拼车服务Ridejoy 的iPhone客户端的过程中所遇到的一些挑战以及相关的解决方案.前戏到这里,进入正文. Ridejoy拼车服务在Web端上线运营了几个月之后,大家对当前的用户基础有了比较清晰的认知.而对于Ridejoy的iPhone应用来说,我们希望它不仅仅是网站的移植版本,它所能带来的应该是更符合移动上下文环境的全新用户体验. 基于这样的产品思路,我们识别出了三个关键

云栖大会在线用户行为分析场分享:海量流式视频日志收集

本文PPT由2017年云栖大会TI 在线用户行为分析专场阿里云北洲分享的<海量流式视频日志收集>整理而成. 在视频直播场景中,使用日志服务的目的是为了能够对当前直播的服务质量进行监控,比如受当前卡顿影响的人数.在线用户数量的变化趋势等. 为了能拿到服务质量,我们需要收集多种维度的日志数据,在介绍日志服务之前,先来了解下日志采集使用上的一些痛点. 日志产生渠道非常多,怎么用一种统一的方式将这些日志快速的收集上来,并进行结构化,方便后续的分析处理,这里的挑战可以说非常之大. 运维方面的困难.业务越