Cloud Monitoring에서 Pub/Sub 모니터링

Google Cloud 콘솔 또는 Cloud Monitoring API를 사용하여 Pub/Sub를 모니터링할 수 있습니다.

이 문서에서는 Monitoring을 사용하여 Google Cloud 콘솔에서 Pub/Sub 사용량을 모니터링하는 방법을 보여줍니다.

Pub/Sub 측정항목 외에 다른 Google Cloud 리소스의 측정항목을 보려면 Monitoring을 사용하세요.
또는 Pub/Sub에서 제공하는 모니터링 대시보드를 사용할 수 있습니다. 주제 모니터링 및 구독 모니터링을 참조하세요.

자동 확장에서 측정항목을 사용하는 방법은 Pub/Sub 측정항목을 확장 신호로 사용하기 위한 권장사항을 참조하세요.

시작하기 전에

Monitoring을 사용하기 전에 다음 항목이 준비되었는지 확인합니다.

Cloud Billing 계정
결제가 사용 설정된 Pub/Sub 프로젝트

이 두 가지 조건을 모두 확인하기 위한 한 가지 방법은 Cloud 콘솔을 사용한 빠른 시작을 완료하는 것입니다.

기존 대시보드 보기

대시보드를 사용하면 동일한 컨텍스트에서 여러 소스의 데이터를 보고 분석할 수 있습니다. Google Cloud는 사전 정의된 대시보드와 커스텀 대시보드를 모두 제공합니다. 예를 들어 사전 정의된 Pub/Sub 대시보드를 보거나 측정항목 데이터, 경고 정책, Pub/Sub 관련 로그 항목을 보여주는 커스텀 대시보드를 만들 수 있습니다.

Cloud Monitoring을 사용하여 Pub/Sub 프로젝트를 모니터링하려면 다음 단계를 수행합니다.

Google Cloud 콘솔에서 Monitoring 페이지로 이동합니다.

Monitoring으로 이동
페이지 상단에서 프로젝트 이름을 선택합니다(아직 선택하지 않은 경우).
탐색 메뉴에서 대시보드를 클릭합니다.
대시보드 개요 페이지에서 새 대시보드를 만들거나 기존 Pub/Sub 대시보드를 선택합니다.

기존 Pub/Sub 대시보드를 검색하려면 모든 대시보드 필터에서 이름 속성을 선택하고 Pub/Sub를 입력합니다.

커스텀 대시보드를 생성, 수정, 관리하는 방법은 커스텀 대시보드 관리를 참조하세요.

단일 Pub/Sub 측정항목 보기

Google Cloud 콘솔을 사용하여 단일 Pub/Sub 측정항목을 보려면 다음 단계를 수행합니다.

Google Cloud 콘솔에서 Monitoring 페이지로 이동합니다.

Monitoring으로 이동
탐색 창에서 측정항목 탐색기를 선택합니다.
구성 섹션에서 측정항목 선택을 클릭합니다.
필터에 Pub/Sub를 입력합니다.
활성 리소스에서 Pub/Sub 구독 또는 Pub/Sub 주제를 선택합니다.
특정 측정항목으로 드릴다운하고 적용을 클릭합니다.

특정 측정항목의 페이지가 열립니다.

Cloud Monitoring 문서를 읽고 모니터링 대시보드에 대해 자세히 알아볼 수 있습니다.

Pub/Sub 측정항목 및 리소스 유형 보기

Pub/Sub가 Cloud Monitoring에 보고하는 측정항목을 알아보려면 Cloud Monitoring 문서에서 Pub/Sub 측정항목 목록을 참조하세요.
pubsub_topic, pubsub_subscription 또는 pubsub_snapshot 모니터링 리소스 유형에 대한 자세한 내용은 Cloud Monitoring 문서의 모니터링 리소스 유형을 참조하세요.

MQL 편집기에 액세스

측정항목 탐색기는 측정항목 데이터를 탐색하고 시각화하도록 설계된 Cloud Monitoring 내의 인터페이스입니다. 측정항목 탐색기에서 모니터링 쿼리 언어(MQL)를 사용하여 Pub/Sub 측정항목을 쿼리하고 분석할 수 있습니다.

측정항목 탐색기를 사용할 때 MQL 편집기에 액세스하려면 코드 편집기에 액세스를 참고하세요.

MQL 쿼리 빌드

다음은 Pub/Sub 측정항목의 MQL 쿼리를 빌드하기 위한 몇 가지 기본 규칙입니다.

