Descripción general de la supervisión

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

Visualiza métricas

Ve a Stackdriver en Google Cloud Console para ver los paneles de supervisión de Stackdriver o definir las alertas de Stackdriver. También puedes usar la API de Stackdriver Monitoring para consultar y ver las métricas de las suscripciones y los temas.

Tipos de métricas y recursos

Supervisa el uso de cuotas de temas o suscripciones

Puedes usar el panel de cuotas de API y servicios para supervisar el uso actual de un tema o una suscripción determinados.

Esas métricas son las siguientes:

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

Ten en cuenta que estas métricas están en bytes, mientras que las cuotas se miden en kilobytes.

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 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:

  • De extracción: subscription/pull_ack_message_operation_count filtrado por response_code != "success"

  • De extracción de transmisión: subscription/streaming_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 toma 100 segundos procesar cada mensaje, es probable que el límite de la capacidad de procesamiento sea de 10 mensajes por segundo.

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 Stackdriver Logging, puedes configurar una métrica basada en registros con una alerta.