Visão geral do Monitoring

O Cloud Pub/Sub exporta métricas por meio do Stackdriver. O Stackdriver permite criar painéis e alertas de monitoramento ou acessar as métricas programaticamente.

Como ver métricas

Acesse o Stackdriver no Console do Google Cloud para ver os painéis de monitoramento do Stackdriver ou para definir os alertas do Stackdriver. Você também pode usar a API Stackdriver Monitoring para consultar e ver as métricas de assinaturas e tópicos.

Métricas e tipos de 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 alertas que serão disparados quando esses valores forem grandes demais no contexto do seu 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: subscription/pull_ack_message_operation_count filtrado por response_code != "success"

  • Pull de streaming: subscription/streaming_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 segundos para processar cada mensagem, a capacidade limite provavelmente será de 10 mensagens por segundo.

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ê registra esses erros no Stackdriver Logging, pode configurar uma métrica com base em registros com um alerta.