fetch pubsub_topic 또는 fetch pubsub_subscription으로 시작합니다. 이 코드 줄은 주제 또는 구독과 같이 쿼리할 Pub/Sub 리소스의 유형을 편집기에 알려줍니다.
측정항목을 선택합니다. | metric 'metric_name'을 사용하여 분석할 측정항목을 지정합니다. Pub/Sub 측정항목의 예는 확인된 메시지의 경우 pubsub.googleapis.com/subscription/ack_message_count입니다.
| filter를 사용하여 데이터 범위를 좁힙니다. 일반적인 필터는 다음과 같습니다.
- resource.project_id == 'your-project-id'
- resource.topic_id == 'your-topic-id'
- resource.subscription_id == 'your-subscription-id'
| align 및 | group_by를 사용하여 데이터를 의미 있는 간격과 그룹으로 집계합니다.
다른 절로 데이터를 세분화합니다. MQL은 | every(쿼리 실행 빈도 설정), | within(기간 지정) 등 다양한 다른 절을 제공합니다.

다음은 특정 구독으로 전송된 메시지의 시간당 수를 모니터링하는 쿼리의 예입니다.

fetch pubsub_subscription
| metric 'pubsub.googleapis.com/subscription/sent_message_count'
| filter resource.project_id == 'your-project-id'
&& resource.subscription_id == 'your-subscription-id'
| align delta(1h)
| every 1h
| group_by [], [value_sent_message_count_aggregate: aggregate(value.sent_message_count)]

할당량 사용량 모니터링

특정 프로젝트의 경우 IAM 및 관리자 할당량 대시보드를 사용하여 현재 할당량 및 사용량을 볼 수 있습니다.

다음 측정항목을 사용하여 이전 할당량 사용량을 볼 수 있습니다.

이러한 측정항목은 consumer_quota 모니터링 리소스 유형을 사용합니다. 할당량 관련 측정항목은 측정항목 목록을 참조하세요.

예를 들어 다음 MQL 쿼리는 각 리전에서 사용 중인 게시자 할당량의 비율이 포함된 차트를 만듭니다.

fetch consumer_quota
| filter resource.service == 'pubsub.googleapis.com'
| { metric serviceruntime.googleapis.com/quota/rate/net_usage
    | filter metric.quota_metric == 'pubsub.googleapis.com/regionalpublisher'
    | align delta_gauge(1m)
    | group_by [metric.quota_metric, resource.location],
        sum(value.net_usage)
  ; metric serviceruntime.googleapis.com/quota/limit
    | filter metric.quota_metric == 'pubsub.googleapis.com/regionalpublisher'
    | group_by [metric.quota_metric, resource.location],
        sliding(1m), max(val()) }
| ratio

사용량이 기본 할당량 한도를 초과할 것으로 예상되면 모든 관련 할당량에 대한 알림 정책을 만듭니다. 이러한 알림은 사용량이 한도에 도달하면 실행됩니다. 예를 들어 다음 모니터링 쿼리 언어 쿼리는 Pub/Sub 할당량이 80% 사용량을 초과하면 알림 정책을 트리거합니다.

fetch consumer_quota
| filter resource.service == 'pubsub.googleapis.com'
| { metric serviceruntime.googleapis.com/quota/rate/net_usage
    | align delta_gauge(1m)
    | group_by [metric.quota_metric, resource.location],
        sum(value.net_usage)
  ; metric serviceruntime.googleapis.com/quota/limit
    | group_by [metric.quota_metric, resource.location],
        sliding(1m), max(val()) }
| ratio
| every 1m
| condition gt(val(), 0.8 '1')

할당량 측정항목에 대한 맞춤설정된 모니터링 및 알림은 할당량 측정항목 사용을 참조하세요.

할당량에 대한 자세한 내용은 할당량 및 한도를 참조하세요.

정상 구독 유지

정상 구독을 유지하려면 Pub/Sub 제공 측정항목을 사용하여 여러 구독 속성을 모니터링할 수 있습니다. 예를 들어 미확인 메시지 볼륨, 메시지 확인 마감 시한 종료 등을 모니터링할 수 있습니다. 또한 낮은 메시지 전송 지연 시간을 달성하기에 충분하도록 구독이 정상 상태인지 확인할 수 있습니다.

특정 측정항목에 대해 자세히 알아보려면 다음 섹션을 참조하세요.

메시지 백로그 모니터링

구독자가 메시지 흐름을 따라갈 수 있도록 대시보드를 만듭니다. 대시보드는 모든 구독에 대해 리소스별로 집계된 다음과 같은 백로그 측정항목을 표시할 수 있습니다.

