本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# Amazon MQ 上的 ActiveMQ 问题排查
<a name="troubleshooting-activemq"></a>

使用本节信息帮助您诊断和解决使用 Amazon MQ 代理上的 ActiveMQ 时可能遇到的常见问题。

**Contents**
+ [尽管我已经激活了日志记录，但我仍无法在 CloudWatch 日志中看到我的经纪人的常规日志或审计日志。](#issues-cw-logging-activemq)
+ [代理重启或维护时段后，即使状态为 `RUNNING`，我也无法连接到我的代理。为什么？](#issues-connection-after-restart)
+ [我看到我的一些客户端可以连接到代理，而其他客户端则无法连接。](#issues-connection-limit)
+ [我在执行操作时，在 ActiveMQ 控制台上看到 `org.apache.jasper.JasperException: An exception occurred processing JSP page` 异常。](#issues-jsp-exception)

## 尽管我已经激活了日志记录，但我仍无法在 CloudWatch 日志中看到我的经纪人的常规日志或审计日志。
<a name="issues-cw-logging-activemq"></a>

 如果您无法在 Logs 中查看经纪人的 CloudWatch 日志，请执行以下操作。

1. 检查创建或重启代理程序的用户是否具有 `logs:CreateLogGroup` 权限。如果您未在用户创建或重启代理之前将 `CreateLogGroup` 权限添加给该用户，则 Amazon MQ 不会创建日志组。

1. 检查您是否已将基于资源的策略配置为允许 Amazon MQ 将日志发布到日志 CloudWatch 。要允许 Amazon MQ 将日志发布到您的日志 CloudWatch 日志组，请配置基于资源的策略以授予 Amazon MQ 访问以下日志 API 操作的权限： CloudWatch 
   +  [https://docs.amazonaws.cn/AmazonCloudWatchLogs/latest/APIReference/API_CreateLogStream.html](https://docs.amazonaws.cn/AmazonCloudWatchLogs/latest/APIReference/API_CreateLogStream.html)— 为指定的 CloudWatch 日志组创建日志日志流。
   +  [https://docs.amazonaws.cn/AmazonCloudWatchLogs/latest/APIReference/API_PutLogEvents.html](https://docs.amazonaws.cn/AmazonCloudWatchLogs/latest/APIReference/API_PutLogEvents.html)— 将事件传送到指定的 CloudWatch 日志日志流。

 [有关在 Amazon MQ 上配置 ActiveMQ 以将日志 CloudWatch 发布到日志的更多信息，请参阅配置日志。](https://docs.amazonaws.cn/amazon-mq/latest/developer-guide/configure-logging-monitoring-activemq.html)

## 代理重启或维护时段后，即使状态为 `RUNNING`，我也无法连接到我的代理。为什么？
<a name="issues-connection-after-restart"></a>

 您可能会在您启动的代理重启后、计划的维护时段完成后或在故障事件中遇到连接问题，此时备用实例会激活。无论是哪种情况，代理重启后的连接问题很可能是由于在您代理的 Amazon EFS 或 Amazon EBS 存储卷中保留了异常大量的消息引起的。在重启期间，Amazon MQ 会将储存的消息从存储移动到代理内存。要确认此诊断，您可以监控 CloudWatch 适用于 ActiveMQ 的 Amazon MQ 经纪商的以下指标：
+  **`StoragePercentUsage`** - 达到或接近 100% 的大百分比会导致代理拒绝连接。
+  **`JournalFilesForFullRecovery`** - 表示在不正常关闭和重启后将重播的日志文件数。值增加或持续高于 1 表示存在未解决的事务，可能会在重启后导致连接问题。
+  **`OpenTransactionCount`** - 重启后的数字大于零表示代理将尝试存储以前使用的消息，从而导致连接问题。

 要解决此问题，我们建议您使用 `rollback()` 或 `commit()` 来解决 XA 事务。有关更多信息，以及要查看使用 `rollback()` 解决 XA 事务的代码示例，请参阅[恢复 XA 事务](best-practices-activemq.md#recover-xa-transactions)。

## 我看到我的一些客户端可以连接到代理，而其他客户端则无法连接。
<a name="issues-connection-limit"></a>

 如果您的代理处于 `RUNNING` 状态并且一些客户端能够成功连接到代理，而其他客户端无法连接，您可能已经达到了代理的[线级连接数](amazon-mq-limits.md#broker-limits)限制。要验证您是否已达到线级连接数限制，请执行以下操作：
+  在 “日志” 中查看您在 Amazon MQ 上的 ActiveMQ 代理的*通用*经纪人日志。 CloudWatch 如果已达到限制，您会在代理日志中看到 `Reached Maximum Connections`。有关亚马逊 MQ 代理上的 ActiveMQ CloudWatch 日志的更多信息，请参阅。[了解 CloudWatch 日志中登录的结构](configure-logging-monitoring-activemq.md#security-logging-monitoring-configure-cloudwatch-structure)

一旦达到线级连接数限制，代理将主动拒绝额外的传入连接。要解决此问题，我们建议升级您的代理实例类型。有关为工作负载选择最佳实例类型的更多信息，请参阅[Broker instance types](broker-instance-types.md)。

 如果您确认线级连接数低于代理的连接数限制，则问题可能与重新启动客户端有关。检查您的代理日志，查找大量且重复出现的 `... Inactive for longer than 600000 ms - removing ...` 条目。日志条目能够表明客户端重启或连接问题。当客户端通过 Network Load Balancer (NLB) 连接到代理，并经常断开连接而重新连接到代理时，这种迹象就会更加明显。这在基于容器的客户端中更为常见。

 请检查客户端日志，了解更多详细信息。代理将在 600000 毫秒后清理不活动的 TCP 连接，并释放连接套接字。

## 我在执行操作时，在 ActiveMQ 控制台上看到 `org.apache.jasper.JasperException: An exception occurred processing JSP page` 异常。
<a name="issues-jsp-exception"></a>

 如果您在授权队列和主题时使用简单的身份验证和配置 `AuthorizationPlugin`，请确保使用 XML 配置文件中的 `AuthorizationEntries` 元素，并允许 `activemq-webconsole` 群组拥有所有队列和主题的权限。这可以确保 ActiveMQ Web 控制台能够与 ActiveMQ 代理进行通信。

 以下示例 `AuthorizationEntry` 将所有队列和主题的读取和写入权限授予 `activemq-webconsole` 群组。

```
<authorizationEntries>
    <authorizationEntry admin="activemq-webconsole,admins,users" topic=">" read="activemq-webconsole,admins,users" write="activemq-webconsole,admins,users" />
    <authorizationEntry admin="activemq-webconsole,admins,users" queue=">" read="activemq-webconsole,admins,users" write="activemq-webconsole,admins,users" />
</authorizationEntries>
```

 同样，当您的代理与 LDAP 集成时，请确保将权限授予 `amazonmq-console-admins` 群组。有关 LDAP 集成的更多信息，请参阅 [LDAP 集成的工作方式](security-authentication-authorization.md#ldap-support-details)。