Monitorar o Pub/Sub no Cloud Monitoring

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 conferir as 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 o uso de 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 como usar o Console do Cloud.

Acessar um painel

Com um painel, você pode conferir e analisar dados de diferentes fontes no mesmo contexto. O Google Cloud oferece painéis predefinidos e personalizados. Por exemplo, é possível visualizar um painel predefinido do Pub/Sub ou criar um painel personalizado que mostra dados de métricas, políticas de alerta 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 novo painel ou selecione o painel Pub/Sub.

    Para pesquisar o painel do Pub/Sub, no filtro 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.

Conferir uma única métrica do Pub/Sub

Para conferir uma única métrica do Pub/Sub usando o console do 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, digite 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.

Para saber mais sobre o painel de monitoramento, leia a documentação do Cloud Monitoring.

Conferir as métricas e os tipos de recurso do Pub/Sub

Acessar o editor MQL

O Metrics Explorer é uma interface do Cloud Monitoring projetada para analisar e visualizar dados de métricas. No Análise detalhada de métricas, é possível usar a linguagem de consulta do Monitoring(MQL) para consultar e analisar as métricas do Pub/Sub.

Para acessar o editor MQL ao usar o Metrics Explorer, consulte Como acessar o editor de código.

Criar sua consulta MQL

Confira algumas regras básicas para criar uma consulta MQL para métricas do Pub/Sub.

  1. Comece com fetch pubsub_topic ou fetch pubsub_subscription. Essa linha de código informa ao editor o tipo de recurso do Pub/Sub que você quer consultar, como tópicos ou assinaturas.

  2. Selecione a métrica. Use | metric 'metric_name' para especificar a métrica que você quer analisar. Um exemplo de métrica do Pub/Sub é pubsub.googleapis.com/subscription/ack_message_count (para mensagens confirmadas).

  3. Use | filter para restringir os dados. Os filtros comuns incluem:

    • resource.project_id == 'your-project-id'
    • resource.topic_id == 'your-topic-id'
    • resource.subscription_id == 'your-subscription-id'

  4. Use | align e | group_by para agregar seus dados em intervalos e agrupamentos significativos.

  5. Refinar seus dados com outras cláusulas. O MQL oferece várias outras cláusulas, como | every (para definir a frequência de execução de consultas), | within (para especificar um intervalo de tempo) e muito mais.

Confira um exemplo de consulta para monitorar a contagem de mensagens por hora enviada a uma assinatura específica:

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

Monitorar o uso da cota

Em um determinado projeto, é possível usar o painel de cotas do IAM e administrador para conferir as cotas e o uso atuais.

Confira o uso histórico de cotas usando 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 MQL 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 disparados quando o uso atinge uma fração do limite. Por exemplo, a consulta da linguagem de consulta do Monitoring a seguir aciona uma política de alertas quando qualquer cota do Pub/Sub excede o uso de 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')

Para 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 saudável

Para manter uma assinatura saudável, é 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 confirmadas, a expiração dos prazos de confirmação de mensagens e assim por diante. Você também pode verificar se a assinatura está saudável o suficiente para alcançar uma latência de entrega de mensagens baixa.

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

Monitorar o backlog de mensagens

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 assinaturas:

Crie políticas de alerta que sejam acionadas quando esses valores estiverem fora do intervalo aceitável no contexto do sistema. Por exemplo, o número absoluto de mensagens não confirmadas não é necessariamente significativo. Ter um milhão de mensagens acumuladas 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 pendências

Sintomas Problema Soluções
Tanto oldest_unacked_message_age quanto num_undelivered_messages estão crescendo no mesmo ritmo. Assinantes 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 que ele confirme mensagens ou processe-as em tempo hábil. Consulte Como monitorar a expiração do prazo de confirmação.
Se houver um volume pequeno e constante de backlog combinado a um oldest_unacked_message_age com crescimento constante, pode haver algumas mensagens que não podem ser processadas. Mensagens travadas
  • Examine os registros do aplicativo para saber se algumas mensagens estão causando falhas no código. Embora seja improvável, é possível que as mensagens ofensivas fiquem travadas no Pub/Sub, e não no seu cliente. Crie um caso de suporte quando tiver certeza de que o código processa todas as mensagens.
  • Se algumas mensagens estiverem causando falhas no código, considere encaminhar essas mensagens para um tópico de mensagens inativas.
O oldest_unacked_message_age excede a duração de 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 expirar.

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