미확인 메시지(subscription/num_undelivered_messages) - 미확인 메시지 수를 표시합니다.
가장 오래된 미확인 메시지 기간(subscription/oldest_unacked_message_age) - 설명 백로그에서 가장 오래된 미확인 메시지 기간을 표시합니다.
전송 지연 시간 상태 점수(subscription/delivery_latency_health_score) - 전송 지연 시간과 관련하여 전반적인 구독 상태를 확인합니다. 이 측정항목에 대한 자세한 내용은 이 문서의 관련 섹션을 참조하세요.

이러한 값이 시스템 컨텍스트에서 허용되는 범위를 벗어날 때 트리거되는 알림 정책을 만듭니다. 예를 들어 미확인 메시지의 절대 개수가 반드시 의미 있는 것은 아닙니다. 100만 개 메시지의 백로그는 초당 100만 개의 메시지에 대해 허용되지만 초당 1개의 메시지에 대해서는 허용되지 않습니다.

일반적인 백로그 문제

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

전송 지연 시간 상태 모니터링

Pub/Sub에서 전송 지연 시간은 게시된 메시지가 구독자에게 전송되는 데 걸리는 시간입니다. 메시지 백로그가 증가하면 전송 지연 시간 상태 점수(subscription/delivery_latency_health_score)를 사용하여 지연 시간 증가에 영향을 주는 요인을 확인할 수 있습니다.

이 측정항목은 10분 간격으로 단일 구독의 상태를 측정합니다. 이 측정항목은 구독이 일관적인 낮은 지연 시간을 달성하는 데 필요한 다음 기준에 대한 통계를 제공합니다.

무시 가능한 검색 요청입니다.
무시 가능한 부정적으로 확인된 메시지입니다(NACK 상태).
무시 가능한 만료된 메시지 확인 마감 시한입니다.
30초 미만의 일관적인 확인 지연 시간입니다.
일관적으로 활용률이 낮으면 구독에 새 메시지를 처리할 수 있는 용량이 일관적으로 충분함을 의미합니다.

전송 지연 시간 상태 점수 측정항목은 지정된 각 기준에 대해 점수를 0 또는 1로 보고합니다. 점수 1은 정상 상태를 나타내며 점수 0은 비정상 상태를 나타냅니다.

탐색 요청: 최근 10분 동안 구독에 탐색 요청이 포함된 경우 점수가 0으로 설정됩니다. 구독을 탐색하면 오래된 메시지가 처음 게시되고 나서 한참 후에 재생되어 전송 지연 시간이 증가할 수 있습니다.
부정적으로 확인된(NACK된) 메시지: 구독에 최근 10분 동안 부정적인 확인(NACK) 요청이 포함된 경우 점수가 0으로 설정됩니다. 부정 확인은 메시지를 다시 전송하도록 만들고 전송 지연 시간을 늘립니다.
만료된 확인 마감 시한: 구독에 최근 10분 동안 만료된 확인 마감 시한이 포함된 경우 점수가 0으로 설정됩니다. 확인 기한이 만료된 메시지는 다시 전송되고 전송 지연 시간이 늘어납니다.
확인 지연 시간: 최근 10분 동안 모든 확인 지연 시간의 99.9번째 백분위수가 30초보다 크면 점수가 0으로 설정됩니다. 높은 확인 지연 시간은 구독자 클라이언트가 메시지를 처리하는 데 비정상적으로 시간이 오래 걸린다는 신호입니다. 이 점수는 구독자 클라이언트 측에 버그 또는 일부 리소스 제약조건이 있음을 의미할 수 있습니다.
낮은 사용률: 사용률은 각 구독 유형에 따라 다르게 계산됩니다.
- StreamingPull: 충분한 스트림이 열려 있지 않으면 점수가 0으로 설정됩니다. 새 메시지에 대해 적절한 용량이 지원되도록 더 많은 스트림을 엽니다.
- 푸시: 푸시 엔드포인트에 미해결 메시지가 너무 많으면 점수가 0으로 설정됩니다. 새 메시지 용량을 확보할 수 있도록 푸시 엔드포인트에 용량을 더 추가하세요.
- 풀: 미해결 풀 요청이 충분하지 않으면 점수가 0으로 설정됩니다. 새 메시지를 수신할 수 있도록 준비하기 위해 더 많은 동시 풀 요청을 엽니다.

