0

AMQ 5.7 在这里。我继承了一组非常古老的 Java 应用程序，它们使用 ActiveMQ (AMQ) 代理在彼此之间以及与该生态系统之外的客户端进行通信。因此，AMQ 代理上有数百个（!!!）队列，实际上有数百个JMS 客户端生活在数十个不同的服务器上（每个）向这些队列发布消息并使用这些队列中的消息。它是一个老鼠窝。

我有一个队列，我们​​称之为它shouldBeDead，它不应该再接收任何消息。它在某个时间点被弃用，不再向该队列发送消息。然而，它会定期受到来自某处/某处的数百条消息的轰炸。它上面没有消费者（这是正确的；我的 Java 应用程序套件不再在其代码中的任何地方使用它，因此没有任何东西在该队列上侦听以从中消耗消息）。

更复杂的是，这是一个旧的 AMQ 版本，它存在TLDR的已知 UI 错误；是：我需要将AMQ实例升级到> 5.12.x。但是，由于此问题范围之外的原因，我目前无法升级 AMQ。因此，虽然我希望浏览排队的消息并深入了解它们以获取有关它们的信息，但我什至无法在 AMQ Web UI 或应用程序日志中查看它们。shouldBeDead

我只是想弄清楚这些消息来自哪里！

进行网络分析可能很有成效，但超出了我的技能范围，这些消息在看似随机的时间涌入队列，没有任何可辨别的模式。

我希望我可以做一些 AMQ 命令行来检查队列元数据，也许可以窥探 KahaDB 或我可以做的任何其他类型的魔法来查看这些消息和/或从中获取跟踪/客户端信息.

最坏的情况我知道我可以部署一些代码更改以重新添加shouldBeDead侦听器/消费者并记录消息，但是我真的试图在不进行任何代码更改的情况下做到这一点。有什么想法/想法吗？提前致谢！

4

1 回答 1

1

我会通过JMX console.

这是通过 JMX 可用的诊断信息列表，这是一种如何通过命令行访问此数据的方法。通过了解问题的确切细节，例如：

  • 这些爆发的可预测性如何
  • 大概有多少条消息
  • 发送了你有多少个连接

您需要捕获相关信息才能抓住您的制作人。

当然，在不知道细节的情况下，一个可行的想法是：
定期运行一个 bash 脚本来检查队列的大小（如Destination/EnqueueCount）+ 定期保存所有活动连接。当您检测到已弃用队列上的消息出现峰值时，请回顾一下当时刚刚出现的连接 ( Connection/RemoteAddress)。

于 2018-10-17T19:41:12.017 回答