Monitorar o Pub/Sub no Cloud Monitoring

Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

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

Neste documento, mostramos 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 do Pub/Sub, use o Monitoring.

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

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 as duas coisas é concluir o guia de início rápido usando o console do Cloud.

Ver um painel existente

O painel permite ver e analisar dados de diferentes fontes no mesmo contexto. O Google Cloud fornece painéis predefinidos e personalizados. Por exemplo, é possível ver um painel predefinido do Pub/Sub ou criar um painel personalizado que exibe 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, execute as seguintes 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 novo painel ou selecione o painel atual do Pub/Sub.

    Para pesquisar o painel Pub/Sub atual, no filtro Todos os painéis, selecione a propriedade Nome e insira 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 visualizar uma única métrica do Pub/Sub usando o Console do Google Cloud, execute as seguintes 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. Acesse 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 do Pub/Sub e tipos de recursos

Monitorar o uso de cotas

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

Veja o uso histórico da cota usando as seguintes métricas:

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

Por exemplo, a consulta Linguagem de consulta do Monitoring a seguir cria um gráfico com a fração da cota de editor que está sendo usada em cada região:

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

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 seu uso atinge uma fração do limite. A consulta de linguagem de consulta do Monitoring a seguir aciona uma política de alertas quando qualquer cota do Pub/Sub excede 80% de uso:

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')

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

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

Mantenha uma assinatura saudável

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

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

Monitorar o backlog da mensagem

Para garantir que os assinantes 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 são acionadas quando esses valores estão fora do intervalo aceitável no contexto do sistema. Por exemplo, o número absoluto de mensagens não reconhecidas 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.

Problemas comuns de backlog

Sintomas Problema Soluções
Tanto oldest_unacked_message_age quanto num_undelivered_messages estão crescendo no mesmo ritmo. Os assinantes não estão acompanhando 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 de confirmar mensagens ou de processá-las em tempo hábil. Consulte Como monitorar a expiração do prazo de confirmação.
Se houver um tamanho de backlog pequeno e estável combinado com um oldest_unacked_message_age que está crescendo constantemente, pode haver algumas mensagens que não podem ser processadas. Mensagens travadas
  • Examine os registros do aplicativo para entender se algumas mensagens estão causando falhas no código. É improvável, mas possível, que as mensagens com problemas sejam bloqueadas no Pub/Sub, e não no seu cliente. Apresente um caso de suporte depois de confirmar que o código processa cada mensagem com êxito.
  • Se algumas mensagens estiverem causando falha no código, considere encaminhá-las para um tópico de mensagens inativas.
O oldest_unacked_message_age excede a duração da retenção de mensagens da assinatura. Perda permanente de dados
  • Configure um alerta que seja acionado antes da duração da retenção de mensagens.

Monitorar a integridade da latência de entrega

No Pub/Sub, a latência de entrega é o tempo decorrido depois que uma mensagem é publicada e entregue a um assinante. Se o backlog das 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 um aumento da latência.

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

  • Solicitações de busca insignificantes

  • Mensagens negligáveis com confirmação negativa (mensagens anuladas).

  • Prazos de confirmação de mensagens expirados negligentes.

  • A latência de confirmação é inferior a 30 segundos.

  • Baixa utilização consistente, o que significa que a assinatura consistentemente tem capacidade adequada de processar novas mensagens.

A métrica Pontuação de integridade da latência de entrega 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 uma pontuação de 0 indica um estado não íntegro.

  • Solicitações de busca: se a assinatura teve alguma solicitação de busca nos últimos 10 minutos, a pontuação é definida como 0. Buscar uma assinatura pode fazer com que as mensagens antigas sejam repetidas muito tempo após a primeira publicação, proporcionando uma latência de entrega maior.

  • Mensagens com confirmação negativa (nus): se a assinatura tiver qualquer solicitação 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 com prazo de confirmação expirado são reenviadas com maior latência de entrega.

  • Latências de confirmação: se o 99.9o percentil 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 inscrito está demorando muito para processar uma mensagem. Essa pontuação pode sugerir um bug ou algumas restrições de recursos no lado do cliente do assinante.

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

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

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

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

Para visualizar a métrica, no Metrics Explorer, selecione a métrica Pontuação de integridade da latência de exibição para o tipo de recurso da 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 horário específico para verificar as pontuações de critérios da assinatura para esse momento.

