Monitorar o Pub/Sub no Cloud Monitoring

Use o console Google Cloud ou a API Cloud Monitoring para monitorar o Pub/Sub.

Este documento mostra como monitorar o uso do Pub/Sub no console do Google Cloud usando o Monitoring.

  • Se você quiser ver métricas de outros recursos do Google Cloud além das métricas do Pub/Sub, use o Monitoring.

  • Caso contrário, use os painéis de monitoramento fornecidos no Pub/Sub. Consulte Monitorar tópicos e Monitorar assinaturas.

Para práticas recomendadas sobre como usar métricas no escalonamento automático, consulte Práticas recomendadas para usar métricas do Pub/Sub como um indicador de escalonamento.

Antes de começar

Antes de usar o Monitoring, verifique se você preparou o seguinte:

  • Uma conta do Cloud Billing

  • Um projeto do Pub/Sub com faturamento ativado

Uma maneira de garantir que você tenha ambos é concluir o guia de início rápido sobre o uso do Console do Cloud.

Ver um painel

Com um painel, é possível ver e analisar dados de diferentes fontes no mesmo contexto. O Google Cloud oferece painéis predefinidos e personalizados. Por exemplo, é possível conferir um painel predefinido do Pub/Sub ou criar um painel personalizado que mostre dados de métricas, políticas de alertas e entradas de registro relacionadas ao Pub/Sub.

Para monitorar seu projeto do Pub/Sub usando o Cloud Monitoring, siga estas etapas:

  1. No console do Google Cloud , acesse a página Monitoring.

    Acessar Monitoring

  2. Selecione o nome do seu projeto (se ele ainda não estiver selecionado) na parte superior da página.

  3. Clique em Painéis no menu de navegação.

  4. Na página Visão geral dos painéis, crie um painel ou selecione o painel Pub/Sub.

    Para pesquisar o painel Pub/Sub, no filtro de Todos os painéis, selecione a propriedade Nome e digite Pub/Sub.

Para mais informações sobre como criar, editar e gerenciar um painel personalizado, consulte Gerenciar painéis personalizados.

Ver uma única métrica do Pub/Sub

Para conferir uma única métrica do Pub/Sub usando o console Google Cloud , siga estas etapas:

  1. No console do Google Cloud , acesse a página Monitoring.

    Acessar Monitoring

  2. No painel de navegação, selecione Metrics Explorer.

  3. Na seção Configuração, clique em Selecionar uma métrica.

  4. No filtro, insira Pub/Sub.

  5. Em Recursos ativos, selecione Assinatura do Pub/Sub ou Tópico do Pub/Sub.

  6. Detalhe uma métrica específica e clique em Aplicar.

    A página de uma métrica específica é aberta.

Leia a documentação do Cloud Monitoring para saber mais sobre o painel de monitoramento.

Ver métricas e tipos de recursos do Pub/Sub

Acessar o editor de PromQL

O Metrics Explorer é uma interface do Cloud Monitoring criada para explorar e visualizar seus dados de métricas. No Metrics Explorer, é possível usar a linguagem de consulta do Prometheus (PromQL) para consultar e analisar suas métricas do Pub/Sub.

Para acessar o editor de código e consultar métricas do Cloud Monitoring com PromQL no Metrics Explorer, consulte Usar o editor de código para PromQL.

Por exemplo, é possível inserir uma consulta PromQL para monitorar a contagem de mensagens enviadas para uma assinatura específica em um período de uma hora:

sum(
  increase({
    "__name__"="pubsub.googleapis.com/subscription/sent_message_count",
    "monitored_resource"="pubsub_subscription",
    "project_id"="your-project-id",
    "subscription_id"="your-subscription-id"
  }[1h])
)

Monitorar o uso da cota

Para um determinado projeto, use o painel de cotas do IAM e administrador para conferir as cotas e o uso atuais.

Para conferir o uso histórico da cota, use as seguintes métricas:

Essas métricas usam o tipo de recurso monitorado consumer_quota. Para mais métricas relacionadas a cotas, consulte a Lista de métricas.

Por exemplo, a consulta PromQL a seguir cria um gráfico com a fração da cota do editor usada em cada região:

