首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

为什么即使收到/删除的指标与发送的指标相匹配,SQS ApproximateNumberOfMessagesVisible & ApproximateAgeOfOldestMessage也会上升?

即使收到/删除的指标与发送的指标相匹配,SQS(Simple Queue Service)的ApproximateNumberOfMessagesVisible和ApproximateAgeOfOldestMessage指标也会上升的原因可能有以下几点:

  1. 消息处理时间长:当消息在队列中被消费者接收后,如果消费者处理消息的时间较长,那么在消息被处理完成之前,ApproximateNumberOfMessagesVisible指标会保持不变或者上升。这是因为SQS在消息被接收后会将其标记为不可见状态,直到消费者处理完毕并删除消息,才会将ApproximateNumberOfMessagesVisible指标减少。
  2. 消费者数量不足:如果队列中的消息被多个消费者并发接收处理,但消费者的数量不足以及时处理所有的消息,那么ApproximateNumberOfMessagesVisible指标会上升。这是因为每个消费者在处理完一条消息之前,其他消息仍然处于不可见状态,因此ApproximateNumberOfMessagesVisible指标会增加。
  3. 消息重复发送:在某些情况下,消息可能会由于网络问题或其他原因而被重复发送到队列中。当重复的消息被接收后,ApproximateNumberOfMessagesVisible指标会上升。这是因为每个重复的消息都会被视为新的消息,即使之前已经有相同的消息在队列中。
  4. 消息处理失败:如果消费者在处理消息时发生错误或失败,可能会导致消息无法被正确处理并删除。这种情况下,ApproximateNumberOfMessagesVisible指标会上升,因为消息仍然处于不可见状态,无法被其他消费者接收。
  5. 延迟删除:当消息被消费者接收后,如果消费者在处理完消息后没有立即删除消息,而是延迟删除,那么ApproximateAgeOfOldestMessage指标会上升。这是因为ApproximateAgeOfOldestMessage指标表示最早一条消息在队列中的存储时间,如果消息被消费者接收后未及时删除,那么这条消息的存储时间会增加。

对于以上情况,可以通过以下方式解决:

  1. 优化消息处理逻辑:尽量减少消息处理的时间,确保消费者能够及时处理完消息并删除,以减少ApproximateNumberOfMessagesVisible指标的上升。
  2. 增加消费者数量:根据实际需求,增加消费者的数量,以提高消息处理的并发能力,减少ApproximateNumberOfMessagesVisible指标的上升。
  3. 实现消息去重机制:在消费者端实现消息去重的机制,避免重复处理相同的消息,以减少ApproximateNumberOfMessagesVisible指标的上升。
  4. 错误处理与重试机制:在消费者端实现错误处理与重试机制,确保消息处理失败时能够进行相应的处理,避免消息无法被正确处理并删除,减少ApproximateNumberOfMessagesVisible指标的上升。
  5. 及时删除消息:消费者在处理完消息后应及时删除消息,避免延迟删除导致ApproximateAgeOfOldestMessage指标的上升。

腾讯云相关产品:腾讯云消息队列 CMQ(Cloud Message Queue),详情请参考:https://cloud.tencent.com/product/cmq

页面内容是否对你有帮助?
有帮助
没帮助

相关·内容

干货 | 成本低误差小,携程基于 Kafka 的 Serverless 延迟队列的实践

同时,对于 DynamoDB 中的消息也设置了 TTL 用来自动删除数据的,设置的 TTL 时间比延迟时间大 24 小时,主要是方便 troubleshooting 的。...这样即使有 n 个 Timer 在同一分钟内向 SQS 的 FIFO 队列投递 n 次消息,也只会有一条消息被成功投递到 SQS 的 FIFO 队列中,n-1 条消息被 SQS 的 FIFO 队列的去重功能过滤掉了...当 Scheduler 消费到通知消息时,会根据消息内容转换成时间戳,并在 DynamoDB 中查询这一时间戳范围内的所有消息,修改消息的延迟时间,投递到 SQS 的 Standard 队列中,最后删除...如果单位时间内写入消息的数量超过了 WCU 的限制会导致消息写入失败,同理也会导致读取消息失败。 如果将 WCU 和 RCU 都设置成峰值肯定不会导致读写失败的问题,但是会产生巨大的成本浪费。...5)Timer 性能指标 Timer 会每分钟向 SQS 的 FIFO 队列中投递一个消息,消息的数量与 Service 的副本数相同。

