Monitorize o Pub/Sub no Cloud Monitoring

Pode usar a Google Cloud consola ou a API Cloud Monitoring para monitorizar o Pub/Sub.

Este documento mostra-lhe como monitorizar a sua utilização do Pub/Sub na consola do Google Cloud através da monitorização.

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

  • Caso contrário, pode usar os painéis de controlo de monitorização fornecidos no Pub/Sub. Consulte os artigos Monitorizar tópicos e Monitorizar subscrições.

Para ver as práticas recomendadas sobre a utilização de métricas no ajuste de escala automático, consulte o artigo Práticas recomendadas para usar métricas do Pub/Sub como um sinal de ajuste de escala.

Antes de começar

Antes de usar a Monitorização, certifique-se de que preparou o seguinte:

  • Uma conta do Cloud Billing

  • Um projeto do Pub/Sub com a faturação ativada

Uma forma de garantir que obteve ambos é concluir o início rápido através da Cloud Console.

Veja um painel de controlo existente

Um painel de controlo permite-lhe ver e analisar dados de diferentes origens no mesmo contexto. O Google Cloud oferece painéis de controlo predefinidos e personalizados. Por exemplo, pode ver um painel de controlo do Pub/Sub predefinido ou criar um painel de controlo personalizado que apresente dados de métricas, políticas de alerta e entradas de registo relacionados com o Pub/Sub.

Para monitorizar o seu projeto do Pub/Sub através do Cloud Monitoring, siga estes passos:

  1. Na Google Cloud consola, aceda à página Monitorização.

    Aceder a Monitorização

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

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

  4. Na página Vista geral dos painéis de controlo, crie um novo painel de controlo ou selecione o painel de controlo Pub/Sub existente.

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

Para mais informações sobre como criar, editar e gerir um painel de controlo personalizado, consulte o artigo Faça a gestão de painéis de controlo personalizados.

Veja uma única métrica do Pub/Sub

Para ver uma única métrica do Pub/Sub através da consola Google Cloud , siga estes passos:

  1. Na Google Cloud consola, aceda à página Monitorização.

    Aceder a Monitorização

  2. No painel de navegação, selecione Explorador de métricas.

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

  4. No filtro, introduza Pub/Sub.

  5. Em Recursos ativos, selecione Subscrição do Pub/Sub ou Tópico do Pub/Sub.

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

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

Pode saber mais sobre o painel de controlo de monitorização lendo a documentação do Cloud Monitoring.

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

Aceda ao editor de MQL

O Explorador de métricas é uma interface no Cloud Monitoring concebida para explorar e visualizar os dados das suas métricas. No Explorador de métricas, pode usar a linguagem de consulta de monitorização(MQL) para consultar e analisar as suas métricas do Pub/Sub.

Para aceder ao editor de MQL quando usar o Explorador de métricas, consulte o artigo Aceder ao editor de código.

Crie a sua consulta MQL

Seguem-se 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. Esta linha de código indica ao editor que tipo de recurso do Pub/Sub quer consultar, como tópicos ou subscrições.

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

  3. Use | filter para restringir os seus 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 os seus dados em intervalos e agrupamentos significativos.

  5. Refine os 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.

Segue-se uma consulta de exemplo para monitorizar a contagem por hora de mensagens enviadas para uma subscrição 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)]

Monitorize a utilização da quota

Para um determinado projeto, pode usar o painel de controlo IAM e quotas de administrador para ver as quotas e a utilização atuais.

Pode ver o histórico de utilização da quota através das seguintes métricas:

Estas métricas usam o tipo de recurso consumer_quota monitorizado. Para ver mais métricas relacionadas com a quota, consulte a lista de métricas.

Por exemplo, a seguinte consulta MQL cria um gráfico com a fração da quota do publicador que está a ser 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 prevê que a sua utilização vai exceder os limites de quota predefinidos, crie políticas de alerta para todas as quotas relevantes. Estes alertas são acionados quando a sua utilização atinge uma determinada fração do limite. Por exemplo, a seguinte consulta da linguagem de consultas do Monitoring aciona uma política de alertas quando qualquer quota do Pub/Sub excede 80% de utilização:

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 uma monitorização e alertas mais personalizados nas métricas de quota, consulte o artigo Usar métricas de quota.

Consulte Quotas e limites para mais informações sobre quotas.

Mantenha uma subscrição saudável

Para manter uma subscrição saudável, pode monitorizar várias propriedades da subscrição através de métricas fornecidas pelo Pub/Sub. Por exemplo, pode monitorizar o volume de mensagens não confirmadas, a expiração dos prazos de confirmação de mensagens, etc. Também pode verificar se a sua subscrição está em bom estado para alcançar uma latência de entrega de mensagens baixa.