sum by (quota_metric, location) (
  rate({
    "__name__"="serviceruntime.googleapis.com/quota/rate/net_usage",
    "monitored_resource"="consumer_quota",
    "service"="pubsub.googleapis.com",
    "quota_metric"="pubsub.googleapis.com/regionalpublisher"
  }[${__interval}])
)
/
(max by (quota_metric, location) (
  max_over_time({
    "__name__"="serviceruntime.googleapis.com/quota/limit",
    "monitored_resource"="consumer_quota",
    "service"="pubsub.googleapis.com",
    "quota_metric"="pubsub.googleapis.com/regionalpublisher"
  }[${__interval}])
) / 60 )

Se você prevê que o uso excede os limites de cota padrão, crie políticas de alerta para todas as cotas relevantes. Esses alertas são acionados quando o uso atinge uma fração do limite. Por exemplo, a consulta PromQL a seguir aciona uma política de alertas quando qualquer cota do Pub/Sub excede 80% de uso:

sum by (quota_metric, location) (
  increase({
    "__name__"="serviceruntime.googleapis.com/quota/rate/net_usage",
    "monitored_resource"="consumer_quota",
    "service"="pubsub.googleapis.com"
  }[1m])
)
/
max by (quota_metric, location) (
   max_over_time({
    "__name__"="serviceruntime.googleapis.com/quota/limit",
    "monitored_resource"="consumer_quota",
    "service"="pubsub.googleapis.com"
  }[1m])
)
> 0.8

Para um monitoramento e alertas mais personalizados sobre métricas de cota, consulte Como usar métricas de cota.

Consulte Cotas e limites para mais informações sobre cotas.

Manter uma assinatura em dia

Para manter uma assinatura saudável, é possível monitorar várias propriedades usando as métricas fornecidas pelo Pub/Sub. Por exemplo, é possível monitorar o volume de mensagens não confirmadas, o vencimento dos prazos de confirmação de mensagens e assim por diante. Você também pode verificar se a assinatura está íntegra o suficiente para alcançar uma baixa latência de entrega de mensagens.

Consulte as próximas seções para mais detalhes sobre as métricas específicas.

Monitorar o backlog de mensagens

Para garantir que os inscritos estejam acompanhando o fluxo de mensagens, crie um painel. O painel pode mostrar as seguintes métricas de backlog, agregadas por recurso, para todas as suas assinaturas:

Crie políticas de alertas que sejam acionadas quando esses valores estiverem fora do intervalo aceitável no contexto do seu sistema. Por exemplo, o número absoluto de mensagens não confirmadas não é necessariamente significativo. Um backlog de um milhão de mensagens pode ser aceitável para uma assinatura de um milhão de mensagens por segundo, mas inaceitável para uma assinatura de uma mensagem por segundo.

Use a versão regional das métricas em vez das globais.

O Pub/Sub oferece versões regionais e globais das métricas usadas para monitorar o backlog de assinaturas. Use as versões regionais com o sufixo by_region:

Não use as versões globais dessas métricas se quiser que seus painéis de monitoramento e políticas de alertas sejam resilientes a falhas de uma única região. As versões globais dessas métricas exigem o cálculo do backlog em todas as regiões conhecidas por ter mensagens, o que significa que a indisponibilidade em uma única região resulta em uma lacuna de dados. Já as versões by_region das métricas calculam e informam o backlog por região. Se não for possível calcular o backlog de uma única região, a métrica ainda vai informar valores para as outras regiões.

Problemas comuns de backlog

Sintomas Problema Soluções
Tanto oldest_unacked_message_age_by_region quanto num_unacked_messages_by_region estão crescendo no mesmo ritmo. Inscritos que não acompanham o volume de mensagens
  • Adicione mais linhas de execução ou processos de assinantes.
  • Adicione mais máquinas ou contêineres de assinantes.
  • Procure sinais de bugs no código que impeçam o reconhecimento ou o processamento das mensagens a tempo. Consulte Expiração do prazo de confirmação do Monitoring.
Se houver um tamanho de backlog pequeno e constante combinado com um oldest_unacked_message_age_by_region em crescimento constante, talvez haja algumas mensagens que não podem ser processadas. Mensagens travadas
  • Analise os registros do aplicativo para entender se algumas mensagens estão causando falhas no código. É improvável, mas possível, que as mensagens ofensivas estejam presas no Pub/Sub em vez de no seu cliente. Abra um caso de suporte depois de ter certeza de que seu código processa cada mensagem corretamente.
  • Se algumas mensagens estiverem causando falhas no seu código, encaminhe-as para um tópico de mensagens inativas.
O oldest_unacked_message_age_by_region excede a duração da retenção de mensagens da assinatura. Perda permanente de dados
  • Configure um alerta que seja acionado antes do fim do período de retenção de mensagens.