Veja a seguir uma captura de tela da métrica exibida para um período de uma hora usando um gráfico de área empilhada. A pontuação de integridade combinada é de 5, às 4h15, com uma pontuação de 1 para cada critério. Depois, 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 da exibição

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

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

Monitorar a expiração do prazo de confirmação

Para reduzir a latência de entrega de mensagens, o Pub/Sub permite que os clientes inscritos tenham um período limitado para confirmar (confirmar) uma determinada mensagem. Esse período é conhecido como prazo de confirmação. Se os assinantes demorarem muito para confirmar as mensagens, elas serão reenviadas, fazendo com que os assinantes vejam mensagens duplicadas. 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 da mensagem. 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 de falha dos assinantes no 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 pequena taxa de expiração (por exemplo, 0,1 a 1%) pode ser íntegra.

Monitorar a capacidade de processamento de mensagens

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

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

Monitorar assinaturas de push

Para assinaturas de push, monitore estas métricas:

  • subscription/push_request_count

    Agrupe a métrica por response_code e subcription_id. Como as assinaturas de push do Pub/Sub usam códigos de resposta como confirmações implícitas de mensagens, é importante monitorar os códigos de resposta à solicitação de 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 essas taxas levam a uma entrega lenta e um backlog crescente. Você pode criar uma métrica filtrada por classe de resposta. No entanto, é provável que as contagens de solicitações de push sejam mais úteis como uma ferramenta para investigar o tamanho e a idade do backlog crescente.

  • subscription/num_outstanding_messages

    O Pub/Sub geralmente limita o número de mensagens pendentes. Use menos de mil mensagens pendentes na maioria das situações. Depois que a capacidade de processamento atinge uma taxa na ordem de 10.000 mensagens por segundo, o serviço ajusta o limite do 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, mil mensagens pendentes são um bom guia.

  • subscription/push_request_latencies

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

Para acessar limites de mensagens pendentes mais altos, os assinantes de push precisam confirmar mais de 99% das mensagens que recebem.

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

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

Monitorar assinaturas com filtros

O Pub/Sub reconhece automaticamente as mensagens que não correspondem ao filtro. É possível monitorar o número, o tamanho e o custo dessas mensagens.

Para monitorar o número de mensagens que não correspondem a um filtro, use a métrica subscription/ack_message_count com o rótulo delivery_type e o valor filter.

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

Monitorar mensagens não entregues encaminhadas

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, você pode comparar a métrica subscription/dead_letter_message_count com a métrica topic/send_request_count. Faça a comparação do tópico de mensagens inativas para onde o Pub/Sub encaminha essas mensagens.

Você também pode anexar uma assinatura ao tópico de mensagens inativas e monitorar as mensagens não entregues dessa assinatura usando as seguintes métricas:

Mantenha a qualidade do editor

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

Uma taxa de segundo plano de erros que podem ser repetidos (menor que 1%) não é um motivo para se preocupar, porque a maioria das bibliotecas de cliente do Cloud repete falhas na mensagem. 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.

Tão importantes quanto o rastreamento de solicitações de publicação com falha no seu cliente de publicação. Embora as bibliotecas de cliente geralmente repitam solicitações com falha, elas não garantem a publicação. Consulte Como publicar mensagens para ver formas de detectar falhas permanentes de publicação ao usar as bibliotecas de cliente do Cloud. No mínimo, o aplicativo do editor precisa registrar erros de publicação permanentes. 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 editores podem enviar mensagens em lotes. É possível monitorar a capacidade de processamento de mensagens enviada pelos editores com estas métricas:

  • topic/send_request_count: o volume de mensagens em lote enviadas pelos editores.

  • Uma contagem de topic/message_sizes: o volume de mensagens individuais (não em lote) enviadas pelos editores.

    É possível calcular uma contagem de mensagens enviadas aplicando um agregador de contagem a essa métrica ou usando a linguagem de consulta de monitoramento. A consulta MQL a seguir cria um gráfico com a taxa de mensagens individuais enviadas em um tópico:

    fetch pubsub_topic
    | metric 'pubsub.googleapis.com/topic/message_sizes'
    | filter
        (resource.topic_id == '$TOPIC')
    | align delta(1m)
    | every 1m
    | group_by [], [row_count: row_count()]
    

A seguir