rabbitmqctl을 사용한 RabbitMQ 노드 상태 및 연결 모니터링 방법

RabbitMQ는 일반적으로 큐가 백업되거나, 컨슈머가 메시지 확인을 중단하거나, 배포로 인해 수백 개의 추가 연결이 생성된 후에야 주목을 받습니다. rabbitmqctl은 여전히 브로커가 노드 내부에서 보는 내용을 확인하는 가장 빠른 방법 중 하나입니다. Prometheus, 관리 UI 또는 로그 검토를 대체하지는 않지만, 서버에 있을 때 빠르게 답을 얻을 수 있는 안정적인 명령줄 보기를 제공합니다.

rabbitmqctl 이해하기

rabbitmqctl 스크립트는 RabbitMQ 노드와 상호 작용하기 위한 기본 명령줄 인터페이스입니다. 관리자는 브로커 시작 및 중지부터 사용자, 권한, 익스체인지, 큐 관리, 그리고 이 글의 핵심인 노드의 운영 상태 및 네트워크 활동 모니터링에 이르기까지 광범위한 작업을 수행할 수 있습니다.

RabbitMQ 노드 상태 확인

연결을 살펴보기 전에 RabbitMQ 노드가 실행 중인지 확인하는 것이 중요합니다. status 명령은 노드의 현재 상태에 대한 포괄적인 개요를 제공합니다.

rabbitmqctl status 명령

이 명령은 다음과 같은 다양한 정보를 출력합니다.

• 노드 이름: RabbitMQ 노드의 이름입니다.
• 실행 중인 애플리케이션: 실행 중인 Erlang 애플리케이션을 나열하며, RabbitMQ 자체가 핵심 지표입니다.
• 메모리 사용량: 성능 튜닝에 중요한 메모리 할당 및 사용량에 대한 세부 정보입니다.
• 디스크 공간: 메시지 지속성에 영향을 줄 수 있는 사용 가능한 디스크 공간에 대한 정보입니다.
• 파일 디스크립터: 중요한 시스템 리소스인 열린 파일 디스크립터의 수입니다.
• 네트워크 정보: 네트워크 인터페이스 및 포트에 대한 세부 정보입니다.
• 클러스터 상태: 노드가 클러스터의 일부인지 여부와 연결 상태에 대한 정보입니다.
• 리스너: RabbitMQ가 다양한 프로토콜(AMQP, 관리 UI 등)에 대해 수신 대기 중인 포트입니다.

사용 예:

rabbitmqctl status

출력 해석: 리소스 고갈 징후(높은 메모리, 낮은 디스크 공간, 높은 파일 디스크립터 사용량)를 찾고 rabbit과 같은 필수 애플리케이션이 실행 중인지 확인합니다. listeners 섹션은 RabbitMQ가 예상 포트에서 액세스 가능한지 확인하는 데 중요합니다.

연결, 채널 및 컨슈머 모니터링

클라이언트가 RabbitMQ 노드와 상호 작용하는 방식을 이해하는 것은 문제 해결 및 성능 분석에 핵심입니다. rabbitmqctl은 이러한 엔터티를 나열하고 검사하는 명령을 제공합니다.

연결 나열 (rabbitmqctl list_connections)

이 명령은 RabbitMQ 노드에 대한 모든 활성 클라이언트 연결을 표시합니다. 각 연결은 성공적으로 연결된 클라이언트 애플리케이션(프로듀서 또는 컨슈머)을 나타냅니다.

명령:

rabbitmqctl list_connections

출력 열 (일반):

• pid: 연결에 대한 Erlang 프로세스 식별자입니다.
• node: 연결이 설정된 노드입니다.
• name: 연결 이름(종종 클라이언트 속성을 반영).
• port: 클라이언트가 연결한 포트입니다.
• host: 클라이언트가 연결한 호스트입니다.
• user: 인증에 사용된 사용자 이름입니다.
• vhost: 연결과 연결된 가상 호스트입니다.
• ssl: 연결이 SSL/TLS를 사용하는지 여부를 나타냅니다.
• protocol: 사용된 프로토콜(예: amqp0-9-1).

예:

rabbitmqctl list_connections name host port user vhost protocol

이를 통해 어떤 사용자가 어디서 연결했는지, 어떤 가상 호스트를 사용하고 있는지 확인할 수 있습니다.

채널 나열 (rabbitmqctl list_channels)

