监控到容器的cpu使用率过高问题

当Grafana监控到Container Cpu Usage is high指标并告警，则说明activemq容器cpu使用率过高，为避免业务因 CPU 资源不足而受影响，建议提前对 CPU 利用率过高的实例进行业务优化，例如控制高并发，或者升级 CPU 资源，若参数调整后，而 CPU 利用率依然偏高，建议找维护人员升级 CPU 的配置，进而提高activemq的整体性能

排查方法

通过top命令找到可疑进程PID，或者top -H找出消耗资源最高的线程

查看这个线程所有系统调用strace -p 24167

通过这3步基本可以找出什么原因导致java进程占用那么高CPU资源

监控到容器网络入流量/网络出流量告警问题

当Grafana监控到Container Network Throughput In is high/Container Network Throughput Out is high指标告警，则表示出现网络流量过高的情况，通常是因为服务器与服务器之间拷贝数据导致的，拷贝结束，流量即可恢复正常，如果不是数据拷贝，通常是服务器中毒或者受到攻击，在对内或对外大量发包导致，此时，可按照以下方法进行排查

• 如果您使用的是Linux系统的服务器，可以在系统中安装nethogs查看具体的进程占用流量的情况（如nether eth0->查看网卡具体流量）并杀死该进程;对于一些常见的网络问题，如容器之间网络通信问题，您可以使用Tcpdump工具捕获网络流量，来解决这些网络问题
• 如果您使用的是windows系统，可通过资源监视器（启动任务管理器>资源监视器>网络）看到哪些进程占用网络流量并结束相关进程

监控到容器down告警问题

当prometheus监控到容器down指标Container Killed告警，说明容器可能失效或终止运行，以异常状态退出或健康检查失败，k8s的核心组件 kubelet会根据设置的pod重启策略自动重启该容器，例如容器运行时内存超出限制，容器以Failed状态终止，kubelet则自动重启该容器。而pod中的守护进程supervisor会保证activemq服务自动重启。

监控到容器内存使用率过高问题

当prometheus监控到Container Memory Usage is high 告警，说明容器内存使用率过高， 检查是否除activemq相关进程在运行外，还有其他不必要进程在运行，若有，可以关闭非必要进程。若是activemq已超过已使用流量的阈值，导致容器的memary的使用率超过预期，可以结合activemq的内存使用率进行分析，见下面提到的内存使用率过高问题

监控到容器存储使用率过高问题

当prometheus监控到 Container Volume Usage is high告警，说明容器的存储使用率过高， 首先检查是哪一个目录的磁盘量已快耗尽，如果是activemq的挂载目录的磁盘已快满，考虑定时删除过期的消息文件，或是由于备份文件过大，可以增大磁盘容量，如果是其他目录，检查是否有垃圾缓存，或者其余日志文件，可以考虑只保留最新的内容。

监控到ActiveMQ内存使用率过高问题

当prometheus监控到
activemq_memory_usage_ratio指标告警，则反映activemq使用内存接近耗尽

可能原因及现象

当消息数量超过了broker资源的限制，导致内存耗尽，生产者收到broker的阻塞信息提示，生产缓慢 或不再生产消息，broker几乎停止对外服务

解决办法

• 消费者端流控 在消费者端，流量控制是通过prefetchSize参数来控制未确认情况下，最多可以预获取多少条记录 ，如 tcp://localhost:61616?jms.prefetchPolicy.all=50 tcp://localhost:61616?jms.prefetchPolicy.queuePrefetch=1
• 生产者端流控 /opt/apache-activemq-5.14.3/conf/activemq.xml中添加<sendFailIfNoSpaceAfterTimeout>属性，单位是毫秒，它会阻塞指定的时间，如果超过了这个时间还是没有可用的内存，则会发送异常给生产端，其配置如下
• 增加虚机内存，增加容器应用的内存预留，升级应用

监控到ActiveMQ硬盘空间使用量告警问题