측정항목을 보려면 측정항목 탐색기에서 Pub/Sub 구독 리소스 유형에 대해 전송 지연 시간 상태 점수 측정항목을 선택합니다. 한 번에 하나만 구독을 선택하도록 필터를 추가합니다. 누적 영역 차트를 선택하고 특정 시점을 지정하여 해당 시점에 구독의 기준 점수를 확인합니다.

다음은 누적 영역 차트를 사용하여 1시간 동안으로 구성된 측정항목의 스크린샷입니다. 결합된 상태 점수는 오전 4시 15분에 5까지 올라가고 각 기준마다 1점이 부여됩니다. 나중에 결합 점수는 활용률 점수가 0이 되는 오전 4시 20분에 4로 낮아집니다.

전송 지연 시간 측정항목의 스크린샷

모니터링 쿼리 언어는 Cloud Monitoring 시계열 데이터에 대한 표현형 텍스트 기반 인터페이스를 제공합니다. 다음 MQL 쿼리는 구독의 전송 지연 시간 상태 점수를 측정하는 차트를 만듭니다.

fetch pubsub_subscription
| metric 'pubsub.googleapis.com/subscription/delivery_latency_health_score'
| filter (resource.subscription_id == '$SUBSCRIPTION')
| group_by 1m,
   [value_delivery_latency_health_score_sum:
     sum(if(value.delivery_latency_health_score, 1, 0))]
| every 1m

확인 기한 만료 모니터링

메시지 전송 지연 시간을 줄이기 위해 Pub/Sub는 제한된 기간 동안 구독자 클라이언트가 지정된 메시지를 확인(ack)하도록 허용합니다. 이 기간을 ack 기한이라고 부릅니다. 구독자가 메시지를 너무 오래 확인하지 않으면 메시지가 다시 전송되어 구독자에게 중복 메시지가 표시됩니다. 이러한 재전송은 여러 가지 이유로 발생할 수 있습니다.

구독자가 완전히 프로비저닝되지 않았습니다. 스레드나 머신이 더 필요합니다.
각 메시지는 메시지 확인 기한보다 처리하는 데 시간이 오래 걸립니다. Cloud 클라이언트 라이브러리는 일반적으로 개별 메시지의 기한을 구성 가능한 최대 한도까지 연장합니다. 그러나 최대 연장 기한은 라이브러리에도 적용됩니다.
일부 메시지가 지속적으로 클라이언트와 충돌합니다.

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

풀 및 StreamingPull: subscription/expired_ack_deadlines_count
푸시: response_code != "success"로 필터링된 subscription/push_request_count

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

메시지 처리량 모니터링

풀 및 StreamingPull 구독자는 각 풀 응답에서 일괄 메시지를 수신할 수 있으며, 푸시 구독은 각 푸시 요청에서 단일 메시지를 수신합니다. 다음 측정항목을 사용하여 구독자가 처리하는 일괄 메시지 처리량을 모니터링할 수 있습니다.

풀: subscription/pull_request_count(이 측정항목에는 메시지 없이 반환된 풀 요청이 포함될 수도 있음)
StreamingPull: subscription/streaming_pull_response_count

delivery_type 라벨로 필터링된 subscription/sent_message_count 측정항목을 사용하여 처리되는 개별 또는 일괄 처리되지 않은 메시지 처리량을 모니터링할 수 있습니다.

다음 MQL 쿼리는 특정 Pub/Sub 구독에 10분마다 전송된 총 메시지 수를 보여주는 시계열 차트를 제공합니다. $PROJECT_NAME 및 $SUBSCRIPTION_NAME의 자리표시자 값을 실제 프로젝트 및 주제 식별자로 바꿉니다.

fetch pubsub_subscription
| metric 'pubsub.googleapis.com/subscription/sent_message_count'
| filter resource.project_id == '$PROJECT_NAME'
&& resource.subscription_id == '$SUBSCRIPTION_NAME'
| align delta(10m)
| every 10m
| group_by [],
[value_sent_message_count_aggregate: aggregate(value.sent_message_count)]

푸시 구독 모니터링

푸시 구독의 경우 다음 측정항목을 모니터링합니다.

subscription/push_request_count

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

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

Pub/Sub는 일반적으로 미해결 메시지 수를 제한합니다. 대부분의 경우 미해결 메시지 수 목표를 1,000개 미만으로 설정합니다. 처리량이 초당 10,000개 메시지의 속도를 달성한 후 서비스가 미해결 메시지 수에 대한 제한을 조정합니다. 이 제한은 1,000개 단위로 적용됩니다. 최댓값을 넘어서는 구체적인 보장이 없으므로 미해결 메시지 1,000개가 적합한 기준입니다.
subscription/push_request_latencies

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

