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

Garantir que você não fique sem cota

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

É possível ver o histórico de uso da cota usando as seguintes métricas:

  • serviceruntime.googleapis.com/quota/rate/net_usage
  • serviceruntime.googleapis.com/quota/limit

Elas 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 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ê seu uso além dos limites de cota padrão, crie políticas de alertas para todas as cotas relevantes. Esses alertas são disparados quando o uso atinge uma fração do limite. Por exemplo, a seguinte consulta na Linguagem de consulta do Monitoring acionará sua política de alerta quando qualquer cota de 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 ter um monitoramento e um alerta mais personalizados sobre métricas de cotas, consulte Como usar métricas de cota.

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

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.

Para acessar limites maiores de mensagens pendentes, os assinantes de push precisam confirmar mais de 99% das mensagens recebidas.

Calcule a fração de mensagens que os assinantes reconhecem usando a linguagem de consulta do Monitoring. A seguinte consulta MQL 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

Como monitorar assinaturas com filtros

O Pub/Sub reconhece automaticamente as mensagens que não correspondem ao filtro. É possível monitorar o número, o tamanho e o custo dessas mensagens.

Para monitorar o número de mensagens que não correspondem a um filtro, use a métrica subscription/ack_message_count com o rótulo delivery_type e o valor filter.

Para monitorar o tamanho e o custo das mensagens que não correspondem a um filtro, use a métrica subscription/byte_cost com o rótulo operation_type e o valor filter_drop. Para mais informações sobre as taxas dessas mensagens, consulte a página de preços do Pub/Sub.

Como monitorar mensagens não entregues encaminhadas

Para monitorar as mensagens que não podem ser entregues que o Pub/Sub encaminha para um tópico de mensagens mortas, use a métrica subscription/dead_letter_message_count. A métrica subscription/dead_letter_message_count contabiliza 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 métrica topic/send_message_operation_count do tópico para o qual o Pub/Sub encaminha essas mensagens.

Também é possível anexar uma assinatura ao tópico de mensagens mortas e monitorar as mensagens não entregues usando as seguintes métricas:

  • subscription/num_undelivered_messages: o número de mensagens que os inscritos não processaram.

  • subscription/oldest_unacked_message_age: quanto tempo antes da próxima mensagem 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.