각 연결에는 여러 채널이 있을 수 있습니다. 채널은 단일 TCP 연결을 통한 경량 다중화 연결로, AMQP 작업에 사용됩니다.

명령:

rabbitmqctl list_channels

출력 열 (일반):

• connection: 상위 연결의 pid입니다.
• node: 채널이 있는 노드입니다.
• channel_pid: 채널에 대한 Erlang 프로세스 식별자입니다.
• vhost: 채널과 연결된 가상 호스트입니다.
• name: 채널 이름(클라이언트가 설정한 경우).
• consumer_count: 이 채널에서 활성 상태인 컨슈머 수입니다.
• messages_unacknowledged: 이 채널에서 확인되지 않은 메시지 수입니다.
• messages_ready: 이 채널에서 전달 준비가 된 메시지 수입니다.

예:

rabbitmqctl list_channels connection vhost consumer_count messages_ready messages_unacknowledged

messages_unacknowledged 및 messages_ready를 모니터링하는 것은 컨슈머가 따라잡지 못하는 잠재적인 병목 현상을 식별하는 데 중요합니다.

컨슈머 나열 (rabbitmqctl list_consumers)

컨슈머는 메시지를 수신하고 처리하기 위해 큐를 구독하는 프로세스입니다.

명령:

rabbitmqctl list_consumers

출력 열 (일반):

• vhost: 컨슈머가 있는 가상 호스트입니다.
• queue: 컨슈머가 연결된 큐의 이름입니다.
• consumer_tag: 컨슈머의 고유 식별자(클라이언트가 설정).
• delivery_tag: 현재 처리 중인 메시지의 전달 태그입니다.
• redelivered: 메시지가 재전송되었는지 여부입니다.
• message_count: 이 컨슈머에게 전달되기를 기다리는 메시지 수입니다.
• ack_required: 이 컨슈머에게 전달된 메시지에 대해 확인이 필요한지 여부를 나타냅니다.

예:

rabbitmqctl list_consumers vhost queue consumer_tag message_count ack_required

이 명령은 어떤 큐에 활성 컨슈머가 있는지, 그들에게 전달 보류 중인 메시지 수, 확인이 올바르게 구성되었는지 이해하는 데 도움이 됩니다.

특정 구성 요소 검사 (선택적 인수)

대부분의 list_* 명령은 표시할 필드를 지정하는 인수를 허용하여 출력을 더 관리하기 쉽게 만듭니다. grep 및 sort와 같은 표준 셸 유틸리티를 사용하여 출력을 필터링하고 정렬할 수도 있습니다.

예: 특정 사용자의 연결 찾기:

rabbitmqctl list_connections | grep 'my_user'

예: 확인되지 않은 메시지가 있는 큐만 표시:

rabbitmqctl list_channels | awk '$4 > 0 { print }'

모니터링 모범 사례

• 정기적 확인: 프로덕션에 영향을 미치기 전에 잠재적인 문제를 식별하기 위해 rabbitmqctl status를 정기적으로 확인합니다.
• 자동화: 스크립트를 사용하여 이러한 검사를 자동화하고 사전 경고를 위해 모니터링 시스템(예: Prometheus, Nagios)과 통합하는 것을 고려하십시오.
• 맥락이 중요: 환경의 일반적인 값을 이해하십시오. 확인되지 않은 메시지의 갑작스러운 급증이나 예상치 못한 새 연결은 조사가 필요합니다.
• 관리 UI와 결합: rabbitmqctl은 스크립팅 및 직접 액세스에 강력하지만, RabbitMQ 관리 UI는 동일한 정보를 모니터링하는 시각적이고 대화식 방법을 제공합니다.
• 리소스 모니터링: 전체적인 그림을 위해 rabbitmqctl 출력을 시스템 수준 리소스 모니터링(CPU, RAM, 디스크 I/O)과 항상 연관시키십시오.

큐가 백업될 때 유용한 분류 흐름

큐가 증가하기 시작하면 RabbitMQ를 다시 시작하는 것부터 시작하지 마십시오. 다시 시작하면 복구 속도가 느려지고 필요한 증거가 숨겨질 수 있습니다. 네 가지 질문에 답하는 것부터 시작하십시오.

첫째, 노드가 클라이언트에 서비스를 제공할 수 있을 정도로 정상입니까?

rabbitmqctl status