Monitorar a integridade da latência de exibição

No Pub/Sub, a latência de entrega é o tempo necessário para que uma mensagem publicada seja entregue a um assinante. Se o backlog de mensagens estiver aumentando, use a pontuação de integridade da latência de entrega (subscription/delivery_latency_health_score) para verificar quais fatores estão contribuindo para o aumento da latência.

Essa métrica mede a integridade de uma única assinatura em uma janela contínua de 10 minutos. A métrica fornece insights sobre os seguintes critérios, necessários para que uma assinatura alcance uma baixa latência consistente:

  • Solicitações de busca insignificantes.

  • Mensagens com confirmação negativa (nacked) insignificantes.

  • Prazos de confirmação de mensagens expiradas insignificantes.

  • Latência de confirmação consistente de menos de 30 segundos.

  • Utilização baixa consistente, ou seja, a assinatura tem capacidade adequada para processar novas mensagens.

A métrica Pontuação de integridade da latência de exibição informa uma pontuação de 0 ou 1 para cada um dos critérios especificados. Uma pontuação de 1 indica um estado íntegro e 0 indica um estado não íntegro.

  • Solicitações de busca: se a assinatura tiver solicitações de busca nos últimos 10 minutos, a pontuação será definida como 0. Buscar uma assinatura pode fazer com que mensagens antigas sejam reproduzidas muito tempo depois de terem sido publicadas, aumentando a latência de entrega.

  • Mensagens com confirmação negativa (nacked): se a assinatura tiver solicitações de confirmação negativa (nack) nos últimos 10 minutos, a pontuação será definida como 0. Uma confirmação negativa faz com que uma mensagem seja reenviada com uma latência de entrega maior.

  • Prazos de confirmação expirados: se a assinatura tiver prazos de confirmação expirados nos últimos 10 minutos, a pontuação será definida como 0. As mensagens cujo prazo de confirmação expirou são reenviadas com uma latência de entrega maior.

  • Latências de confirmação: se o percentil 99,9 de todas as latências de confirmação nos últimos 10 minutos for maior que 30 segundos, a pontuação será definida como 0. Uma alta latência de confirmação é um sinal de que um cliente assinante está demorando muito para processar uma mensagem. Essa pontuação pode indicar um bug ou algumas restrições de recursos no lado do cliente assinante.

  • Baixa utilização: a utilização é calculada de maneira diferente para cada tipo de assinatura.

    • StreamingPull: se você não tiver fluxos abertos suficientes, a pontuação será definida como 0. Abra mais streams para garantir que você tenha capacidade suficiente para novas mensagens.

    • Push: se você tiver muitas mensagens pendentes para seu endpoint de push, a pontuação será definida como 0. Adicione mais capacidade ao seu endpoint de push para ter espaço para novas mensagens.

    • Pull: se você não tiver solicitações de pull pendentes suficientes, a pontuação será definida como 0. Abra mais solicitações de pull simultâneas para garantir que você está pronto para receber novas mensagens.

Para conferir a métrica, em Metrics Explorer, selecione a métrica Pontuação de integridade da latência de entrega para o tipo de recurso de assinatura do Pub/Sub. Adicione um filtro para selecionar apenas uma assinatura por vez. Selecione o Gráfico de área empilhada e aponte para um momento específico para verificar as pontuações de critério da assinatura naquele momento.

A captura de tela a seguir mostra a métrica representada em um período de uma hora usando um gráfico de área empilhada. A pontuação de integridade combinada aumenta para 5 às 4h15, com uma pontuação de 1 para cada critério. Mais tarde, a pontuação combinada diminui para 4 às 4h20, quando a pontuação de utilização cai para 0.

Captura de tela da métrica de latência de exibição

A PromQL oferece uma interface expressiva e baseada em texto para dados de séries temporais do Cloud Monitoring. A consulta PromQL a seguir cria um gráfico para medir a pontuação de integridade da latência de entrega de uma assinatura.

sum_over_time(
  {
    "__name__"="pubsub.googleapis.com/subscription/delivery_latency_health_score",
    "monitored_resource"="pubsub_subscription",
    "subscription_id"="$SUBSCRIPTION"
  }[${__interval}]
)

Monitorar o vencimento do prazo de confirmação

