[모니터링] RabbitMQ 모니터링 지표 정리

목표

• RabbitMQ에서 모니터링 할 수 있는 메트릭과 스스로 우선 순위를 정해보기
• RabbitMQ는 퍼블리셔, [Node, Exchange, Queue], 컨슈머 객체로 이루어져 있음
• 각 구성 요소에 대해서 어떠한 것을 주요 메트릭 확인

내용

• Rabbit MQ 구성
  • Erlang Runtime 기반의 Node에서 Producer, [Exchange, queue], Consumer로 구성
  • Exchange, queue는 RabbitMQ 브로커 영역
• 주요 참고 메트릭
  • Node Metric (RabbitMQ를 운영하는 머신)
    • File descriptors used, File descriptors used as sockets
      • 고갈 되면, 새로운 Connection을 블락함, 사용가능한 갯수 파악 필요
    • Disk Space Used
      • 고갈 되면, 클러스터 유지를 위해 Connection을 블락함, 어디서 제일 많이 쓰는 지 파악 필요
    • Memory Used
      • 고갈 되면, 퍼블리싱을 위한 커넥션을 모두 블락함
  • Exchange Metric (일종의 분배기)
    • Mesage published in/out exchange
      • RabbitMQ의 일반적인 성능 지표 (Count/rate)
    • Messages unroutable
      • Binding 룰을 벗어난 메시지들, 유실된 메시지 → 이런 메시지를 담아놓는 exchange 생성
  • Queue Metric
    • Queue Depth (큐 내 모든 메시지 갯수)
      • 값이 0 이다 → 컨슈머가 잘 동작한다 or 프로듀서가 문제가 있다.
    • Message Unacknowledged (컨슈머 쪽에서 ack메시지가 넘어오지 않은 메시지)
      • 컨슈머 쪽에서 에러가 났다는 의미 → 장애 발생
    • Messages Ready (컨슈머에게 소비되어야 할 메시지 )
      • Unacknowledged 랑 같이 확인 해서 메시지 에러 정도를 확인할 수 있다.
    • Messages persistent (디스크에 쓰여진 메시지 갯수)
    • Message bytes RAM (메모리에 저장되어 있는 메시지 용량 합)
      • Rabbitmq는 설정에 따라 메세지 저장을 memory와 disk를 유동적으로 사용한다
      • disk와 메모리 증설 타임 파악 용도
    • Number of consumers (큐를 사용하는 컨슈머 갯수)
      • consumers 카운터가 변경이 없다면 동일하게 유지 → 컨슈머 서비스 상태 확인
  • 추가 지표들 (위와 중복되는 내용도 있음)
    • Connection opening rate
    • Channel opening rate
    • Connection failure (recovery) rate
    • Publishing rate
    • Delivery rate
    • Positive delivery acknowledgement rate
    • Negative delivery acknowledgement rate
    • Mean/95th percentile delivery processing latency

배울 점 & 개인 생각

• RabbitMQ는 메시지큐의 일종으로 느슨한 결합을 위해 중요한 요소로 사용되는 경우가 많다.
• 예상하기에는 장애가 발생할 수 있는 요소는 아래의 경우가 있다고 생각한다. (네트워크 문제 등은 배제)
  • Node의 FD의 개수가 고갈되거나, Memory, Disk의 가용량이 부족해서 블록킹이 발생한다.
  • Exchange에서 제대로 분배를 못해주거나, 유실되는 메시지가 증가한다.
  • Queue에서 소비되지 못한 메시지가 계속 남아있고, ack를 기다리고 queue에서 대기하고 있는 메시지가 증가한다.
  • Queue에 연결되어 있는 컨슈머들이 제대로 뜨지 못해 계속 숫자의 변동이 생긴다. (위의 ack를 기다리는 메시지를 발생하는 요인이 될 것임)
• 자체적으로 모니터링의 우선 순위를 나눠보자면 아래의 순서일 것 같다.
  • Node
  • Queue, Exchange
• 모니터링을 통해 확인해야 하는 정보의 우선순위는 첫 번째로 발생할 장애의 심각성으로 정렬한 후, 자주 반복될 빈도의 순으로 결정된다고 생각한다.
  • 이유는 RabbitMQ를 동작해주는 Node자원의 리소스가 부족하거나, FD가 부족해서 블락킹이 발생한다고 하면, 애초에 정보 인입이 막히기 때문에, 유실 등의 다른 경우와 다르게 서비스 전체의 문제가 발생한다.이후에는 Queue와 Exchange 내용은 RabbitMQ 서비스 자체는 유지 되지만 내부문제이기 때문에 자주 반복되는 문제들을 확인해서 먼저 보여주는 것이 좋다고 생각한다.

추후 해야할 것

• 세부 모니터링 정보 우선순위 정하기
• RabbitMQ 튜닝하는 법 알아보기
• 정말 가져올 수 있는 정보가 맞는 지 확인해보기 (제약 및 예외조건 확인)

참고 링크

Key metrics for RabbitMQ monitoring

Key metrics for RabbitMQ monitoring

RabbitMQ - Performance and File Descriptors - Code-and-Stuff

RabbitMQ - Performance and File Descriptors - Code-and-Stuff

Monitoring

Monitoring — RabbitMQ