메모리 알람, 디스크 알람, 파일 디스크립터 사용량 및 리스너를 확인하십시오. RabbitMQ에는 메모리 및 디스크 여유 공간 안전 메커니즘이 있습니다. 노드가 알람 상태에 들어가면 게시자가 차단될 수 있습니다. 외부에서는 브로커가 스스로를 보호하고 있음에도 불구하고 애플리케이션 문제처럼 보일 수 있습니다.

둘째, 컨슈머가 연결되어 있습니까?

rabbitmqctl list_consumers vhost queue consumer_tag ack_required active

큐에 컨슈머가 없으면 큐 깊이는 RabbitMQ 성능 문제가 아닙니다. 큐에서 소비해야 하는 애플리케이션이 다운되었거나, 잘못 구성되었거나, 잘못된 가상 호스트에 연결되었거나, 게시자가 사용하는 것과 다른 큐 이름을 사용하고 있는 것입니다.

셋째, 컨슈머가 메시지를 수신하고 있지만 확인하지 않고 있습니까?

rabbitmqctl list_queues name messages_ready messages_unacknowledged consumers

messages_ready는 메시지가 큐에서 대기 중임을 의미합니다. messages_unacknowledged는 메시지가 컨슈머에게 전달되었지만 아직 확인되지 않았음을 의미합니다. 확인되지 않은 수가 많으면 느린 핸들러, 컨슈머 내부의 긴 데이터베이스 호출, 너무 높은 프리페치 값 또는 메시지를 수신한 후 충돌한 컨슈머를 가리키는 경우가 많습니다.

넷째, 연결 또는 채널이 너무 많습니까?

rabbitmqctl list_connections name user host state channels send_pend recv_cnt send_cnt
rabbitmqctl list_channels connection number consumer_count messages_unacknowledged prefetch_count

정상적인 클라이언트는 일반적으로 연결을 재사용하고 제어된 수의 채널을 엽니다. 모든 요청이 새 연결을 열면 브로커가 연결 변동에 많은 시간을 소비할 수 있습니다. 단일 연결에 매우 많은 수의 채널이 있는 경우 클라이언트 라이브러리 동작과 배포 크기를 검사하십시오.

연결 상태 해석

list_connections는 특정 열을 요청할 때 더 유용합니다. 간결한 명령은 인시던트 중에 스캔하기 더 쉽습니다:

rabbitmqctl list_connections name user host state channels protocol ssl

state 열은 정상 트래픽과 의심스러운 동작을 구분하는 데 도움이 됩니다. running 상태의 연결은 활성 상태입니다. 흐름 제어 또는 차단 상태에 갇힌 많은 수의 연결은 주의가 필요합니다. TLS가 예상되는 곳에서 ssl이 false이면 클라이언트가 잘못된 리스너 또는 이전 구성을 사용하고 있을 수 있습니다.

클라이언트 이름은 애플리케이션 코드에서 설정할 가치도 있습니다. 많은 RabbitMQ 클라이언트 라이브러리를 사용하면 연결 이름을 설정할 수 있습니다. 그렇지 않으면 호스트 및 포트 세부 정보만 볼 수 있어 부하를 유발하는 서비스를 식별하기가 더 어려워집니다. billing-worker-prod-3과 같은 이름은 익명의 TCP 연결보다 훨씬 유용합니다.

채널 및 프리페치 문제

채널은 TCP 연결에 비해 저렴하지만 무료는 아닙니다. 일반적인 프로덕션 문제는 채널을 만들고 닫지 않는 작업자 프로세스입니다. 또 다른 문제는 높은 프리페치 값을 가진 컨슈머가 많은 메시지를 수신하고, 느리게 처리하며, 다른 컨슈머를 유휴 상태로 만드는 것입니다.

사용:

rabbitmqctl list_channels connection number consumer_count messages_unacknowledged prefetch_count

한 채널에 messages_unacknowledged 수가 많으면 해당 컨슈머를 검사하십시오. 느린 HTTP 호출을 수행하거나, 데이터베이스 잠금을 기다리거나, 프리페치가 훨씬 더 많이 예약하도록 허용하는 동안 한 번에 하나의 메시지를 처리하고 있을 수 있습니다. 프리페치를 낮추면 공정성이 향상될 수 있지만 마법 같은 성능 수정은 아닙니다. 핸들러가 느리면 여전히 핸들러를 수정해야 합니다.

연결 검사 옆에 있어야 할 큐 검사

