Resumen de la supervisión

La API de Pub/Sub exporta métricas a través de Cloud Monitoring. Cloud Monitoring te permite crear paneles y políticas de alertas de supervisión o acceder a las métricas de manera programática.

Cómo ver métricas

Para ver los paneles de Cloud Monitoring o definir las políticas de alertas, ve a Monitoring en Google Cloud Console:

Ir a Monitoring

También puedes usar la API de Cloud Monitoring para consultar y ver las métricas de las suscripciones y los temas.

Tipos de recursos y métricas

Asegúrate de no agotar tu cuota

Para un proyecto determinado, puedes usar el panel de cuotas de IAM y administración a fin de ver el uso y las cuotas actuales.

Puedes ver el historial de uso de cuota con las siguientes métricas:

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

Estas métricas usan el tipo de recurso supervisado consumer_quota. Para obtener más métricas relacionadas con las cuotas, consulta la Lista de métricas.

Por ejemplo, la siguiente consulta en el lenguaje de consultas de Monitoring crea un gráfico con la fracción de la cuota de publicadores que se usa en cada región:

  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

Si prevés que tu uso excederá los límites de cuota predeterminados, crea políticas de alertas para todas las cuotas relevantes. Estas alertas deben activarse cuando tu uso alcance alguna parte del límite. Por ejemplo, la siguiente consulta del lenguaje de consulta de Monitoring activará tu política de alertas cuando cualquier cuota de Pub/Sub supere el uso del 80%:

  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')

Si deseas obtener una supervisión más personalizada de las métricas de cuota y las alertas sobre ellas, consulta Usa métricas de cuota.

Consulta Cuotas y límites para obtener más información sobre las cuotas.

Mantén a los suscriptores en buen estado

Supervisa las tareas pendientes

Para asegurarte de que los suscriptores le sigan el paso al flujo de mensajes, crea un panel que muestre las siguientes métricas (agregadas por recurso) para todas tus suscripciones:

  • subscription/num_undelivered_messages
  • subscription/oldest_unacked_message_age

Crea políticas de alertas que se activen cuando estos valores sean inusualmente grandes en el contexto de tu sistema. Por ejemplo, la cantidad total de mensajes no entregados no siempre es significativa. Una acumulación de un millón de mensajes puede ser aceptable en el caso de una suscripción de un millón de mensajes por segundo, pero inaceptable en el caso de una suscripción de un mensaje por segundo.

Síntomas Problema Soluciones
oldest_unacked_message_age y num_undelivered_messages están creciendo en conjunto. Los suscriptores no le siguen el paso al volumen de mensajes.
  • Agrega más subprocesos o procesos de suscriptor.
  • Agrega más máquinas o contenedores de suscriptor.
  • En tu código, busca indicios de errores que impidan procesar los mensajes o confirmar su recepción con puntualidad (consulta la sección sobre cómo supervisar el vencimiento del plazo de confirmación).
Si se combina una cantidad pequeña y constante de tareas pendientes con una oldest_unacked_message_age en constante aumento, es posible que haya una cantidad reducida de mensajes que no se puedan procesar. Los mensajes están atascados. Examina los registros de tu aplicación para descubrir si hay mensajes que estén haciendo que el código falle. Es poco probable pero posible que los mensajes problemáticos estén atascados en Pub/Sub y no en tu cliente. Inicia un caso de ayuda una vez que estés seguro de que tu código procesa con éxito cada mensaje.
La oldest_unacked_message_age excede la duración de retención de mensajes de la suscripción. Existe una pérdida permanente de datos. Configura una alerta que se active mucho antes de que venza la duración de retención de mensajes de la suscripción.

Supervisa el vencimiento del plazo de confirmación

Para reducir la latencia de extremo a extremo de la entrega de mensajes, Pub/Sub ofrece a los clientes suscriptores un tiempo limitado para confirmar la recepción de un mensaje determinado (conocido como “plazo de confirmación”) antes de volver a entregar el mensaje. Si los suscriptores tardan demasiado en confirmar la recepción de los mensajes, estos se volverán a entregar, lo que hará que los suscriptores vean mensajes duplicados. Esto puede suceder por varias razones:

  • Tus suscriptores no cuentan con el aprovisionamiento suficiente (necesitas más subprocesos o máquinas).

  • Toma más tiempo el procesamiento de cada mensaje que la duración del plazo de confirmación de mensajes. Por lo general, las bibliotecas cliente de Google Cloud extienden el plazo para mensajes individuales hasta el máximo configurable. Sin embargo, un plazo de extensión máxima también está vigente para las bibliotecas.

  • Algunos mensajes generan fallas en el cliente todo el tiempo.

Puede resultar útil medir la frecuencia con la que los suscriptores no cumplen el plazo de confirmación. La métrica específica depende del tipo de suscripción:

  • Extracción y StreamingPull: subscription/pull_ack_message_operation_count filtrado por response_code != "success"

  • De envío: subscription/push_request_count filtrado por response_code != "success"

Si la frecuencia con la que no se cumplen los plazos de confirmación es demasiado alta, se pueden generar ineficiencias costosas en tu sistema. Se te cobra por cada entrega nueva y por intento de procesar cada mensaje repetidas veces. Por el contrario, una frecuencia de vencimiento baja (por ejemplo, 0.1-1%) puede ser buena.

Supervisa las suscripciones de envío

