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 no console do Google Cloud usando o Monitoring.

  • Se você quiser conferir métricas de outros recursos do Google Cloud, 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 conhecer as práticas recomendadas sobre o uso de métricas nos seus 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 o faturamento ativado

Uma maneira de garantir que você obteve ambos é concluir o Guia de início rápido sobre como usar o console do Cloud.

Visualizar um painel

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

Para monitorar seu projeto do Pub/Sub usando o Cloud Monitoring, faça o seguinte: 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 atual do Pub/Sub.

    Para pesquisar o painel atual do Pub/Sub, use o filtro Todos os painéis, selecione a propriedade Nome e insira Pub/Sub.

Para mais informações sobre como criar, editar e gerenciar uma 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 no 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. Selecione 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.

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

Monitorar o uso de cotas

Para um determinado projeto, é possível usar a IAM e Painel de cotas do administrador as cotas e o uso atuais.

Você pode visualizar o histórico de uso da cota com 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 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 os alertas são acionados quando o uso atinge uma fração do limite. Para exemplo, a consulta a seguir em linguagem de consulta do Monitoring aciona uma política de alertas quando qualquer cota do Pub/Sub exceder 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 mais informações personalizadas de monitoramento e alerta sobre métricas de cota, acesse Como usar métricas de cota.

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

Mantenha uma assinatura íntegra

Para manter a integridade das assinaturas, você pode monitorar vários usando as métricas fornecidas pelo Pub/Sub. Por exemplo, é possível monitorar o volume de mensagens não confirmadas, a expiração de mensagens prazos de confirmação e assim por diante. Você também pode verificar se a assinatura está íntegra o suficiente baixa latência de entrega de mensagens.

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

Monitorar o backlog das mensagens

Para garantir que os assinantes acompanhem o fluxo das mensagens, crie em um painel. O painel pode mostrar as seguintes métricas de backlog, agregadas por para todas as suas assinaturas:

Crie políticas de alertas que sejam acionadas quando esses valores estiverem fora do em um intervalo aceitável no contexto do sistema. Por exemplo, o valor absoluto número de mensagens não confirmadas não é necessariamente significativo. Uma lista de pendências um milhão de mensagens pode ser aceitável para 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. 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 o impeçam de usá-lo confirmar as mensagens ou processá-las em tempo hábil. Consulte Como monitorar a expiração do prazo de confirmação.
Se houver um backlog pequeno e estável combinado com um está crescendo oldest_unacked_message_age, talvez algumas mensagens não possam 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 ofensivas ficam presas no Pub/Sub e não no seu cliente. Faça uma caso de suporte depois que você tiver certeza seu código processa cada mensagem com sucesso.
  • Se algumas mensagens estiverem causando falhas no código, encaminhe essas mensagens tópico de mensagens inativas.
O oldest_unacked_message_age excede a assinatura duração da retenção da mensagem. Perda permanente de dados
  • Configurar um alerta que é acionado antes do fim da mensagem duração da retenção.

Monitorar a integridade da latência de entrega

No Pub/Sub, a latência de entrega é o tempo que leva para a ser entregue a um assinante. Se o backlog das mensagens estiver aumentando, use o artigo Integridade da latência de entrega score (subscription/delivery_latency_health_score) para verificar quais fatores contribuem para o aumento da latência.

Essa métrica avalia a integridade de uma única assinatura em um janela de 10 minutos. A métrica fornece informações sobre os seguintes critérios: que são necessários para uma assinatura alcançar uma latência baixa consistente:

  • Solicitações de busca insignificantes.

  • Mensagens confirmadas negativamente (não recebidas).

  • Prazos insignificantes de confirmação de mensagem expirado.

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

  • Baixa utilização consistente, o que significa que a assinatura tem capacidade adequada para 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 saudável 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 será definida como 0. Procurando uma assinatura pode fazer com que as mensagens antigas sejam reproduzidas muito depois de serem publicado, o que aumenta a latência de entrega.

  • Mensagens confirmadas negativamente (não recebidas): se a assinatura teve algum solicitações de confirmação negativa (nack) nos últimos 10 minutos, a pontuação será definido como 0. Uma confirmação negativa faz com que a mensagem seja reenviados com aumento da latência de entrega.

  • Prazos de confirmação expirados: se a assinatura tiver expirado de confirmação nos últimos 10 minutos, a pontuação será definida como 0. Mensagens com prazo de confirmação vencido são reenviadas com um latência de entrega.

  • Latências de confirmação: se o 99,9o percentil de toda a confirmação latências nos últimos 10 minutos foi maior do que 30 segundos, a pontuação é definido como 0. Uma alta latência de confirmação é um sinal de que o cliente assinante está demorando muito para processar uma mensagem. Esta 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 streams suficientes abertos, a pontuação será definida como zero. Abra mais streams para garantir que você tenha a capacidade adequada para novas mensagens.

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

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

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