이 글은 노드 상태 및 연결에 중점을 두지만, 큐 상태가 전체 그림을 완성합니다:

rabbitmqctl list_queues name durable auto_delete messages messages_ready messages_unacknowledged consumers memory state

지속적인 메시지가 있는 내구성 있는 큐는 디스크에 부담을 줄 수 있습니다. consumers가 0으로 설정된 큐는 애플리케이션 검사가 필요합니다. 준비된 메시지가 많고 활성 컨슈머가 있는 큐는 처리량 불일치를 나타냅니다. 확인되지 않은 메시지가 많은 큐는 컨슈머 측 처리 또는 확인 동작을 나타냅니다.

셸 필터를 사용할 때는 열 위치에 주의하십시오. 요청된 필드를 변경하면 이전 awk 스니펫이 잘못된 열을 자동으로 필터링할 수 있습니다. 반복 가능한 검사의 경우 고정 필드를 요청하고 출력에 레이블을 지정하는 스크립트를 선호하십시오.

클러스터 참고 사항

클러스터에서는 관심 있는 노드에 대해 명령을 실행하거나 지원되는 경우 노드를 지정하십시오:

rabbitmqctl -n rabbit@node1 status

클러스터 구성원 및 파티션 확인:

rabbitmqctl cluster_status

네트워크 파티션 및 노드 불일치는 혼란스러운 증상을 만들 수 있습니다. 클라이언트는 한 노드에 성공적으로 연결하지만 큐나 메타데이터는 다른 곳에서 비정상입니다. 문제가 하나의 가용성 영역 또는 하나의 브로커 호스트에만 영향을 미치는 경우 클러스터 전체 설정을 변경하기 전에 노드 간에 status, list_connections 및 list_queues를 비교하십시오.

자동화할 내용

소규모 환경의 경우 몇 가지 스크립트된 검사로 명백한 문제를 포착할 수 있습니다: 노드 다운, 디스크 알람, 메모리 알람, 중요한 큐에 컨슈머 없음, 정상 임계값 이상의 준비된 메시지, 계속 증가하는 확인되지 않은 메시지, 기준선을 훨씬 초과하는 연결 수.

대규모 시스템의 경우 RabbitMQ Prometheus 플러그인 또는 다른 메트릭 파이프라인을 사용하고 직접 조사에는 rabbitmqctl을 사용하십시오. 알림은 사용자가 관심을 갖는 동작과 연결되어야 합니다. 배치 작업 중에 큐가 일시적으로 증가하는 것은 정상일 수 있습니다. 컨슈머가 연결되어 있고 확인되지 않은 메시지도 증가하는 동안 큐가 15분 동안 증가하는 것은 더 나은 페이지입니다.

시간을 절약하는 운영 습관

올바른 OS 사용자 또는 설치에서 예상하는 서비스 계정을 통해 rabbitmqctl을 실행하십시오. 권한 문제는 서두를 때 브로커 문제처럼 보일 수 있습니다. 명령이 노드에 연결할 수 없으면 노드 이름, Erlang 쿠키 및 RabbitMQ 서비스가 실제로 해당 호스트에서 실행 중인지 확인하십시오.

중요한 큐와 예상 컨슈머의 작은 목록을 유지하십시오. 인시던트 중에 "큐에 컨슈머가 0명입니다"는 해당 큐에 항상 컨슈머가 있어야 하는지 아는 경우에만 유용합니다. 일부 지연, 데드 레터 또는 배치 큐는 오랜 기간 동안 유휴 상태로 있을 것으로 예상됩니다.

마지막으로, 대시보드를 녹색으로 만들기 위해 큐를 지우지 마십시오. 메시지를 삭제할 수 있도록 설계되지 않은 경우 큐를 비우는 것은 데이터 손실입니다. 메시지가 멈춘 경우 먼저 메시지가 대기 중인지, 확인되지 않았는지, 거부되었는지, 데드 레터링되었는지, 아니면 누락된 컨슈머에 의해 차단되었는지 확인하십시오.

rabbitmqctl status, list_connections, list_channels, list_consumers 및 list_queues는 "메시지가 지연되었습니다"에서 가능한 원인까지 실용적인 명령줄 경로를 제공합니다. 요령은 함께 읽는 것입니다: 노드 리소스, 클라이언트 연결, 채널 동작, 컨슈머 존재 및 큐 깊이는 모두 동일한 이야기의 다른 부분을 알려줍니다.