Para reduzir a latência de entrega de mensagens, o Pub/Sub permite que os clientes assinantes tenham um período limitado para confirmar (ack) uma mensagem específica. Esse período é conhecido como prazo de confirmação. Se os assinantes demorarem muito para confirmar as mensagens, elas serão reenviadas, resultando em mensagens duplicadas para os assinantes. Isso pode acontecer por vários motivos:

  • Seus assinantes estão subprovisionados (você precisa de mais linhas de execução ou máquinas).

  • Cada mensagem leva mais tempo para ser processada do que o prazo de confirmação. As bibliotecas de cliente do Cloud geralmente estendem o prazo para mensagens individuais até um máximo configurável. No entanto, também há um prazo máximo de extensão para as bibliotecas.

  • Algumas mensagens falham consistentemente no cliente.

Você pode medir a taxa em que os assinantes perdem o prazo de confirmação. A métrica específica depende do tipo de assinatura:

Caso a taxa de expiração de prazo de confirmação seja alta demais, seu sistema poderá ter um custo alto devido à falta de eficiência. Você paga por cada reenvio e pela tentativa de processar cada mensagem repetidamente. Por outro lado, uma taxa de expiração pequena (por exemplo, 0,1 a 1%) pode ser normal.

Monitorar a capacidade de processamento de mensagens

Os assinantes de Pull e StreamingPull podem receber lotes de mensagens em cada resposta de pull. As assinaturas por push recebem uma única mensagem em cada solicitação de push. É possível monitorar a capacidade de processamento de mensagens em lote processadas pelos seus assinantes com estas métricas:

É possível monitorar o throughput de mensagens individuais ou não em lote processadas pelos seus assinantes com a métrica subscription/sent_message_count filtrada pelo rótulo delivery_type.

A consulta PromQL a seguir mostra um gráfico de série temporal com o número total de mensagens enviadas para uma assinatura específica do Pub/Sub em um período contínuo de 10 minutos. Substitua os valores de marcador de posição para $PROJECT_NAME e $SUBSCRIPTION_NAME pelos identificadores reais do projeto e do tópico.

sum(
  increase({
    "__name__"="pubsub.googleapis.com/subscription/sent_message_count",
    "monitored_resource"="pubsub_subscription",
    "project_id"="$PROJECT_NAME",
    "subscription_id"="$SUBSCRIPTION_NAME"
  }[10m])
)

Monitorar assinaturas push

Para assinaturas por push, monitore estas métricas:

  • subscription/push_request_count

    Agrupe a métrica por response_code e subscription_id. Como as assinaturas push do Pub/Sub usam códigos de resposta como confirmações implícitas de mensagens, é importante monitorar os códigos de resposta de solicitações push. Como as assinaturas de push regressam exponencialmente em caso de erros ou alcance do tempo limite, o backlog pode aumentar rapidamente de acordo com o modo como seu endpoint responde.

    Considere definir um alerta para altas taxas de erro, já que elas levam a entregas lentas e um backlog crescente. É possível criar uma métrica filtrada por classe de resposta. No entanto, as contagens de solicitações push provavelmente serão mais úteis como uma ferramenta para investigar o tamanho e a idade crescentes do backlog.

  • subscription/num_outstanding_messages

    O Pub/Sub geralmente limita o número de mensagens pendentes. Procure ter menos de 1.000 mensagens pendentes na maioria das situações. Depois que a capacidade de processamento atinge uma taxa da ordem de 10.000 mensagens por segundo, o serviço ajusta o limite para o número de mensagens pendentes. Essa limitação é feita em incrementos de 1.000. Não há garantias específicas além do valor máximo. Portanto, 1.000 mensagens pendentes é um bom guia.

  • subscription/push_request_latencies

    Essa métrica ajuda a entender a distribuição da latência de resposta do endpoint de push. Devido ao limite no número de mensagens pendentes, a latência do endpoint afeta a capacidade de processamento da assinatura. Se leva 100 milissegundos para processar cada mensagem, o limite de capacidade de processamento provavelmente será de 10 mensagens por segundo.

Para ter acesso a limites mais altos de mensagens pendentes, os inscritos nas notificações push precisam confirmar mais de 99% das mensagens recebidas.

É possível calcular a fração de mensagens que os assinantes confirmam usando o PromQL. A consulta PromQL a seguir cria um gráfico com a fração de mensagens que os assinantes confirmam em uma assinatura:

rate({
  "__name__"="pubsub.googleapis.com/subscription/push_request_count",
  "monitored_resource"="pubsub_subscription",
  "subscription_id"="$SUBSCRIPTION",
  "response_class"="ack"
}[${__interval}])
/
rate({
  "__name__"="pubsub.googleapis.com/subscription/push_request_count",
  "monitored_resource"="pubsub_subscription",
  "subscription_id"="$SUBSCRIPTION"
}[${__interval}])

