ActiveMQ Artemis 2.17.0每两周服务降级问题求助

环境与配置说明 #

本地部署对称集群拓扑，包含3个broker主节点以实现高可用和容错，每日处理数百万条消息，拥有数千个地址和队列，已开启持久化配置：<persistence-enabled>true</persistence-enabled>。

集群连接配置 #

<cluster-connections>
   <cluster-connection name="my-cluster">
      <address></address> <!-- Empty address means load balancing messages -->
      <connector-ref>artemis</connector-ref>
      <message-load-balancing>ON_DEMAND</message-load-balancing>
      <max-hops>1</max-hops>
      <discovery-group-ref discovery-group-name="dg-group1"/>
   </cluster-connection>
</cluster-connections>

HA策略配置 #

<ha-policy>
   <replication>
      <master>
         <vote-on-replication-failure>true</vote-on-replication-failure>
      </master>
   </replication>
</ha-policy>

地址设置示例 #

<address-setting match="status.#">
  <dead-letter-address>DLQ</dead-letter-address>
  <expiry-address>ExpiryQueueStatus</expiry-address>
  <auto-create-expiry-resources>true</auto-create-expiry-resources>
  <expiry-queue-prefix>EXP.</expiry-queue-prefix>
  <min-expiry-delay>10</min-expiry-delay>
  <max-expiry-delay>600000</max-expiry-delay>
  <redistribution-delay>1000</redistribution-delay>
  <redelivery-delay>0</redelivery-delay>
  <!-- with -1 only the global-max-size is in use for limiting -->
  <max-size-bytes>100Mb</max-size-bytes>
  <page-size-bytes>10Mb</page-size-bytes>
  <message-counter-history-day-limit>10</message-counter-history-day-limit>
  <address-full-policy>PAGE</address-full-policy>
  <auto-create-queues>true</auto-create-queues>
  <auto-create-addresses>true</auto-create-addresses>
  <auto-create-jms-queues>true</auto-create-jms-queues>
  <auto-create-jms-topics>true</auto-create-jms-topics>
  <auto-delete-addresses>false</auto-delete-addresses>
  <auto-delete-queues>false</auto-delete-queues>
  <auto-delete-created-queues>false</auto-delete-created-queues>
</address-setting>

<address-setting match="ExpiryQueueStatus">
  <expiry-queue-suffix></expiry-queue-suffix>
  <min-expiry-delay>10</min-expiry-delay>
  <max-expiry-delay>3600000</max-expiry-delay>
  <redistribution-delay>1000</redistribution-delay>
  <redelivery-delay>0</redelivery-delay>
  <max-size-bytes>100Mb</max-size-bytes> 
  <page-size-bytes>10Mb</page-size-bytes>
  <address-full-policy>PAGE</address-full-policy>
  <auto-create-queues>true</auto-create-queues>
  <auto-create-addresses>true</auto-create-addresses>
  <auto-create-jms-queues>true</auto-create-jms-queues>
  <auto-create-jms-topics>true</auto-create-jms-topics>
</address-setting>

<address-setting match="#">
  <expiry-queue-suffix></expiry-queue-suffix>
  <min-expiry-delay>10</min-expiry-delay>
  <max-expiry-delay>3600000</max-expiry-delay>
  <redistribution-delay>1000</redistribution-delay>
  <redelivery-delay>0</redelivery-delay>
  <max-size-bytes>100Mb</max-size-bytes>
  <page-size-bytes>10Mb</page-size-bytes>
  <address-full-policy>PAGE</address-full-policy>
  <auto-create-queues>true</auto-create-queues>
  <auto-create-addresses>true</auto-create-addresses>
  <auto-create-jms-queues>true</auto-create-jms-queues>
  <auto-create-jms-topics>true</auto-create-jms-topics>
</address-setting>

问题现象 #

每两周左右出现服务降级，部分应用正常、部分异常，Artemis服务仍处于运行状态。当日志目录占用超过可用内存（journal目录有时增长至几十GB）时，清理/var/lib/artemis/data/journal和/var/lib/artemis/data/paging目录后重启服务，所有应用即可恢复正常。目前无法直接访问应用，也无明确日志解释该现象。

排查建议 #

• 优化日志采集与级别调整：将Artemis日志级别临时调整为DEBUG或TRACE（重点关注集群通信、持久化、分页、过期消息处理相关日志），配置日志轮转避免磁盘溢出，保留足够周期的日志以便定位问题。
• 分析持久化与分页目录增长原因：
  • 检查DLQ（死信队列）和过期队列是否有未被消费的消息堆积，确认是否存在消息无法被正常消费的场景；
  • 统计地址队列的消息留存情况，排查是否有大量未确认、未签收的持久化消息；
  • 验证max-size-bytes和address-full-policy=PAGE的实际生效情况，确认分页机制是否正常触发，是否存在分页文件无法被清理的情况。
• 集群状态一致性检查：
  • 使用Artemis控制台或artemis queue stat等命令定期检查集群各节点的队列状态、消息计数、内存使用情况，确认是否存在节点间状态不一致的情况；
  • 排查集群连接是否稳定，检查是否存在频繁的节点断开、重连日志，确认discovery-group配置是否正常，网络是否存在间歇性波动。
• 资源使用监控：
  • 部署监控工具跟踪Artemis的JVM内存（堆、非堆）、CPU、磁盘IO使用情况，重点关注服务降级前的资源变化趋势；
  • 监控journal目录的写入频率与文件清理机制，确认Artemis的journal压缩、清理配置是否合理（默认配置可能不满足高消息量场景）。
• 配置优化验证：
  • 检查auto-delete-addresses和auto-delete-queues均为false，确认是否存在大量废弃的地址/队列未被清理，导致元数据堆积；
  • 调整过期消息处理配置，验证expiry-address的消息是否被及时消费或清理，避免过期消息堆积；
  • 考虑调整message-load-balancing策略，结合实际业务场景验证是否需要从ON_DEMAND调整为STRICT或其他策略，优化集群负载分布。
• 模拟场景复现：在测试环境模拟高消息量、大量地址队列的场景，尝试复现服务降级现象，逐步排查配置与业务逻辑的潜在问题。

内容的提问来源于stack exchange，提问作者Andrea Carubelli