문제 해결: ActiveMQ용 Amazon MQ - Amazon MQ
로그 검색 CloudWatch 재시작 후 브로커에 연결일부 클라이언트는 연결할 수 없음웹 콘솔의 JSP 예외

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

문제 해결: ActiveMQ용 Amazon MQ

이 단원의 정보를 사용하여 ActiveMQ용 Amazon MQ 브로커를 사용할 때 발생할 수 있는 일반적인 문제를 진단하고 해결할 수 있습니다.

로깅을 활성화했는데도 로그에서 브로커의 일반 로그나 감사 CloudWatch 로그를 볼 수 없습니다.

로그에서 CloudWatch 브로커에 대한 로그를 볼 수 없는 경우 다음을 수행하십시오.

  1. 브로커를 생성하거나 재부팅하는 사용자에게 logs:CreateLogGroup 권한이 있는지 확인합니다. 사용자가 브로커를 생성하거나 재부팅하기 전에 CreateLogGroup 권한을 사용자에게 추가하지 않으면 Amazon MQ가 로그 그룹을 생성하지 않습니다.

  2. Amazon MQ가 로그를 Logs에 게시할 수 있도록 리소스 기반 정책을 구성했는지 확인하십시오. CloudWatch Amazon MQ가 로그 로그 그룹에 로그를 게시하도록 허용하려면 Amazon MQ가 다음 CloudWatch Logs API 작업에 액세스할 수 있도록 리소스 기반 정책을 구성하십시오. CloudWatch

    • CreateLogStream— 지정된 로그 그룹에 대한 CloudWatch 로그 로그 스트림을 생성합니다.

    • PutLogEvents— 지정된 로그 CloudWatch 로그 스트림에 이벤트를 전달합니다.

로그를 로그에 게시하도록 ActiveMQ용 Amazon MQ를 구성하는 방법에 대한 자세한 내용은 로깅 구성을 참조하십시오. CloudWatch

브로커 재시작 또는 유지 관리 기간이 지나면 상태가 RUNNING과 같더라도 브로커에 연결할 수 없습니다. 이유?

브로커를 다시 시작했거나, 예약된 유지 관리 기간이 완료된 후 또는 대기 인스턴스가 활성화되는 장애 이벤트로 인해 연결 문제가 발생할 수 있습니다. 두 경우 모두 브로커 재시작 후 연결 문제는 브로커의 Amazon EFS 또는 Amazon EBS 스토리지 볼륨에 비정상적으로 많은 수의 메시지가 존재하여 발생할 수 있습니다. 다시 시작하는 동안 Amazon MQ는 지속적 메시지를 스토리지에서 브로커 메모리로 이동합니다. 이 진단을 확인하기 위해 CloudWatch ActiveMQ용 Amazon MQ 브로커에 대한 다음 지표를 모니터링할 수 있습니다.

  • StoragePercentUsage — 100%이거나 100%에 근접한 높은 비율로 인해 브로커가 연결을 거부할 수 있습니다.

  • JournalFilesForFullRecovery — 불완전하게 종료하고 다시 시작한 후 재생될 저널 파일 수를 나타냅니다. 값이 증가하거나 지속적으로 1보다 높으면 다시 시작한 후 연결 문제가 발생할 수 있는 해결되지 않은 트랜잭션이 표시됩니다.

  • OpenTransactionCount — 재시작 후 0보다 큰 숫자는 브로커가 이전에 사용한 메시지를 저장하려고 시도하므로 연결 문제가 발생합니다.

이 문제를 해결하려면 rollback() 또는 commit() 중 하나를 사용하여 XA 트랜잭션을 해결하는 것이 좋습니다. 자세한 내용을 알려보고, rollback()을(를) 사용하여 XA 트랜잭션을 해결하는 코드 예제를 보려면 XA 트랜잭션 복구 단원을 참조하십시오.

일부 클라이언트는 브로커에 연결되는 반면 다른 클라이언트는 연결할 수 없습니다.

브로커가 RUNNING 상태이며 일부 클라이언트는 브로커에 성공적으로 연결할 수 있지만 다른 클라이언트는 그렇게 할 수 없는 경우, 브로커에 대한 와이어 레벨 연결 한도에 도달했을 수 있습니다. 와이어 레벨 연결 한도에 도달했는지 확인하려면 다음을 수행합니다.

  • 로그에서 ActiveMQ용 Amazon MQ 브로커의 일반 브로커 로그를 확인하십시오. CloudWatch 한도에 도달한 경우, 브로커 로그의 Reached Maximum Connections을 참조하십시오. ActiveMQ CloudWatch 브로커용 Amazon MQ 로그에 대한 자세한 내용은 을 참조하십시오. 로그 로그인 구조 이해 CloudWatch

와이어 레벨 연결 제한에 도달하면 브로커는 추가 수신 연결을 적극적으로 거부합니다. 이 문제를 해결하려면 브로커 인스턴스 유형을 업그레이드하는 것이 좋습니다. 워크로드에 가장 적합한 인스턴스 유형을 선택하는 방법에 대한 자세한 내용은 Broker instance types 단원을 참조하십시오.

와이어 레벨 연결 수가 브로커 연결 한도보다 작다는 것을 확인한 경우 클라이언트 재부팅과 관련된 문제가 발생할 수 있습니다. 브로커 로그에서 다수의 자주 발생하는 ... Inactive for longer than 600000 ms - removing ... 항목이 있는지 확인하십시오. 로그 항목은 클라이언트 재부팅 또는 연결 문제를 나타냅니다. 이 효과는 브로커와 자주 연결을 끊고 다시 연결하는 클라이언트를 포함하는 Network Load Balancer(NLB)를 통해 클라이언트가 브로커에 연결할 때 더 분명합니다. 이는 컨테이너 기반 클라이언트에서 더 일반적으로 관찰됩니다.

자세한 내용은 클라이언트 측 로그를 확인하십시오. 브로커는 600000ms 후에 비활성 TCP 연결을 정리하고 연결 소켓을 비웁니다.

작업을 수행할 때 ActiveMQ 콘솔에서 예외 org.apache.jasper.JasperException: An exception occurred processing JSP page을(를) 볼 수 있습니다.

간단한 인증을 사용하고 대기열 및 주제 승인에 대한 AuthorizationPlugin을 구성하는 경우, XML 구성 파일에 있는 AuthorizationEntries 요소를 사용하고 모든 대기열 및 주제에 대한 activemq-webconsole 그룹 사용 권한을 허용하십시오. 이렇게 하면 ActiveMQ 웹 콘솔이 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 통합의 작동 방식 단원을 참조하십시오.