Visão geral do Monitoring

A API Pub/Sub exporta métricas por meio do Cloud Monitoring. O Cloud Monitoring permite criar painéis de monitoramento e políticas de alertas ou acessar as métricas de maneira programática.

Como ver métricas

Para ver os painéis do Cloud Monitoring ou definir políticas de alertas, acesse Monitoramento no Console do Google Cloud:

Acessar Monitoring

Também é possível usar a API Cloud Monitoring para consultar e visualizar métricas de assinaturas e tópicos.

Tipos de métricas e recursos

Monitorar o uso da cota de tópico ou assinatura

O painel de cotas de APIs e serviços pode ser usado para monitorar o uso atual de um determinado tópico ou assinatura.

Essas métricas são:

  • pubsub.googleapis.com/topic/byte_cost
  • pubsub.googleapis.com/subscription/byte_cost

Essas métricas estão em bytes. Já a cota é medida em kilobytes.

Como manter os assinantes íntegros

Como monitorar o backlog

Para garantir que os assinantes estejam acompanhando o fluxo de mensagens, crie um painel que mostre as métricas a seguir, agregadas por recurso, para todas as assinaturas:

  • subscription/num_undelivered_messages
  • subscription/oldest_unacked_message_age

Crie políticas de alerta que serão disparadas quando esses valores forem muito grandes no contexto do sistema. Por exemplo, o número absoluto de mensagens não entregues 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.

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 um pequeno número de 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 consegue processar todas as mensagens.
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 bem antes de a duração da retenção de mensagens da assinatura expirar.

Como monitorar a expiração do prazo de confirmação

Para reduzir a latência de ponta a ponta na entrega de mensagens, o Pub/Sub permite que os assinantes reservem um tempo limitado para confirmar uma determinada mensagem (chamado de o "prazo de confirmação") antes de entregar novamente a mensagem. Caso seus assinantes demorem demais para reconhecer as mensagens, elas serão entregues novamente, fazendo com que os assinantes vejam mensagens duplicadas. Isso pode acontecer por uma série de 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 Google 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.

Pode ser útil medir a taxa de perda do prazo de confirmação dos assinantes. A métrica específica depende do tipo de assinatura:

  • Pull e StreamingPull: subscription/pull_ack_message_operation_count filtrado por response_code != "success"

  • Push: subscription/push_request_count filtrado por response_code != "success"

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.

Como 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 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 em caso de altas taxas de erro (criar uma métrica filtrada por classe de resposta), porque essas taxas fazem com que a entrega seja mais lenta e causam um aumento do backlog. 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. Como regra, o serviço ajusta o limite de acordo com a capacidade geral da assinatura em incrementos de 1.000 depois que capacidade alcançar uma taxa na ordem de 10.000 mensagens por segundo. Não há nenhuma garantia específica além do valor máximo, então 1.000 é 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.

Como monitorar tópicos de mensagens inativas

Para monitorar mensagens encaminhadas a tópicos de mensagens inativas, use a métrica subscription/dead_letter_message_count da assinatura com o tópico de mensagens inativas.

Para verificar se as mensagens encaminhadas foram recebidas, compare subscription/dead_letter_message_count com a métrica topic/send_message_operation_count do tópico de mensagens inativas.

Também é possível monitorar mensagens encaminhadas que foram recebidas por tópicos de mensagens inativas usando métricas de uma assinatura para esse tópico:

  • subscription/num_undelivered_messages

    Se uma assinatura só receber as mensagens encaminhadas para um tópico de mensagens inativas, essa métrica calculará o número de mensagens encaminhadas que não são processadas por um aplicativo do assinante.

  • subscription/oldest_unacked_message_age

    Se uma assinatura receber apenas as mensagens encaminhadas para um tópico de mensagem inativa, essa métrica indicará se as mensagens encaminhadas para um tópico de mensagem inativa estão perto de expirar.

Como manter os editores íntegros

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 secundária de erros de repetição (significativamente menor que 1%) não é motivo de preocupação, porque a maioria das bibliotecas de cliente do Google Cloud repete as mensagens com falha. Você deve investigar 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 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 Google 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.