AWS中SQS队列的实时监控
提供实时监视发送到SQS队列的消息总数的最佳方法是什么？
我目前设置了一个Grafana仪表板来监视一个SQS队列，但它似乎大约每两分钟刷新一次。我正在寻找的东西设置，以更新几乎是实时的，例如刷新每秒。
我使用的队列每分钟大约消耗6,000条消息。
我的同事已经构建了一些用于实时监控上传到S3 bucket的东西，使用lambda填充PostgreSQL数据库，并使用Grafana查询。
这是否达到目的的最佳方法呢？有没有更有效率的办法？
共有1个答案
SQS不是事件驱动的-必须轮询它。因此，每次将消息放入队列或从队列中移除时，并不存在一个事件。在S3 to Lambda中，每次创建或删除对象时，都会实时发送一个事件。
您可以更改SQS的轮询间隔，并以您想要的速度进行轮询。但请注意轮询是有代价的。每月前100万次请求是免费的。
-
我有一个IAM用户的策略，该策略是为从特定SQS队列发送和接收消息而创建的。当使用AWS CLI并发出命令时，会出现错误： 我认为应该只返回IAM用户被授予该操作的队列，这是不是错了？ 欢迎任何指导/建议！谢了！
-
我正在尝试设计一个基于SQS、Lambda和SNS的小型消息处理系统。在失败的情况下，我希望将消息排入死信队列(DLQ)中，并调用webhook。 目前，如果一切顺利，流程应该是这样的： SQS（用于处理重试）将消息排入队列 lambda由SQS调用并处理消息 lambda发送webhook，并正常完成 如果lambda中的某些东西出错（无法调用success webhook，无法处理手头的任务）
-
我试图实现一个AWS SQS队列，以最大限度地减少来自后端服务器的数据库交互，但我遇到了问题。 我有一个消费者进程，它从一个SQS队列中查找消息 为了测试功能，我为一个客户端实现了逻辑。它运行得很好。然而，当我添加了3个客户端时，它不能正常工作。我能够看到SQS队列被500条消息卡住了，后端作业正在正常工作，从队列中读取。 我需要增加后端作业的数量还是增加客户端SQS队列的数量？现在，所有客户端都
-
假设我有两个单独的服务，A和B，它们的SQS队列都订阅了SNS主题“topic-foo”。然后我发布一个消息m1到SNS主题“topic-foo”。 如果服务A拥有的SQS队列（sqs-A）看到了消息m1并对其进行处理（即将其从队列中弹出并处理该消息，使其不再在sqs-A上），是否仍然可以保证服务B拥有的单独的SQS队列（sqs-B）始终能够看到并处理消息m1？（换句话说，AWS SNS发布是否保
-
解决方案#3:使用AWS SQS标准队列和AWS ElasticCache（Redis或Memcached）。对于每条消息，“messageID”字段将保存在缓存服务器中，并在以后检查是否重复。存在意味着此消息已被处理。（顺便说一下，“MessageID”在缓存服务器中应该存在多长时间。AWS SQS文档没有提到消息可以重复到多长时间。）
-
我们试图使用aws sqs临时队列库在我们的两个应用程序之间进行同步通信。一个应用程序使用，而另一个应用程序使用-这两个应用程序都是使用库中的构建器创建的，并作为Spring bean连接到应用程序配置中。通过AWS控制台，我们创建了一个SQS队列，作为请求/返回模式所需的“主机队列”。请求应用程序发送到此队列，响应应用程序使用SQSMessageConsumer轮询队列并将消息传递到。库的部分工