Monitorar assinaturas com filtros

Se você configurar um filtro em uma assinatura, o Pub/Sub reconhecerá automaticamente as mensagens que não corresponderem ao filtro. Você pode monitorar esse reconhecimento automático.

As métricas de backlog incluem apenas mensagens que correspondem ao filtro.

Para monitorar a taxa de mensagens com reconhecimento automático que não correspondem ao filtro, use a métrica subscription/ack_message_count com o rótulo delivery_type definido como filter.

Para monitorar a capacidade de processamento e o custo das mensagens com reconhecimento automático que não correspondem ao filtro, use a métrica subscription/byte_cost com o rótulo operation_type definido como filter_drop. Para mais informações sobre as taxas dessas mensagens, consulte a página de preços do Pub/Sub.

Monitorar assinaturas com SMTs

Se a assinatura tiver um SMT que filtra mensagens, as métricas de backlog vão incluir as mensagens filtradas até que o SMT seja executado nelas. Isso significa que o backlog pode parecer maior e a idade da mensagem mais antiga não confirmada pode parecer mais antiga do que o que será entregue ao assinante. Isso é especialmente importante se você estiver usando essas métricas para fazer o escalonamento automático de assinantes.

Monitorar mensagens encaminhadas que não podem ser entregues

Para monitorar mensagens não entregues que o Pub/Sub encaminha para um tópico de mensagens inativas, use a métrica subscription/dead_letter_message_count. Essa métrica mostra o número de mensagens não entregues que o Pub/Sub encaminha de uma assinatura.

Para verificar se o Pub/Sub está encaminhando mensagens não entregues, compare as métricas subscription/dead_letter_message_count e topic/send_request_count. Faça a comparação para o tópico de mensagens inativas a que o Pub/Sub encaminha essas mensagens.

Também é possível anexar uma assinatura ao tópico de mensagens inativas e monitorar as mensagens encaminhadas que não podem ser entregues nessa assinatura usando as seguintes métricas:

Manter um publisher saudável

O principal objetivo de um editor é manter a rapidez dos dados de mensagens. Monitore essa performance usando topic/send_request_count, agrupada por response_code. Essa métrica indica se o Pub/Sub está íntegro e aceitando solicitações.

Uma taxa de erros repetíveis em segundo plano (inferior a 1%) não é motivo de preocupação, já que a maioria das bibliotecas de cliente do Cloud tenta novamente em caso de falhas de mensagens. Investigue taxas de erro maiores que 1%. Como os códigos não repetíveis são processados pelo aplicativo (e não pela biblioteca de cliente), você deve examine os códigos de resposta. Se o aplicativo do editor não tiver uma boa maneira de sinalizar um estado não íntegro, considere definir um alerta na métrica topic/send_request_count.

É igualmente importante rastrear as solicitações de publicação com falha no cliente de publicação. Embora as bibliotecas de cliente geralmente repitam solicitações com falha, elas não garantem a publicação. Consulte Publicar mensagens para detectar falhas permanentes de publicação ao usar as bibliotecas de cliente do Cloud. No mínimo, o aplicativo do publisher precisa registrar erros permanentes de publicação. Se você registrar esses erros no Cloud Logging, poderá configurar uma métrica com base em registros com uma política de alertas.

Monitorar a capacidade de processamento de mensagens

Os publishers podem enviar mensagens em lotes. É possível monitorar a capacidade de processamento de mensagens enviadas pelos seus editores com estas métricas:

Para ter uma contagem precisa de mensagens publicadas, use a seguinte consulta do PromQL. Essa consulta do PromQL recupera a contagem de mensagens individuais publicadas em um tópico específico do Pub/Sub em intervalos de tempo definidos. Substitua os valores de marcador de posição para $PROJECT_NAME e $TOPIC_ID pelos identificadores reais do projeto e do tópico.

sum by (topic_id) (
  increase({
    "__name__"="pubsub.googleapis.com/topic/message_sizes_count",
    "monitored_resource"="pubsub_topic",
    "project_id"="$PROJECT_NAME",
    "topic_id"="$TOPIC_ID"
  }[${__interval}])
)

Para melhorar a visualização, principalmente das métricas diárias, considere o seguinte:

  • Analise seus dados por um período mais longo para contextualizar melhor as tendências diárias.

  • Use gráficos de barras para representar as contagens diárias de mensagens.

A seguir