모니터링 개요

Pub/Sub API는 Cloud Monitoring을 통해 측정 항목을 내보냅니다. Cloud Monitoring을 사용하면 모니터링 대시보드알림 정책을 만들거나 프로그래매틱 방식으로 측정 항목에 액세스할 수 있습니다.

측정항목 보기

Cloud Monitoring 대시보드를 보거나 알림 정책을 정의하려면 Google Cloud Console에서 모니터링으로 이동하세요.

모니터링으로 이동

Cloud Monitoring API를 사용하면 구독 및 주제의 측정 항목을 쿼리하고 볼 수도 있습니다.

측정항목 및 리소스 유형

주제 또는 구독 할당량 사용률 모니터링

API 및 서비스 할당량 대시보드를 사용하여 주어진 주제 또는 구독에 대한 현재 사용률을 모니터링할 수 있습니다.

이러한 측정 항목은 다음과 같습니다.

  • pubsub.googleapis.com/topic/byte_cost
  • pubsub.googleapis.com/subscription/byte_cost

이러한 측정항목은 바이트 단위인 반면 할당량은 KB 단위입니다.

구독자의 상태를 양호하게 유지

백로그 모니터링

구독자가 메시지 흐름을 따라 잡으려면 모든 구독에 대해 리소스별로 집계된 다음 측정항목이 표시되는 대시보드를 만듭니다.

  • subscription/num_undelivered_messages
  • subscription/oldest_unacked_message_age

시스템 컨텍스트에서 이러한 값이 비정상적으로 큰 경우 실행되는 알림 정책을 생성합니다. 예를 들어 전송되지 않은 메시지의 절대 개수가 반드시 의미 있는 것은 아닙니다. 100만 개 메시지의 백로그는 초당 100만 개의 메시지에 대해 허용되지만 초당 1개의 메시지에 대해서는 허용되지 않습니다.

증상 문제 솔루션
oldest_unacked_message_agenum_undelivered_messages 모두 동시에 증가하고 있습니다. 구독자가 메시지 볼륨을 유지하지 못함
  • 더 많은 구독자 스레드 또는 프로세스를 추가합니다.
  • 더 많은 구독자 머신 또는 컨테이너를 추가합니다.
  • 메시지를 성공적으로 인식하거나 적절한 시기에 처리하지 못하도록 하는 버그의 징후가 코드에 있는지 확인합니다(ACK 기한 만료 모니터링 참조).
안정적으로 증가하는 oldest_unacked_message_age와 결합된 안정적인 작은 백로그 크기가 있는 경우 처리할 수 없는 적은 수의 메시지가 있을 수 있습니다. 메시지가 막힘 애플리케이션 로그를 검토하여 일부 메시지가 코드 충돌을 일으키는지 확인합니다. 문제가 되는 메시지가 클라이언트가 아니라 Pub/Sub에서 막히는 경우는 거의 없습니다. 코드가 각 메시지에서 성공적으로 처리되었다고 생각되면 지원 기록을 제기합니다.
oldest_unacked_message_age에서 구독의 메시지 보관 기간을 초과했습니다. 영구적인 데이터 손실 구독의 메시지 보관 기간이 경과하기 전에 알림을 설정합니다.

ACK 기한 만료 모니터링

메시지 전송의 엔드 투 엔드 지연을 줄이기 위해 Pub/Sub는 메시지를 재전송하기 전에 구독자 클라이언트가 제공된 메시지('ACK 기한')를 확인하는 데 제한된 시간을 허용합니다. 구독자가 메시지를 너무 오래 확인하지 않으면 메시지가 다시 전송되어 구독자에게 중복 메시지가 표시됩니다. 표시되지 않는 원인으로는 여러 가지가 있습니다.

  • 구독자가 완전히 프로비저닝되지 않았습니다. 스레드나 머신이 더 필요합니다.

  • 각 메시지는 메시지 확인 기한보다 처리하는 데 시간이 오래 걸립니다. Google Cloud 클라이언트 라이브러리는 일반적으로 개별 메시지의 기한을 구성 가능한 최대 한도까지 연장합니다. 그러나 최대 연장 기한은 라이브러리에도 적용됩니다.

  • 일부 메시지가 지속적으로 클라이언트와 충돌합니다.

구독자가 ACK 기한을 놓치는 비율을 측정하는 것이 유용할 수 있습니다. 구체적인 측정항목은 구독 유형에 따라 다릅니다.

  • Pull 및 StreamingPull: subscription/pull_ack_message_operation_count, 필터링 기준: response_code != "success"

  • 내보내기: subscription/push_request_count, 필터링 기준: response_code != "success"