Veja a seguir uma captura de tela da métrica representada para um período de uma hora usando um gráfico de área empilhada. A pontuação de integridade combinada vai para 5 às 4h15, com um 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 mostrando a métrica de latência de entrega

A linguagem de consulta de monitoramento oferece uma interface expressiva e baseada em texto para dados de séries temporais do Cloud Monitoring. A seguinte consulta MQL 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 aos clientes assinantes um tempo limitado para confirmar (confirmar) um determinado mensagem. Esse período é conhecido como prazo de confirmação. Se seus assinantes seguirem muito tempo para reconhecer mensagens, elas são reenviadas, o que as mensagens duplicadas. Esse reenvio pode ocorrer por vários motivos:

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

  • O processamento de cada mensagem leva mais tempo do que a confirmação da mensagem prazo. As bibliotecas de cliente do Cloud geralmente estendem 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 de expiração pequena (por exemplo, 0,1% a 1%) podem ser saudáveis.

Monitore a capacidade de processamento das mensagens

Os assinantes de Pull e StreamingPull podem receber lotes de mensagens em cada resposta de pull; as assinaturas de push recebem uma única mensagem em cada solicitação de push. Você pode 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 individual ou sem lote que está sendo processados 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 como confirmações implícitas de mensagens, é importante e monitorar 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, uma vez que essas taxas levam a entrega lenta 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 quanto uma ferramenta para investigar o tamanho e o tempo de backlog crescentes.

  • subscription/num_outstanding_messages

    O Pub/Sub geralmente limita o número de mensagens pendentes. Tente enviar menos de mil mensagens pendentes em na maioria das situações. Depois que a capacidade atingir uma taxa da ordem 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 garantias específicas são feitas além do valor máximo, de modo que 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 ter acesso a limites maiores de mensagens pendentes, faça o seguinte: 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

Se você configurar um filtro em uma assinatura, o Pub/Sub reconhece automaticamente as mensagens que não correspondem o filtro. É possível monitorar essa confirmação automática.

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

Para monitorar a taxa de mensagens confirmadas automaticamente que não correspondem ao filtro, use o subscription/ack_message_count com o rótulo delivery_type definido como filter.

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

Monitorar mensagens encaminhadas que não podem ser entregues

Para monitorar as mensagens não entregues que o Pub/Sub encaminha para um tópico de mensagens inativas, use o subscription/dead_letter_message_count métrica. 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, podemos comparar a métrica subscription/dead_letter_message_count topic/send_request_count métrica. Faça a comparação do tópico de mensagens inativas com que O Pub/Sub encaminha essas mensagens.

Você também pode anexar uma assinatura ao tópico de mensagens inativas e, em seguida, monitorar os encaminhou mensagens que não podem ser entregues nesta assinatura usando as seguintes métricas:

Mantenha um editor íntegro

O principal objetivo de um editor é manter a rapidez dos dados de mensagens. Monitorar o 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 Isso é motivo de preocupação, já que a maioria das bibliotecas de cliente do Cloud e falha em 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 monitorar 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 maneiras de detectar falhas permanentes de publicação ao usar o Cloud Client Bibliotecas. 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.

Monitore a capacidade de processamento das mensagens

Os editores podem enviar mensagens em lotes. Você pode monitorar a capacidade de processamento das mensagens enviadas pelos editores com essas métricas:

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

  • Um contagem de topic/message_sizes: o volume de mensagens individuais (sem lote) enviadas pelos editores.

    Você pode calcular o número de mensagens enviadas aplicando uma contagem agregador a essa métrica ou usando a Linguagem de consulta do Monitoring. A consulta MQL a seguir cria um gráfico com a taxa de mensagens 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