No Pub/Sub, a latência de envio é o tempo que uma mensagem publicada leva para ser entregue a um assinante. Se o acúmulo 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 de 10 minutos. A métrica fornece insights sobre os seguintes critérios, que são necessários para que uma assinatura alcance uma latência baixa consistente:

  • Solicitações de busca desprezíveis.

  • Mensagens de confirmação negativa (NACK) desprezíveis.

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

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

  • Utilização consistentemente baixa, o que significa que 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 uma pontuação de 0 indica um estado não íntegro.

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

  • Mensagens com confirmação negativa (NACK): 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 envio maior.

  • Latências de confirmação: se o percentil 99,9 de todas as latências de confirmação nos últimos 10 minutos foi 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 do assinante.

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

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

    • Push: se você tiver muitas mensagens pendentes para o endpoint de push, a pontuação será definida como 0. Adicione mais capacidade ao endpoint push para ter capacidade 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ê esteja pronto para receber novas mensagens.

Para conferir a métrica, no 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 conferir as pontuações dos critérios da assinatura nesse momento.

Confira abaixo uma captura de tela da 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 Linguagem de consulta do Monitoring é uma interface expressiva e baseada em texto para dados de séries temporais do Cloud Monitoring. A consulta de MQL a seguir cria um gráfico para medir a pontuação de integridade da latência de exibição 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 assinantes reservem um tempo limitado para confirmar (confirmação) uma determinada mensagem. Esse período é conhecido como prazo de confirmação. Se os assinantes demorarem demais para confirmar as mensagens, elas serão entregues novamente, 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.

É possível medir a taxa de perda do prazo de confirmação dos assinantes. 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 baixa de expiração (por exemplo, 0,1-1%) pode ser íntegra.

Monitorar a taxa de transferência de mensagens

Os assinantes de pull e streaming pull podem receber lotes de mensagens em cada resposta de pull. As assinaturas de push recebem uma única mensagem em cada solicitação de push. É possível monitorar a taxa de transferência de mensagens em lote processadas pelos assinantes com estas métricas:

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

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

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

Monitorar inscrições 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 das solicitações por 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, porque essas taxas causam entrega lenta e um acúmulo crescente. É possível criar uma métrica filtrada por classe de resposta. No entanto, é provável que a contagem de solicitações por push sejam mais úteis como uma ferramenta para investigar o volume e o tempo do backlog.

  • subscription/num_outstanding_messages

    O Pub/Sub geralmente limita o número de mensagens pendentes. Na maioria das situações,tente ter menos de 1.000 mensagens pendentes. Depois que a capacidade alcançar uma taxa na ordem de 10.000 mensagens por segundo, o serviço vai ajustar 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, então 1.000 mensagens pendentes é um bom guia.

  • subscription/push_request_latencies

    Essa métrica ajuda a entender a distribuição de latência de 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 maiores de mensagens pendentes, os assinantes de push precisam confirmar mais de 99% das mensagens recebidas.

É 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

Se você configurar um filtro em uma assinatura, o Pub/Sub reconhecerá automaticamente as mensagens que não correspondem ao filtro. É possível monitorar esse aviso automático.

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

Para monitorar a taxa de mensagens com confirmação automática 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 taxa de transferência e o custo das mensagens com confirmação automática 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 mensagens não entregues encaminhadas

Para monitorar as 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 a métrica subscription/dead_letter_message_count com a topic/send_request_count. Faça a comparação para o tópico de mensagens inativas para o qual o Pub/Sub encaminha essas mensagens.

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

Manter um editor saudável

O principal objetivo de um editor é manter a rapidez dos dados de mensagens. Monitore essa performance 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 secundária de erros de repetição (inferior a 1%) não é motivo de preocupação, porque a maioria das bibliotecas de cliente do Google Cloud repete as mensagens com falha. 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.

Também é importante acompanhar 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 Como publicar mensagens para saber como detectar falhas permanentes de publicação ao usar as bibliotecas de cliente do Cloud. No mínimo, o aplicativo do editor precisa registrar os 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 taxa de transferência de mensagens

Os editores podem enviar mensagens em lotes. É possível monitorar a taxa de transferência de mensagens enviada pelos editores com estas métricas:

Para ter uma contagem precisa das mensagens publicadas, use a seguinte consulta MQL. Essa consulta MQL recupera efetivamente 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 de $PROJECT_NAME e $TOPIC_ID pelos identificadores de projeto e tópico reais.

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

Para uma visualização melhor, especialmente para métricas diárias, considere o seguinte:

  • Confira seus dados em um período mais longo para fornecer mais contexto sobre as tendências diárias.

  • Use gráficos de barras para representar a contagem de mensagens diárias.

A seguir