지나친 ACK 기한 만료 비율은 시스템 비효율적인 비용을 초래할 수 있습니다. 재전송하는 경우와 각 메시지를 반복적으로 처리하려는 경우에 요금을 지불합니다. 반대로 적은 만료 비율(예: 0.1~1%)이 양호할 수 있습니다.

내보내기 구독 모니터링

내보내기 구독의 경우 다음 측정항목도 모니터링해야 합니다.

  • subscription/push_request_count

    response_codesubcription_id로 측정항목을 그룹화합니다. Pub/Sub 내보내기 구독은 암시적 메시지 수신 확인으로 응답 코드를 사용하므로 내보내기 요청 응답 코드를 모니터링해야 합니다. 시간 초과 또는 오류가 발생하면 내보내기 구독이 기하급수적으로 백오프되므로 엔드포인트가 응답하는 방식에 따라 백로그가 빠르게 증가할 수 있습니다.

    높은 오류 비율로 인해 전달이 느려지고 백로그가 증가하므로 이에 대한 알림을 설정하는 것이 좋습니다(응답 클래스에 의해 필터링된 측정항목 생성). 하지만 푸시 요청 수는 증가하는 백로그 크기 및 기간을 조사하는 도구로 더 유용할 수 있습니다.

  • subscription/num_outstanding_messages

    Pub/Sub는 일반적으로 미해결 메시지 수를 제한합니다. 대부분의 경우 1,000개 미만의 미해결 메시지를 목표로 해야 합니다. 일반적으로 처리량이 초당 1만 개의 메시지를 처리하면 서비스가 구독의 전체 처리량을 기준으로 한도를 1,000 단위로 조정합니다. 최댓값을 넘는 특별한 보장은 없으므로 1,000이 좋은 가이드입니다.

  • subscription/push_request_latencies

    이 측정항목을 사용하면 푸시 엔드포인트의 응답 지연 시간 분포를 이해할 수 있습니다. 미해결 메시지 수에 제한이 있으므로 엔드포인트 지연 시간은 구독 처리량에 영향을 미칩니다. 각 메시지를 처리하는 데 100밀리초가 걸리면 처리량 한도는 초당 10개의 메시지입니다.

데드 레터 주제 모니터링

데드 레터 주제로 전달된 메시지를 모니터링하려면 데드 레터 주제가 있는 구독에서 subscription/dead_letter_message_count 측정항목을 사용합니다.

전달된 메시지가 성공적으로 수신되었는지 확인하려면 subscription/dead_letter_message_count를 데드 레터 주제의 topic/send_message_operation_count 측정항목과 비교합니다.

또는, 데드 레터 주제에 대한 구독에서 측정항목을 사용하여 데드 레터 주제가 전달된 메시지를 수신하였는지 모니터링할 수 있습니다.

  • subscription/num_undelivered_messages

    구독이 데드 레터 주제로 전달된 메시지만 수신하는 경우 이 측정항목에서 구독자 애플리케이션이 처리하지 않는 전달된 메시지 수를 계산합니다.

  • subscription/oldest_unacked_message_age

    구독이 데드 레터 주제로 전달된 메시지만 수신하는 경우 이 측정 항목에서 데드 레터 주제로 전달된 메시지의 만료 여부를 표시합니다.

게시자의 상태를 양호하게 유지

게시자의 기본 목표는 메시지 데이터를 빠르게 유지하는 것입니다. response_code별로 그룹화된 topic/send_request_count을 사용하여 이 성능을 모니터링합니다. 이 측정항목은 Pub/Sub가 정상이며 요청을 수락하는지에 대한 지표를 제공합니다.

대부분의 Google Cloud 클라이언트 라이브러리는 메시지 오류를 다시 시도하므로 재시도 가능한 오류의 백그라운드 비율(1%보다 크게 낮음)이 문제가 되지 않습니다. 1%를 초과하는 오류율을 조사해야 합니다. 재시도 불가 코드는 클라이언트 라이브러리가 아닌 애플리케이션에서 처리하므로 응답 코드를 검사해야 합니다. 게시자 애플리케이션이 비정상 상태를 알릴 수 없는 경우에는 send_request_count 측정항목에서 알림 설정을 고려하세요.

게시 클라이언트에서 실패한 게시 요청을 추적하는 것도 똑같이 중요합니다. 일반적으로 클라이언트 라이브러리는 실패한 요청을 다시 시도하지만 게시를 보장하지는 않습니다. Google Cloud 클라이언트 라이브러리를 사용할 때 영구 게시 오류를 감지하는 방법은 게시 메시지를 참조하세요. 최소한 게시자 애플리케이션은 영구적인 게시 오류를 로깅해야 합니다. 이러한 오류를 Cloud Logging에 로깅하는 경우 알림 정책으로 로그 기반 측정항목을 설정할 수 있습니다.