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 console do Google Cloud usando o Monitoring.
Se você quiser ver métricas de outros recursos do Google Cloud além das 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 práticas recomendadas sobre o uso de métricas no 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ê tenha ambos é concluir o Guia de início rápido sobre como usar o console do Cloud.
Visualizar um painel
Um painel permite visualizar e analisar dados de diferentes fontes no mesmo contexto. O Google Cloud oferece painéis predefinidos e personalizados. Por exemplo, é possível ver um painel predefinido do Pub/Sub ou criar um painel personalizado que exibe dados de métricas, políticas de alertas e entradas de registro relacionadas ao Pub/Sub.
Para monitorar seu projeto do Pub/Sub usando o Cloud Monitoring, siga estas etapas:
No Console do Google Cloud, acesse a página Monitoring.
Selecione o nome do seu projeto (se ele ainda não estiver selecionado) na parte superior da página.
Clique em Painéis no menu de navegação.
Na página Visão geral dos painéis, crie um novo painel ou selecione o painel atual do Pub/Sub.
Para pesquisar o painel Pub/Sub atual, no filtro Todos os painéis, selecione a propriedade Nome e insira
Pub/Sub
.
Para mais informações sobre como criar, editar e gerenciar um painel personalizado, consulte Gerenciar painéis personalizados.
ver uma única métrica do Pub/Sub
Para visualizar uma única métrica do Pub/Sub usando o console do Google Cloud, siga estas etapas:
No Console do Google Cloud, acesse a página Monitoring.
No painel de navegação, selecione Metrics Explorer.
Na seção Configuração, clique em Selecionar uma métrica.
No filtro, digite
Pub/Sub
.Em Recursos ativos, selecione Assinatura do Pub/Sub ou Tópico do Pub/Sub.
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
Para ver quais métricas o Pub/Sub informa ao Cloud Monitoring, consulte a lista de métricas do Pub/Sub na documentação do Cloud Monitoring.
Para ver os detalhes dos tipos de recursos monitorados
pubsub_topic
,pubsub_subscription
oupubsub_snapshot
, consulte Tipos de recursos monitorados na documentação do Cloud Monitoring.
Monitorar o uso de cotas
Em um determinado projeto, é possível usar o painel de cotas do IAM e administrador para visualizar 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 ver mais opções 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 alertas são acionados quando seu uso atinge uma fração do limite. Por exemplo, a consulta a seguir na linguagem de consulta do Monitoring aciona uma política de alertas quando uma cota do Pub/Sub excede 80% do 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 monitoramento e alertas mais personalizados sobre métricas de cota, consulte Como usar métricas de cota.
Consulte Cotas e limites para mais informações sobre cotas.
Mantenha uma assinatura íntegra
Para manter uma assinatura íntegra, é possível monitorar várias propriedades dela usando as métricas fornecidas pelo Pub/Sub. Por exemplo, é possível monitorar o volume de mensagens não confirmadas, a expiração dos prazos de confirmação de mensagens e assim por diante. Também é possível verificar se a assinatura é íntegra o suficiente para alcançar uma 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 estejam acompanhando o fluxo das mensagens, crie um painel. O painel pode mostrar as seguintes métricas de backlog, agregadas por recurso, de todas as assinaturas:
Mensagens não confirmadas (
subscription/num_undelivered_messages
) para ver o número de mensagens não confirmadas.Idade da mensagem não confirmada mais antiga (
subscription/oldest_unacked_message_age
) para consultar o tempo da mensagem não confirmada mais antiga no backlog da assinatura.Pontuação de integridade da latência de entrega (
subscription/delivery_latency_health_score
) para verificar a integridade geral da assinatura em relação à latência de entrega. Para mais informações sobre essa métrica, consulte a seção relevante deste documento.
Crie políticas de alertas que sejam acionadas quando esses valores estiverem fora do intervalo aceitável no contexto do sistema. Por exemplo, o número absoluto de mensagens não confirmadas não é necessariamente significativo. Um backlog de 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 que não acompanham o volume de mensagens |
|
Se houver um tamanho pequeno e estável de backlog combinado a um oldest_unacked_message_age
que cresce constantemente, algumas mensagens podem não ser processadas. |
Mensagens travadas |
|
O oldest_unacked_message_age excede a
duração da retenção de mensagens da assinatura. |
Perda permanente de dados |
|
Monitorar a integridade da latência de entrega
No Pub/Sub, a latência de entrega é o tempo que uma mensagem
publicada leva para ser entregue a um assinante.
Se o backlog da mensagem estiver aumentando, use a Pontuação de integridade
da latência de entrega (subscription/delivery_latency_health_score
) para verificar quais fatores estão contribuindo para o aumento da latência.
Essa métrica avalia a integridade de uma única assinatura em uma janela contínua de 10 minutos. A métrica fornece insights sobre os critérios a seguir, que são necessários para que uma assinatura tenha baixa latência 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 e consistente 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 íntegro e 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 é definida como 0. Procurar uma assinatura pode fazer com que mensagens antigas sejam reproduzidas muito depois da primeira publicação, aumentando a latência de entrega.
Mensagens de confirmação negativa (não confirmadas): se a assinatura tiver alguma solicitação de confirmação negativa (nack) nos últimos 10 minutos, a pontuação será definida como 0. Uma confirmação negativa faz com que uma mensagem seja reenviada com um aumento da latência de entrega.
Prazos de confirmação expirados: se a assinatura tiver prazos de confirmação vencidos nos últimos 10 minutos, a pontuação será definida como 0. As mensagens com o prazo de confirmação expirado são reenviadas com uma latência de entrega aumentada.
Latências de confirmação: se o 99,9o percentil de todas as latências de confirmação nos últimos 10 minutos for maior que 30 segundos, a pontuação será definida como 0. Uma alta latência de confirmação é um sinal de que um cliente assinante está demorando muito para processar uma mensagem. Essa pontuação pode implicar 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 0. 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 será definida como 0. Adicione mais capacidade ao endpoint de push para ter capacidade para novas mensagens.
Pull: se você não tiver solicitações de envio pendentes o suficiente, a pontuação será definida como 0. Abra mais solicitações de envio simultâneas para garantir que você esteja pronto para receber novas mensagens.
No Metrics Explorer, selecione a métrica Pontuação de integridade da latência de entrega para o tipo de recurso de assinatura do Pub/Sub. Adicione um filtro para selecionar apenas uma assinatura por vez. Selecione o Gráfico de área empilhada e aponte para um horário específico para verificar as pontuações de critérios da assinatura naquele momento.
Confira a seguir uma captura de tela da métrica representada para um período de uma hora usando um gráfico de áreas empilhadas. A pontuação de integridade combinada vai para 5 às 4h15, com uma 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.
A linguagem de consulta do Monitoring fornece uma interface expressiva e baseada em texto para dados de séries temporais do Cloud Monitoring. A consulta MQL a seguir 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 que os clientes assinantes tenham um período limitado para confirmar (confirmar) uma determinada mensagem. Esse período é conhecido como prazo de confirmação. Se os assinantes demorarem muito para confirmar as mensagens, elas serão reenviadas, fazendo com que os assinantes recebam mensagens duplicadas. Esse reenvio pode acontecer por vários 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. As bibliotecas de cliente do 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.
É possível 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/expired_ack_deadlines_count
Envio:
subscription/push_request_count
filtrado porresponse_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 de expiração pequena (por exemplo, de 0,1% a 1%) pode ser íntegra.
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. É possível monitorar a capacidade de processamento de mensagens em lote que está sendo processada pelos assinantes com estas métricas:
Pull:
subscription/pull_request_count
(essa métrica também pode incluir solicitações de envio retornadas sem mensagens)StreamingPull:
subscription/streaming_pull_response_count
É possível monitorar a capacidade de processamento de mensagens individual ou sem lote que está sendo processada 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
esubcription_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 para altas taxas de erro, porque elas levam a uma entrega lenta e a um backlog crescente. É possível criar uma métrica filtrada por classe de resposta. No entanto, as contagens de solicitações de push provavelmente serão mais úteis como uma ferramenta para investigar o tamanho e o tempo crescentes do backlog.
subscription/num_outstanding_messages
O Pub/Sub geralmente limita o número de mensagens pendentes. Tente usar menos de 1.000 mensagens pendentes na maioria das situações. Depois que a capacidade atinge uma taxa de cerca de 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. Nenhuma garantia específica é feita além do valor máximo. Portanto, 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 acessar limites mais altos de mensagens pendentes, 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 confirmará automaticamente as mensagens que não corresponderem ao 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 a métrica
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 a métrica subscription/byte_cost
com o rótulo operation_type
definido como filter_drop
. Para 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 mensagens não entregues que o Pub/Sub
encaminha para um tópico de mensagens inativas, use a
métrica
subscription/dead_letter_message_count
. 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 que não podem ser entregues, compare a métrica subscription/dead_letter_message_count
com a
métrica
topic/send_request_count
. Faça a comparação do tópico de mensagens inativas para o qual o Pub/Sub encaminha essas mensagens.
Também é possível anexar uma assinatura ao tópico de mensagens inativas e, em seguida, monitorar as mensagens não entregues encaminhadas nessa assinatura usando as seguintes métricas:
subscription/num_undelivered_messages
- o número de mensagens encaminhadas acumuladas na assinatura
subscription/oldest_unacked_message_age
- a idade da mensagem encaminhada mais antiga na assinatura
Mantenha um editor íntegro
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 de erro em segundo plano de erros que podem ser repetidos (menor que 1%) não é um motivo de preocupação, já que a maioria das bibliotecas de cliente do Cloud repete falhas de 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 saber como detectar falhas permanentes de publicação ao usar as bibliotecas de cliente do Cloud. 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. É possível monitorar a capacidade de processamento de mensagens enviada pelos editores com estas métricas:
topic/send_request_count
: o volume de mensagens em lote que são enviadas pelos editores.Uma contagem de
topic/message_sizes
: o volume de mensagens individuais (não em lote) enviadas pelos editores.É possível calcular uma contagem de mensagens enviadas aplicando um agregador de contagem 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 individuais 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
Para criar um alerta para uma métrica específica, consulte Como gerenciar políticas de alertas com base em métricas.
Para saber mais sobre como usar o MQL para criar gráficos de monitoramento, consulte Como usar o Editor de consultas.
Para saber mais sobre os recursos da API Monitoring, como métricas, recursos monitorados, grupos de recursos monitorados e políticas de alertas, consulte Recursos da API.