2.1K40

ElasticMQ 0.7.0:使用Akka和Spray的长轮询,非阻塞实现

客户端的主要改进是: 近期加入SQS的长轮询(long polling)支持 更简单的独立服务器 - 只需下载一个jar 通过长轮询,您可以在收到消息时指定一个附加MessageWaitTime属性。...这有助于减少使用的带宽(不需要非常频繁的请求),提高系统整体性能(发送后立即收到消息)并降低SQS消耗。 现在,独立服务器是一个单一的jar文件。...为了与Actor交互,使用了类型化的问答模式(Typed ask pattern)。...{prefixOption => //逻辑 } } } 上述action与在body参数中的"Action"URL中指定的Action 名字相匹配,并选择接受或拒绝请求...当接收消息的请求到达,并且队列中没有任何内容时,我们不是立即回复(即向发送者Actor发送空列表),而是将原始请求的引用和发送方actor存储在一个map中。

1.6K90
  • 如何避免AWS的高额账单?

    最终找到根因在于一个会触发Lambda执行的消息事件由于某个bug被大量复制,并且该事件在被Lambda处理后原样发回SQS,导致发生死循环。...了解得越清楚,在配置监控和告警时会更得心应手,收到告警后也有助于快速定位问题。 除了针对各个基础服务的各类指标进行监控外,监控云平台各个账号的账单也是避免损失的一大法宝。...但这样做,一方面带来了额外的工作量,另一方面也会带来大量的“噪音”,增加了分析日志的复杂程度。更重要的是,记录大量日志有可能影响函数本身执行的性能,也会增加监控系统的成本。...即使使用单元测试来观察特定事件处理过程的执行性能,因为要关注特定业务场景,也需要花费大量时间准备测试数据。...当然,还有很多其他类似的工具也能达到相同的目的,我们在使用中根据具体需求进行选择就好。 写在最后 本文只是抛砖引玉,没有过于深入的讨论,目的是想总结与记录在Serverless系统中试水的所见与所得。

    18520

    以太网存储网络的拥塞管理连载(四)

    本节还有助于理解为什么以太网交换机不具备类似功能。 第 5 章 "了解存储网络中的 I/O 流量 "一节有助于了解光纤通道结构中的 I/O 流量与无损以太网网络中的 I/O 流量之间的区别。...即使在将来,以太网交换机也不可能监控 I/O 性能,类似于 Cisco MDS 交换机光纤通道端口上的 SAN Analytics。...即使流量通过网络中其他位置的 FCoE 端口,这种方法也能发挥作用。一个典型的例子是思科 UCS 服务器,它在内部使用 FCoE。...将第 5 章中的 I/O 操作和网络流量模式一节与前一节进行比较,可以发现流量模式之间有惊人的相似之处。因此,与网络拥塞的相关性也很相似。...需要注意的是,多年来,Cisco 设备上的 LLFC 和 PFC MIB 计数器一直受到某些固件版本和交换机型号执行不力的影响。在依赖返回值之前,请验证它们是否与交换机上的命令行输出相匹配。

    39010

    超越架构师!消息通知系统优化设计

    SQS队列在需要发送大量通知时充当缓冲区。每种通知事件类型都分配到一个独立的消息队列,以便一个发送服务的中断不会影响其他通知类型。...Worker — 从SQS队列轮询通知事件并将其发送到相应的服务的Lambda服务列表。 SNS或第三方服务 — 这些服务负责将通知传递给消费者。在与第三方服务集成时,我们需要关注可扩展性和高可用性。...为了避免向用户发送过多通知,通过使用SQS并限制用户在一段时间内可以接收的通知数量,我们可以提高通知系统的礼貌度。...监视队列中的通知和事件跟踪 我们应该使用AWS CloudWatch指标监视通知系统。要监视的关键指标是EventBirdge中的事件总数和排队通知的总数。...如果这两个指标很大,那么通知事件没有被工作人员快速处理。这意味着我们应该扩展,需要更多的工作人员。 事件跟踪 — 一些重要的自定义指标,如开放率、点击率和参与度,对于理解客户行为很重要。

    23810

    消息通知(Notification)系统优化

    SQS队列在需要发送大量通知时充当缓冲区。每种通知事件类型都分配到一个独立的消息队列,以便一个发送服务的中断不会影响其他通知类型。...Worker — 从SQS队列轮询通知事件并将其发送到相应的服务的Lambda服务列表。 SNS或第三方服务 — 这些服务负责将通知传递给消费者。在与第三方服务集成时,我们需要关注可扩展性和高可用性。...为了避免向用户发送过多通知,通过使用SQS并限制用户在一段时间内可以接收的通知数量,我们可以提高通知系统的礼貌度。...监视队列中的通知和事件跟踪 我们应该使用AWS CloudWatch指标监视通知系统。要监视的关键指标是EventBirdge中的事件总数和排队通知的总数。...如果这两个指标很大,那么通知事件没有被工作人员快速处理。这意味着我们应该扩展,需要更多的工作人员。 事件跟踪 — 一些重要的自定义指标,如开放率、点击率和参与度,对于理解客户行为很重要。

    23210

    一文掌握Serverless中的异常处理

    2 错误处理的最佳实践 2.1 死信队列 (DLQs) AWS SQS 中的死信队列 (DLQ) 是一个单独的队列,用于捕获和存储 Lambda 函数在处理 SQS 队列时无法成功处理的消息。...解决方案 为 SQS 队列配置死信队列,以捕获和存储无法成功处理的消息。使用 DLQ 进行调查并重新处理失败的消息。...解决方案 实现带有指数回退的自动重试,以减轻瞬时故障。这有助在暂时问题期间防止向下游服务发送过多请求。 指数回退是一种技术,其中重试尝试之间的时间呈指数增长。...Error'         }     finally:         logger.info('Lambda execution completed.') 2.4 自定义错误响应 场景 API 的消费者在收到缺乏细节的通用错误响应时面临挑战...这种方法简化了对模式的识别,加快了问题解决速度。 3.2 自定义指标和仪表板 通过为 Lambda 函数创建自定义 CloudWatch 指标来扩展你的监控能力。

    16010

    扫盲消息队列 | 消息中间件 | Kafka

    日常开发中需要关心哪些指标 1.生产消息数目 每分钟几百几千个都正常水平吧,业务繁忙的每分钟几万几十万也是有的 ?...这个新手也一定要知道啦,因为面试官会问。...消息的顺序问题:如 Producer 发送顺序是123,Consumer 收到的消息是132,要考虑消费端是否对顺序敏感。...一致性问题: 如消息丢失问题真的发生且无法找回,会造成两个系统的数据最终不一致,如果消息延迟,会造成短暂不一致。...ZeroMQ:扩展性好,开发比较灵活,采用C语言实现,实际上他只是一个socket库的重新封装,如果我们做为消息队列使用,需要开发大量的代码 Amazon SQS 关于消息队列的常见面试题 为什么使用消息队列

    1.9K11

    DevOps成功并不总是数字上升

    在与管理层的会议中,我们会讨论我们这个小型新成立团队的成功标准,这将带来进一步的惊吓。 “写一篇知识文章需要多长时间?”是第一个令人不寒而栗的问题,就好像“一篇文章”可以是一个可量化的指标一样。...由于这种心态,我经常被阻止使内容变得有用,这意味着即使人们能够找到它,他们也并不总是能得到他们需要的帮助。 所以,如果帮助内容找不到或无法理解……为什么要有知识库呢?...但是,嘿,对于那些向上汇报的人来说,一切都很好:“我的团队表现出色,因为你看,数字在上升!” 其中一些冲突指出了一个系统性的文化问题,突出了当团队没有共享目标时,事情会变得多么糟糕。...它还建议在与你的技术指标相同的系统中跟踪业务指标,以查看技术变更何时对业务产生负面或正面影响,反之亦然。 仔细分析数字(贬义) 听着,我理解在商业中,一些数字必须上升是自然的。...然而,将“数字上升”作为衡量所有任务成功的唯一指标,就等于否认了你对整个业务中价值的含义的完整理解。

    11910

    为什么时间戳对网络流量数据包捕获很重要?

    网络数据包时间戳可用于调查以某种方式影响网络性能的事件。例如,跟踪数据包的到达可让你了解原始流量,以便可以计算诸如性能指标之类的链路指标,或诸如TCP流吞吐量、延迟和抖动之类的应用程序性能。...因此,高精度地给数据包加上时间戳的能力,对于了解逐包级别网络中正在发生的事情至关重要。准确的时间信息对于法律和刑事调查也是非常重要,准确性要求很高的法医分析也同样适用。...简而言之,时间戳是与传入和事件传出数据包关联的本地系统时间的快照。用于指定数据包通过网络访问设备转发的时间。...它可以分为入口时间戳——指定设备接收到数据包的第一位的时间,以及出口时间戳——指定从设备发送数据包的第一位的时间。 时间不正确的数据包会导致识别和解决问题的延迟,因此必须加盖时间戳。...在网络危机期间,网络和系统团队互相指责,因为网络和服务器数据之间缺少与数据包到数据包响应时间相匹配的任何关联。

    1.4K62

    ElasticMQ 0.7.0:长轮询,使用Akka和Spray的非阻塞实现

    主要的客户端改进是: 支持长轮询,这是SQS前一段时间的补充 更简单的独立服务器 - 只需下载一个jar包 使用长时间的轮询的过程中,当收到消息时,可以指定一个额外的的MessageWaitTime属性...这有助于减少带宽的使用(不需要非常频繁地进行请求),进而提高系统整体性能(发送后立即收到消息)并降低SQS成本。 独立的服务器现在是一个单一的jar包。...为了与actor沟通,使用了类型化问答模式。...,rootPath会匹配出空路径(...)。...当接收到消息的请求到达时,队列中没有任何内容产生,而是立即回复(即向发送者actor发送空列表),我们将储存原始请求的引用和发送方actor在map中。

    1.6K60

    Elastic可观测解决方案为集成插件启用时序数据流,可节省高达 70% 的指标存储空间

    使用标准 (30.4GB) 与时间序列 (5.9GB) 模式存储的指标的索引大小比较 当您将文档添加到 TSDS 时,Elasticsearch 会根据其@timestamp值将该文档添加到适当的索引里面...因此,TSDS 可以将文档添加到任何可以接收写入的 TSDS 支持索引。即使该索引不是最新的支持索引,这也适用。 ? 应用程序正在扩展,数据正在以指数速度增长,存储成本也随之增加。...大多数组织需要做出艰难的决定,决定保留或删除哪些数据以保持在预算之内。通过 Elastic 的优化,您对云存储(例如 S3)的使用将会降低,并减少将数据移动到“冷”存储的需要。...这自然会允许您扩展指标存储以获取更长期的指标数据,这将有助于分析模式(长期分析)、减少 MTTx 并提高应用程序的整体性能。...用户的额外收益 除了大幅节省存储成本之外,支持时间序列的集成插件还带来了一种新的指标数据存储方法,与常规数据流相比,具有几个独特的优势: 高效索引: TSDS 通过利用基于维度的路由、内部索引排序和有时间范围的支持索引来优化索引和存储

    1.5K61

    (第4篇) 大型网站核心架构,我们必须要理解这些性能指标

    今天这篇我们先从基础开始,去掌握必须知道的性能指标,只有扎实的基础才能让我们走的更远。 性能概要 当我们在浏览器上打开一个网页,会直接感受到这个网站响应速度快还是慢。...与传播介质的并行度有关。传输介质可以看成是多车道马路,数据由0/1组成,每股车道每次只能容纳一个0/1。因此,如果马路的车道增多,那么每次发送的0/1也就增多,从而提高了发送速度(即带宽)。...响应时间 指应用执行一个操作需要的时间, 响应时间(RT)是指从客户端发一个请求开始计时,到客户端接收到从服务器端返回的响应结果结束所经历的时间,响应时间由请求发送时间、网络传输时间和服务器处理时间三部分组成...响应时间是系统最重要的性能指标,直观地反映了系统的"快慢",我们要客观知道一个服务的响应时间,通常是通过记录收到响应和发出请求之间的时间差来计算系统响应时间。...服务器健康度 它是描述服务器或操作系统性能的一些数据指标。 包括System Load、对象与线程数、内存使用、CPU使用、磁盘与网络I/O等指标。

    31420

    使用Celery构建生产级工作流编排器

    Tasks Worker:负责执行涉及 Pandas 和模型预测的实际任务,并且计算量也很大。...-O Fair flag:默认情况下,预分叉 Celery 工作人员会在收到任务后立即将任务分配给他们的工作进程,而不管进程当前是否正忙于其他任务。...它们可以存储任务结果,并且也可以将缓存放在一边策略与 DynamoDB 和 S3 等数据库一起使用,以满足成本优化架构需求。...ELK Stack:发送所有 Celery 任务状态日志的一种方法是在工作进程启动时劫持 Celery 记录器,并为其附加 Fluentd 处理程序,这将发送包含任务持续时间、在执行期间传递给任务的参数和关键字参数以及任务状态的日志...如果流量很大,则更多侦听同一队列的工作进程将解决此问题。为了定义最佳扩展策略,我们查看队列指标,例如 Amazon SQS 上提供的指标。 使用 SQS 指标调整策略 扩展和生产设置?

    40810

    ​我们如何将 OpenTelemetry 与 Prometheus 指标相结合来构建强大的告警机制

    当链路跟踪与警报条件匹配时(例如,数据库查询时间超过 5 秒),我们将跨度转换为 Prometheus 指标。 Prometheus模型符合我们的目标。...在 Helios 中,对用户来说的一个主要好处是,我们可以从分布式链路跟踪数据转换为指标,也可以从指标返回到特定链路跟踪,因为我们维护指标的上下文。...SNS-SQS 报告警报。...触发警报后,我们会向 Prometheus 查询警报定义的时间序列(如前所述,客户和警报定义 ID 的组合),并获取指标列表作为警报查询的实例 - 每个指标都有其匹配的跨度和跟踪 ID。...例如,获取在收到警报后直接触发的警报的匹配跨度 ID(即,作为 Prometheus 报告的警报有效负载的一部分)对我们来说并不适用,因此我们必须向 Prometheus 发送另一个 API 调用并查询它们

    1.8K21

    Cloudflare 如何大规模运行 Prometheus

    当 Prometheus 收集指标时,它会记录每次开始收集的时间,然后使用它作为每个时间序列的时间戳值对。 这就是为什么应用程序输出的不是真正的指标或时间序列,而是样本。 是不是很困惑?...因此,内存使用会形成一个循环——当我们添加第一个样本时,内存使用量较低,然后内存使用量缓慢上升,直到新建一个样本块,然后重新开始。...设置 label_limit 提供了一定程度的基数保护,但即使只有一个标签名,如果值很多的话,我们也会遭遇高基数。传递 sample_limit 是防止高基数的终极武器。...这样,即使是最缺乏经验的工程师也可以开始输出指标,而不用总是担心“这会导致意外事件吗?”。 另一个原因是,试图掌握使用情况是一项具有挑战性的任务。...例如,我们在前面的示例中使用的 errors_total 指标,可能在我们开始看到一些错误之前根本就不存在,即使看到了错误,也可能只记录一两个错误。工程师正在使用的许多标签都是如此。

    60220

    「大型网站架构设计」—— 网站性能测试

    、尽可能近地获取页面内容,即使不优化应用程序和架构,也可以很大程度地改善用户视角下的网站性能。...响应时间 响应时间:指应用执行一个操作需要的时间,包括从发出请求开始到收到最后响应数据所需的时间。 响应时间是系统最重要的性能指标。...客户机在发送请求时开始计时,收到服务器响应后结束计时,以此来计算使用的时间和完成的事务个数。...车辆很少时,车速很快,但是收到的高速费也相应较少;随着高速公路上车辆数目的增多,车速略受影响,但是收到的高速费增加很快;随着车辆的继续增加,车速变得越来越慢,高速公路越来越堵,收费不增反降;如果车流量继续增加...包括: a)System Load; b)对象与线程数; c)内存使用; d)CPU 使用; e)磁盘与网络 I/O; 等指标。

    1.9K20

    80% or 90%?--告警设置之动态阈值最佳实践

    与现有的静态阈值告警功能相比,动态阈值弥补了静态阈值场景能力、配置门槛和维护成本上的不足。 如何配置动态阈值告警?...这个功能主要是提供给一些特点的指标场景,例如成功率只关注下降的方向,失败率值关注上升的方向等。 持续周期:目前最小的选择是持续 1 个周期,表示连续俩个异常点,才会发送告警。...对应的,发送恢复也是需要持续 2 个点正常才发送恢复。  每 1 天告警 1 次:当告警一直为恢复时,用户可以定义多久收到一次告警。...这种情形出现一定幅度的突增,则会向你发送告警,更容易在问题初期收到告警,去关注解决。 场景三: 当然,如果你觉得必须到达某个值,才想看告警。...而动态阈值,你只需要选择 “大于或小于” 的上下方向,系统会帮你自适应的去识别出突增和突降。 同时,经过一段时间,可能统计量上升到 550 为合理的值。

    10K42

    MQ·将多消息合并为一条消息的发送、消费的设计与实现

    由于mq使用的是亚马逊的sqs服务,而sqs是按请求数消费的原因,所以才有的将多消息合并为一条消息发送的想法。...本篇将介绍如何将多个消息合并成一个消息发送而不影响服务的并发性能,以及由于合并后产生的大消息消费出现的消息堆积现象,开的消费者越多反而消息堆积越多的bug。 为什么要将多消息合并为一个消息发送?...以每分钟50w的广告点击数来算,一个月将产生50*60*24*31w的点击消息,再乘以3就是每个月的sqs请求数,3代表的是发送消息、拉取消息、删除消息,按每100w请求0.4美刀的价格计算大概一个月要...由于sqs限制单条消息的大小最大为256k,根据业务场景估算每点击消息也不可能达到1k,,所以我将256个请求合并为一个消息发送,或者1s内未达到256个消息也合并为一个消息发送,这样每月的费用可以直接除以...我借签Dubbo的客户端与服务端配置多个连接时使用轮询方式使用连接,同时也借签了netty的EventLoop的设计,实现消息合并发送。

    4.1K10

    警告:有用的警告|让Kubernetes的使用越来越容易

    警告是使用标准的Warning响应头发送的,因此它不会以任何方式更改状态代码或响应体。这允许服务器发送警告,任何API客户端都可以轻松读取,同时保持与以前的客户端版本兼容。...即使对于全职从事项目的人来说,跟上每个版本中的变化也是一件令人生畏的事情。一种重要的改变是API的弃用。随着Kubernetes中的API升级到GA版本,预发布的API版本将被弃用并最终被删除。...即使有一个延长的弃用期,并且在发布说明中包含了弃用,它们仍然很难跟踪。在弃用期间,预发布API仍然有效,允许多个版本转换为稳定的API版本。...我们可以将这些信息与apiserver_request_total指标连接起来,以获得关于向这些API发出的请求的更多细节: kubectl get --raw /metrics | prom2json...当API请求自定义资源的已弃用版本时,将返回一条警告消息,与内置API的行为相匹配。 如果需要,CustomResourceDefinition的作者还可以为每个版本定制警告。

    1.9K30
    领券