Consulte as secções seguintes para ver mais detalhes sobre as métricas específicas.

Monitorize o atraso de mensagens

Para garantir que os seus subscritores se mantêm a par do fluxo de mensagens, crie um painel de controlo. O painel de controlo pode mostrar as seguintes métricas de pendências, agregadas por recurso, para todas as suas subscrições:

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

Problemas comuns de pendências

Sintomas Problema Soluções
Tanto o oldest_unacked_message_age_by_region como o num_unacked_messages_by_region estão a crescer em conjunto. Os subscritores não conseguem acompanhar o volume de mensagens
  • Adicione mais processos ou threads de subscrição.
  • Adicione mais máquinas ou contentores de subscrição.
  • Procure sinais de erros no seu código que o impeçam de acusar a receção de mensagens ou processá-las atempadamente. Consulte o artigo Monitorizar a expiração do prazo de confirmação.
Se houver um tamanho da fila de espera pequeno e constante, combinado com um oldest_unacked_message_age_by_region em constante crescimento, pode haver algumas mensagens que não podem ser processadas. Mensagens bloqueadas
  • Examine os registos da aplicação para compreender se algumas mensagens estão a causar uma falha no código. É improvável, mas possível, que as mensagens ofensivas estejam bloqueadas no Pub/Sub e não no seu cliente. Apresente um registo de apoio técnico depois de ter a certeza de que o seu código processa com êxito cada mensagem.
  • Se algumas mensagens estiverem a causar falhas no seu código, considere encaminhar essas mensagens para um tópico de mensagens rejeitadas.
O oldest_unacked_message_age_by_region excede a duração da retenção de mensagens da subscrição. Perda de dados permanente
  • Configure um alerta que é acionado antes do fim da duração da retenção de mensagens.

Monitorize o estado da latência de entrega

No Pub/Sub, a latência de entrega é o tempo que uma mensagem publicada demora a ser entregue a um subscritor. Se o atraso de mensagens estiver a aumentar, pode usar a pontuação de estado de latência de entrega (subscription/delivery_latency_health_score) para verificar que fatores estão a contribuir para um aumento da latência.

Esta métrica mede o estado de uma única subscrição durante um período contínuo de 10 minutos. A métrica fornece estatísticas sobre os seguintes critérios, que são necessários para que uma subscrição alcance uma latência baixa consistente:

  • Pedidos de procura insignificantes.

  • Mensagens com reconhecimento negativo (nacked) insignificantes.

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

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

  • Uma utilização baixa consistente, o que significa que a subscrição tem sempre capacidade adequada para processar novas mensagens.

A métrica Estado da latência de fornecimento indica uma pontuação de 0 ou 1 para cada um dos critérios especificados. Uma pontuação de 1 indica um estado saudável e uma pontuação de 0 indica um estado não saudável.

  • Pedidos de procura: se a subscrição tiver tido pedidos de procura nos últimos 10 minutos, a pontuação é definida como 0. A procura de uma subscrição pode fazer com que as mensagens antigas sejam reproduzidas muito depois de terem sido publicadas pela primeira vez, o que aumenta a latência de entrega.

  • Mensagens com confirmação negativa (nacked): se a subscrição tiver pedidos de confirmação negativa (nack) nos últimos 10 minutos, a pontuação é definida como 0. Uma confirmação negativa faz com que uma mensagem seja reenviada com uma latência de entrega aumentada.

  • Prazos de confirmação expirados: se a subscrição tiver prazos de confirmação expirados nos últimos 10 minutos, a pontuação é definida como 0. As mensagens cuja data limite de confirmação expirou são reenviadas com uma latência de entrega aumentada.

  • Latências de confirmação: se o percentil 99,9 de todas as latências de confirmação nos últimos 10 minutos tiver sido superior a 30 segundos, a classificação é definida como 0. Uma latência de reconhecimento elevada é um sinal de que um cliente subscritor está a demorar um tempo anormalmente longo a processar uma mensagem. Esta pontuação pode implicar um erro ou algumas restrições de recursos do lado do cliente do subscritor.

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

    • StreamingPull: se não tiver streams abertas suficientes, a pontuação é definida como 0. Abra mais streams para garantir que tem capacidade adequada para novas mensagens.

    • Push: se tiver demasiadas mensagens pendentes para o seu ponto final push, a pontuação é definida como 0. Adicione mais capacidade ao seu ponto final de envio para ter capacidade para novas mensagens.

    • Extrair: se não tiver pedidos de extração pendentes suficientes, a pontuação é definida como 0. Abra mais pedidos de obtenção simultâneos para garantir que está tudo pronto para receber novas mensagens.