Para las suscripciones de envío, también debes supervisar estas métricas:

  • subscription/push_request_count

    Agrupa la métrica de acuerdo con response_code y subcription_id. Dado que las suscripciones de envío de Pub/Sub usan los códigos de respuesta como confirmaciones de recepción de mensajes implícitas, es importante supervisar los códigos de respuesta de las solicitudes de envío. Debido a que las suscripciones de envío se interrumpen de manera exponencial cuando se les presentan tiempos de espera o errores, tu conjunto de tareas pendientes puede crecer con rapidez en función de cómo responde tu extremo.

    Considera configurar una alerta para las tasas de error altas (crea una métrica filtrada por clase de respuesta), ya que esas tasas generan una entrega más lenta y una acumulación de tareas pendientes. Sin embargo, es probable que los recuentos de solicitudes de envío sean más útiles como herramientas para investigar el tamaño y la antigüedad de la acumulación de tareas pendientes.

  • subscription/num_outstanding_messages

    Por lo general, Pub/Sub limita la cantidad de mensajes pendientes. Tu objetivo debería ser menos de 1,000 mensajes pendientes en la mayoría de las situaciones. Como regla general, el servicio ajusta el límite en incrementos de 1,000 en función de la capacidad de procesamiento general de la suscripción, una vez que esta capacidad alcanza una tasa de diez mil mensajes por segundo. No se brindan garantías específicas más allá del valor máximo, por lo que 1,000 es un buen parámetro.

  • subscription/push_request_latencies

    Esta métrica te ayuda a comprender la distribución de la latencia de respuesta de tu extremo de envío. Debido al límite en la cantidad de mensajes pendientes, la latencia del extremo afecta la capacidad de procesamiento de la suscripción. Si se necesitan 100 milisegundos para procesar cada mensaje, tu límite de capacidad de procesamiento es de 10 mensajes por segundo.

Para acceder a los límites de mensajes pendientes más altos, los suscriptores de envío deben confirmar más del 99% de los mensajes que reciben.

Puedes calcular la fracción de los mensajes que los suscriptores reconocen mediante el lenguaje de consultas de Monitoring. La siguiente consulta MQL crea un gráfico con la fracción de los mensajes que los suscriptores reconocen sobre una suscripción:

  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

Supervisa las suscripciones con filtros

Pub/Sub confirma automáticamente los mensajes que no coinciden con el filtro. Puedes supervisar la cantidad, el tamaño y el costo de estos mensajes.

Para supervisar la cantidad de mensajes que no coinciden con un filtro, usa la métrica subscription/ack_message_count con la etiqueta delivery_type y el valor filter.

Para supervisar el tamaño y el costo de los mensajes que no coinciden con un filtro, usa la métrica subscription/byte_cost con la etiqueta operation_type y el valor filter_drop. Para obtener más información sobre las tarifas de estos mensajes, consulta la página de precios de Pub/Sub.

Supervisa mensajes reenviados que no se pueden entregar

Para supervisar los mensajes que no se pueden entregar que Pub/Sub reenvía a un tema de mensajes no entregados, usa la métrica subscription/dead_letter_message_count. La métrica subscription/dead_letter_message_count cuenta la cantidad de mensajes que no se pueden entregar que Pub/Sub reenvía desde una suscripción.

Para verificar que Pub/Sub reenvíe mensajes que no se pueden entregar, puedes comparar la métrica subscription/dead_letter_message_count con la métrica topic/send_message_operation_count del tema al que Pub/Sub reenvía estos mensajes.

También puedes adjuntar una suscripción al tema de mensajes no entregados y, luego, supervisar los mensajes reenviados que no se pueden entregar mediante las siguientes métricas:

  • subscription/num_undelivered_messages: la cantidad de mensajes que los suscriptores no procesaron

  • subscription/oldest_unacked_message_age: la cantidad de tiempo que transcurre antes de que caduque el siguiente mensaje

Mantén a los publicadores en buen estado

El objetivo principal de un publicador es conservar los datos de los mensajes con rapidez. Supervisa este rendimiento mediante topic/send_request_count, agrupado según response_code. Esta métrica te indica si Pub/Sub está en buen estado y si acepta solicitudes.

Una tasa secundaria de errores que permiten reintentar la operación (bastante inferior al 1%) no debería ser motivo de preocupación, ya que la mayoría de las bibliotecas cliente de Google Cloud reintentan las operaciones que generaron errores en los mensajes. Debes investigar las tasas de error superiores al 1%. Como tu aplicación administra los códigos que no se pueden reintentar (en lugar de la biblioteca cliente), debes examinar los códigos de respuesta. Si tu aplicación de publicador no cuenta con una forma adecuada de indicar si un publicador está en mal estado, considera establecer una alerta en la métrica send_request_count.

Es igual de importante realizar un seguimiento de las solicitudes de publicación con errores en tu cliente de publicación. Si bien, por lo general, las bibliotecas cliente vuelven a intentar realizar las solicitudes con errores, no garantizan su publicación. Consulta la sección sobre cómo publicar mensajes para conocer las formas de detectar errores de publicación permanentes que se generan cuando usas las bibliotecas cliente de Google Cloud. Como mínimo, tu aplicación de publicador debe registrar errores de publicación permanentes. Si registras esos errores en Cloud Logging, puedes configurar una métrica basada en registros con una política de alertas.