当prometheus监控到
activemq_store_usage_ratio指标告警，则反映持久化消息几乎占满硬盘，分配的硬盘空间使用量接近耗尽， 此时生产者阻塞，但消费者可正常连接并消费消息，等消息消费掉一部分，文件删除又腾出空间之后，生产者又可继续发送消息，服务自动恢复正常

报错日志：Usage Manager Store is Full, 100% of 1073741824. Stopping producer (
ID:db01-48754-1336034955132-0:5:1:1) to prevent flooding
queue://queue.land.group...

原因分析

如果持久订阅者很多，有几个一直不在线，则导致db-.log文件中的持久化消息一直保留，只有所有持久订阅者上线后才会删除db-.log ， 若是有很多持久订阅者不在线，分配的磁盘就可能撑爆

解决办法

• 检查持久订阅者是否异常下线
• 在/opt/apache-activemq-5.14.3/conf/activemq.xml文件中增加硬盘分配

监控到ActiveMQ临时文件硬盘空间使用量告警问题

当prometheus监控到activemq_temp_usage_ratio指标告警，则反映产生的非持久化消息过多使得分配的临时文件硬盘空间使用量达到上限

解决办法

在
/opt/apache-activemq-5.14.3/conf/activemq.xml文件中增加临时硬盘分配

监控到ActiveMQ的未消费消息数量告警问题

当prometheus监控到activemq_queue_queue_size(队列的未消费消息数量)或activemq_topic_queue_size（某主题订阅者未消费消息数量）指标告警，则反映未被消费的消息数量过多，pending消息堆积则可能导致activemq的整体性能下降

解决办法

设置消息的全局过期时间，在broker节点下增加如下的配置

ttlCeiling表示过期时间上限（程序写的过期时间不能超过此时间，超过则以此时间为准） zeroExpirationOverride表示过期时间（给未分配过期时间的消息分配过期时间)

消息过期后会进入死信队列，AcitveMQ提供了一个便捷的插件DiscardingDLQBrokerPlugin来抛弃死信队列或主题，配置如下

超过最大客户端连接数问题

当连接到activemq的生产者消费者客户端超过一定数量，通过grafana查看
/opt/apache-activemq-5.14.3/data目录下的activemq.log，发现报错

2020-03-04 20:25:27,760 | ERROR | Could not accept connection : org.apache.activemq.transport.tcp.ExceededMaximumConnectionsException: Exceeded the maximum number of allowed client connections. See the 'maximumConnections' property on the TCP transport configuration URI in the ActiveMQ configuration file (e.g., activemq.xml) | org.apache.activemq.broker.TransportConnector | ActiveMQ Transport Server Thread Handler: mqtt://0.0.0.0:1883?maximumConnections=100&wireFormat.maxFrameSize=104857600

解决办法

/opt/apache-activemq-5.14.3/conf/activemq.xml中修改对应协议的<maximumConnections>参数

Activemq内存分配问题

在
/opt/apache-activemq-5.14.3/conf/activemq.xml文件中配置内存分配

订阅者下线断连问题

原因分析

ActiveMQ InactivityMonitor是一个活动线程，用于检查连接是否仍处于活动状态，如果默认30秒钟内未从连接中写入或读取任何数据，则InactivityMonitor将启动 InactivityMonitor引发InactivityIOException并关闭与该连接关联的传输。将导致以下调试日志记录

2012-06-26 17:13:55,712 | DEBUG | 30000 ms elapsed since last read check. | org.apache.activemq.transport.AbstractInactivityMonitor | InactivityMonitor ReadCheck 2012-06-26 17:13:55,712 | DEBUG | No message received since last read check for tcp:///127.0.0.1:52659! Throwing InactivityIOException. | org.apache.activemq.transport.AbstractInactivityMonitor | InactivityMonitor ReadCheck 2012-06-26 17:13:55,714 | DEBUG | Transport Connection to: tcp://127.0.0.1:52659 failed: org.apache.activemq.transport.InactivityIOException: Channel was inactive for too (>30000) long: tcp://127.0.0.1:52659 ...

解决办法

在建立连接的Uri中加入<
wireFormat.maxInactivityDuration=0>，关闭不活动状态监测