Para ver a métrica, no Explorador de métricas, selecione a métrica Estado da latência de entrega para o tipo de recurso de subscrição do Pub/Sub. Adicione um filtro para selecionar apenas uma subscrição de cada vez. Selecione o gráfico de área sobreposto e aponte para um momento específico para verificar as pontuações dos critérios da subscrição nesse momento.

Segue-se uma captura de ecrã da métrica representada num período de uma hora através de um gráfico de áreas sobrepostas. A Pontuação de Saúde combinada sobe até 5 às 04:15, com uma pontuação de 1 para cada critério. Mais tarde, a classificação combinada diminui para 4 às 04:20, quando a classificação de utilização desce para 0.

Captura de ecrã da métrica de latência de entrega

A linguagem de consulta de monitorização oferece uma interface expressiva baseada em texto para os dados de séries cronológicas do Cloud Monitoring. A seguinte consulta MQL cria um gráfico para medir a pontuação de estado da latência de entrega de uma subscrição.

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

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

Para reduzir a latência de entrega de mensagens, o Pub/Sub permite aos clientes subscritores um período limitado para acusar a receção (ack) de uma determinada mensagem. Este período é conhecido como prazo de ACK. Se os subscritores demorarem demasiado tempo a confirmar a receção das mensagens, estas são reenviadas, o que faz com que os subscritores vejam mensagens duplicadas. Esta nova entrega pode acontecer por vários motivos:

  • Os seus subscritores têm recursos insuficientes (precisa de mais linhas de execução ou máquinas).

  • Cada mensagem demora mais tempo a ser processada do que o prazo de confirmação da mensagem. Geralmente, as bibliotecas de cliente da nuvem prolongam o prazo para mensagens individuais até um máximo configurável. No entanto, também existe um prazo máximo de extensão para as bibliotecas.

  • Algumas mensagens fazem com que o cliente falhe consistentemente.

Pode medir a taxa à qual os subscritores não cumprem o prazo de confirmação. A métrica específica depende do tipo de subscrição:

As taxas de expiração do prazo de confirmação excessivas podem resultar em ineficiências dispendiosas no seu sistema. Paga por cada reenvio e por tentar processar cada mensagem repetidamente. Por outro lado, uma pequena taxa de expiração (por exemplo, 0,1 a 1%) pode ser saudável.

Monitorize o débito de mensagens

Os subscritores de obtenção e obtenção em streaming podem receber lotes de mensagens em cada resposta de obtenção; as subscrições push recebem uma única mensagem em cada pedido push. Pode monitorizar o débito de mensagens de lotes que está a ser processado pelos seus subscritores com estas métricas:

Pode monitorizar o débito de mensagens individuais ou não processadas em lote pelos seus subscritores com a métrica subscription/sent_message_count filtrada pela etiqueta delivery_type.

A seguinte consulta MQL apresenta um gráfico de séries cronológicas que mostra o número total de mensagens enviadas para uma subscrição específica do Pub/Sub a cada 10 minutos. Substitua os valores dos marcadores de posição de $PROJECT_NAME e $SUBSCRIPTION_NAME pelos identificadores reais do projeto e do tópico.

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

Monitorize as subscrições de notificações push

Para subscrições push, monitorize estas métricas:

  • subscription/push_request_count

    Agrupe a métrica por response_code e subcription_id. Uma vez que as subscrições push do Pub/Sub usam códigos de resposta como confirmações implícitas de mensagens, é importante monitorizar os códigos de resposta dos pedidos push. Uma vez que as subscrições push reagem exponencialmente quando encontram limites de tempo ou erros, a sua lista de pendências pode crescer rapidamente com base na forma como o seu ponto final responde.

    Considere definir um alerta para taxas de erro elevadas, uma vez que estas taxas levam a um envio lento e a um aumento do atraso. Pode criar uma métrica filtrada por classe de resposta. No entanto, as contagens de pedidos push são provavelmente mais úteis como uma ferramenta para investigar o tamanho e a antiguidade da fila de espera em crescimento.

  • subscription/num_outstanding_messages

    Geralmente, o Pub/Sub limita o número de mensagens pendentes. Procure ter menos de 1000 mensagens pendentes na maioria das situações. Depois de a taxa de transferência atingir uma taxa da ordem de 10 000 mensagens por segundo, o serviço ajusta o limite para o número de mensagens pendentes. Esta limitação é feita em incrementos de 1000. Não são dadas garantias específicas além do valor máximo, pelo que 1000 mensagens pendentes é uma boa orientação.

  • subscription/push_request_latencies

    Esta métrica ajuda a compreender a distribuição da latência de resposta do ponto final de envio. Devido ao limite do número de mensagens pendentes, a latência do ponto final afeta o débito da subscrição. Se demorar 100 milissegundos a processar cada mensagem, é provável que o seu limite de débito seja de 10 mensagens por segundo.