더 높은 미해결 메시지 제한에 액세스하려면 푸시 구독자는 수신한 메시지 중 99% 이상을 확인해야 합니다.

모니터링 쿼리 언어를 사용하여 구독자가 확인한 메시지의 비율을 계산할 수 있습니다. 다음 MQL 쿼리는 구독자가 구독을 확인하는 메시지 비율이 포함된 차트를 만듭니다.

fetch pubsub_subscription
| metric 'pubsub.googleapis.com/subscription/push_request_count'
| filter
    (resource.subscription_id == '$SUBSCRIPTION')
    | filter_ratio_by [], metric.response_class == 'ack'
    | every 1m

필터로 구독 모니터링

구독에 필터를 구성한 경우 Pub/Sub에서 필터와 일치하지 않는 메시지를 자동으로 확인합니다. 이 자동 확인을 모니터링할 수 있습니다.

백로그 측정항목에는 필터와 일치하는 메시지만 포함됩니다.

필터와 일치하지 않는 자동 확인 메시지 비율을 모니터링하려면 delivery_type 라벨이 filter로 설정된 subscription/ack_message_count 측정항목을 사용합니다.

필터와 일치하지 않는 자동 확인 메시지의 처리량 및 비용을 모니터링하려면 operation_type 라벨이 filter_drop으로 설정된 subscription/byte_cost 측정항목을 사용합니다. 이러한 메시지의 수수료에 대한 자세한 내용은 Pub/Sub 가격 책정 페이지를 참조하세요.

전송할 수 없는 전달된 메시지 모니터링

Pub/Sub가 데드 레터 주제로 전달하는 전송할 수 없는 메시지를 모니터링하려면 subscription/dead_letter_message_count 측정항목을 사용합니다. 이 측정항목에서는 Pub/Sub가 구독에서 전달하는 전송할 수 없는 메시지 수를 보여줍니다.

Pub/Sub가 전송할 수 없는 메시지를 전달하는지 확인하려면 subscription/dead_letter_message_count 측정항목을 topic/send_request_count 측정항목과 비교하면 됩니다. Pub/Sub가 이러한 메시지를 전달하는 데드 레터 주제에 대해 비교를 수행합니다.

또한 데드 레터 주제에 구독을 연결한 후 다음 측정항목을 통해 이 구독에서 전송할 수 없는 메시지를 모니터링할 수 있습니다.

subscription/num_undelivered_messages

구독에 누적된 전달된 메시지 수
subscription/oldest_unacked_message_age

구독에서 가장 오래된 전달 메시지의 기간

정상 게시자 유지

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

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

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

메시지 처리량 모니터링

게시자는 메시지를 일괄적으로 보낼 수 있습니다. 다음 측정항목을 사용하여 게시자가 전송하는 메시지 처리량을 모니터링할 수 있습니다.

topic/send_request_count: 게시자가 전송하는 일괄 메시지 볼륨
topic/message_sizes의 개수: 게시자가 전송하는 개별(일괄 처리되지 않은) 메시지 볼륨

게시된 메시지의 정확한 개수를 확인하려면 다음 MQL 쿼리를 사용하세요. 이 MQL 쿼리는 지정된 시간 간격 내에 특정 Pub/Sub 주제에 게시된 개별 메시지의 수를 효과적으로 검색합니다. $PROJECT_NAME 및 $TOPIC_ID의 자리표시자 값을 실제 프로젝트 및 주제 식별자로 바꿉니다.

fetch pubsub_topic
| metric 'pubsub.googleapis.com/topic/message_sizes'
| filter resource.project_id == '$PROJECT_NAME'
&& resource.topic_id == '$TOPIC_ID'
| align delta(60m)
| every 60m
| group_by [resource.topic_id],
[value_message_sizes_sum: count(value.message_sizes)]

특히 일일 측정항목의 경우 더 나은 시각화를 위해 다음 사항을 고려하세요.

장기간에 걸쳐 데이터를 확인하여 일일 동향에 대한 더 많은 맥락을 제공하세요.
막대 그래프를 사용하여 일일 메시지 수를 나타냅니다.

다음 단계

특정 측정항목에 대해 알림을 만들려면 측정항목 기반 알림 정책 관리를 참조하세요.
MQL을 사용하여 모니터링 차트를 빌드하는 방법은 쿼리 편집기 사용을 참조하세요.
측정항목, 모니터링 리소스, 모니터링 리소스 그룹, 알림 정책 등 Monitoring API의 API 리소스에 대해 자세히 알아보려면 API 리소스를 참조하세요.