Para aceder a limites de mensagens pendentes mais elevados, os subscritores de push têm de confirmar mais de 99% das mensagens que recebem.

Pode calcular a fração de mensagens que os subscritores confirmam através da linguagem de consulta de monitorização. A seguinte consulta MQL cria um gráfico com a fração de mensagens que os subscritores reconhecem numa subscrição:

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

Monitorize subscrições com filtros

Se configurar um filtro numa subscrição, o Pub/Sub confirma automaticamente as mensagens que não correspondem ao filtro. Pode monitorizar esta confirmação automática.

As métricas de pendências incluem apenas mensagens que correspondem ao filtro.

Para monitorizar a taxa de mensagens com confirmação automática que não correspondem ao filtro, use a métrica subscription/ack_message_count com a etiqueta delivery_type definida como filter.

Para monitorizar o débito e o custo das mensagens com confirmação automática que não correspondem ao filtro, use a métrica subscription/byte_cost com a etiqueta operation_type definida como filter_drop. Para mais informações sobre as taxas destas mensagens, consulte a página de preços do Pub/Sub.

Monitorize subscrições com SMTs

Se a sua subscrição contiver um SMT que filtra mensagens, as métricas de pendências incluem as mensagens filtradas até que o SMT seja efetivamente executado nas mesmas. Isto significa que a fila de espera pode parecer maior e a idade da mensagem não confirmada mais antiga pode parecer mais antiga do que a que vai ser entregue ao seu subscritor. É especialmente importante ter isto em atenção se estiver a usar estas métricas para ajustar automaticamente a escala dos subscritores.

Monitorize mensagens não entregues encaminhadas

Para monitorizar mensagens não entregues que o Pub/Sub encaminha para um tópico de mensagens rejeitadas, use a métrica subscription/dead_letter_message_count. Esta métrica mostra o número de mensagens não entregues que o Pub/Sub encaminha a partir de uma subscrição.

Para verificar se o Pub/Sub está a encaminhar mensagens não entregues, pode comparar a métrica subscription/dead_letter_message_count com a métrica topic/send_request_count. Faça a comparação para o tópico de mensagens não entregues para o qual o Pub/Sub encaminha estas mensagens.

Também pode anexar uma subscrição ao tópico de mensagens não entregues e, em seguida, monitorizar as mensagens não entregues encaminhadas nesta subscrição através das seguintes métricas:

Mantenha um publicador saudável

O objetivo principal de um publicador é persistir rapidamente os dados das mensagens. Monitorize este desempenho através de topic/send_request_count, agrupado por response_code. Esta métrica dá-lhe uma indicação de se o Pub/Sub está em bom estado e a aceitar pedidos.

Uma taxa de erros repetíveis em segundo plano (inferior a 1%) não é motivo de preocupação, uma vez que a maioria das bibliotecas de cliente da nuvem tenta novamente as falhas de mensagens. Investigue as taxas de erro superiores a 1%. Uma vez que os códigos não repetíveis são processados pela sua aplicação (em vez de pela biblioteca de cliente), deve examinar os códigos de resposta. Se a sua aplicação de publicador não tiver uma boa forma de sinalizar um estado não saudável, considere definir um alerta na métrica topic/send_request_count.

É igualmente importante monitorizar os pedidos de publicação com falhas no seu cliente de publicação. Embora as bibliotecas de cliente geralmente tentem novamente os pedidos com falhas, não garantem a publicação. Consulte o artigo Publicar mensagens para saber como detetar falhas de publicação permanentes quando usa as bibliotecas de cliente do Google Cloud. No mínimo, a sua aplicação de publicador tem de registar erros de publicação permanentes. Se registar esses erros no Cloud Logging, pode configurar uma métrica baseada em registos com uma política de alerta.

Monitorize o débito de mensagens

Os publicadores podem enviar mensagens em lotes. Pode monitorizar o débito de mensagens enviadas pelos seus publicadores com estas métricas:

Para obter uma contagem precisa das mensagens publicadas, use a seguinte consulta MQL. Esta consulta MQL obtém eficazmente a quantidade de mensagens individuais publicadas num tópico específico do Pub/Sub dentro de intervalos de tempo definidos. Substitua os valores dos marcadores de posição de $PROJECT_NAME e $TOPIC_ID pelos identificadores reais do projeto e do tópico.

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 melhor visualização, especialmente para métricas diárias, considere o seguinte:

  • Veja os seus dados durante um período mais longo para fornecer mais contexto para as tendências diárias.

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

O que se segue?