Supervisa Pub/Sub en Cloud Monitoring

Puedes usar la consola de Google Cloud o la API de Cloud Monitoring para supervisar Pub/Sub.

En este documento, se muestra cómo supervisar el uso de Pub/Sub en la console de Google Cloud con Monitoring.

  • Si deseas ver métricas de otros recursos de Google Cloud, además de las métricas de Pub/Sub, usa Monitoring.

  • De lo contrario, puedes usar los paneles de supervisión proporcionados en Pub/Sub. Consulta Supervisa temas y Supervisa suscripciones.

Para obtener prácticas recomendadas sobre el uso de métricas en el ajuste de escala automático, consulta Prácticas recomendadas para usar las métricas de Pub/Sub como indicadores de escalamiento.

Antes de comenzar

Antes de usar Monitoring, asegúrate de tener lo siguiente:

  • Una cuenta de Facturación de Cloud

  • Un proyecto de Pub/Sub con la facturación habilitada

Una forma de asegurarte de tener ambos elementos es completar la guía de inicio rápido con la consola de Cloud.

Cómo ver un panel existente

Un panel te permite ver y analizar datos de diferentes fuentes en el mismo contexto. Google Cloud proporciona paneles predefinidos y personalizados. Por ejemplo, puedes ver un panel predefinido de Pub/Sub o crear un panel personalizado que muestre datos de métricas, políticas de alertas y entradas de registro relacionadas con Pub/Sub.

Para supervisar tu proyecto de Pub/Sub con Cloud Monitoring, sigue estos pasos:

  1. En la consola de Google Cloud, ve a la página Monitoring.

    Ir a Monitoring

  2. Selecciona el nombre de tu proyecto si aún no está seleccionado en la parte superior de la página.

  3. En el menú de navegación, haz clic en Paneles.

  4. En la página Descripción general de los paneles, crea un panel nuevo o selecciona el panel existente de Pub/Sub.

    Para buscar el panel existente de Pub/Sub, en el filtro de Todos los paneles, selecciona la propiedad Nombre y, luego, ingresa Pub/Sub.

Para obtener más información sobre cómo crear, editar y administrar un panel personalizado, consulta Administra paneles personalizados.

Cómo ver una sola métrica de Pub/Sub

Para ver una sola métrica de Pub/Sub con la consola de Google Cloud, sigue estos pasos:

  1. En la consola de Google Cloud, ve a la página Monitoring.

    Ir a Monitoring

  2. En el panel de navegación, selecciona el Explorador de métricas.

  3. En la sección Configuración, haz clic en Seleccionar una métrica.

  4. En el filtro, ingresa Pub/Sub.

  5. En Recursos activos, selecciona Suscripción a Pub/Sub o Tema de Pub/Sub.

  6. Desglosa una métrica específica y haz clic en Aplicar.

    Se abrirá la página de una métrica específica.

Para obtener más información sobre el panel de supervisión, lee la documentación de Cloud Monitoring.

Cómo ver las métricas y los tipos de recursos de Pub/Sub

Accede al editor de MQL

El Explorador de métricas es una interfaz de Cloud Monitoring diseñada para explorar y visualizar los datos de tus métricas. En el Explorador de métricas, puedes usar el Lenguaje de consulta de Monitoring(MQL) para consultar y analizar tus métricas de Pub/Sub.

Para acceder al editor de MQL cuando usas el Explorador de métricas, consulta Cómo acceder al editor de código.

Compila tu consulta de MQL

Estas son algunas reglas básicas para crear una consulta de MQL para las métricas de Pub/Sub.

  1. Comienza con fetch pubsub_topic o fetch pubsub_subscription. Esta línea de código le indica al editor qué tipo de recurso de Pub/Sub deseas consultar, como temas o suscripciones.

  2. Selecciona tu métrica. Usa | metric 'metric_name' para especificar la métrica que deseas analizar. Un ejemplo de métrica de Pub/Sub es pubsub.googleapis.com/subscription/ack_message_count (para mensajes confirmados).

  3. Usa | filter para acotar tus datos. Entre los filtros comunes, se incluyen los siguientes:

    • resource.project_id == 'your-project-id'
    • resource.topic_id == 'your-topic-id'
    • resource.subscription_id == 'your-subscription-id'

  4. Usa | align y | group_by para agregar tus datos en intervalos y agrupaciones significativos.

  5. Define mejor tus datos con otras cláusulas. MQL ofrece varias otras cláusulas, como | every (para establecer la frecuencia de ejecución de consultas), | within (para especificar un intervalo de tiempo) y mucho más.

Este es un ejemplo de consulta para supervisar el recuento por hora de los mensajes enviados a una suscripción específica:

fetch pubsub_subscription
| metric 'pubsub.googleapis.com/subscription/sent_message_count'
| filter resource.project_id == 'your-project-id'
&& resource.subscription_id == 'your-subscription-id'
| align delta(1h)
| every 1h
| group_by [], [value_sent_message_count_aggregate: aggregate(value.sent_message_count)]

Supervisa el uso de la cuota

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

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

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 MQL 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 se activan cuando tu uso alcanza alguna parte del límite. Por ejemplo, la siguiente consulta del lenguaje de consulta de Monitoring activa una política de alertas cuando cualquier cuota de Pub/Sub supera 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 una suscripción saludable

Para mantener una suscripción en buen estado, puedes supervisar varias propiedades de suscripción con las métricas que proporciona Pub/Sub. Por ejemplo, puedes supervisar el volumen de mensajes no confirmados, el vencimiento de las fechas límite de confirmación de mensajes, etcétera. También puedes verificar si tu suscripción está en buen estado para lograr una latencia de entrega de mensajes baja.

Consulta las siguientes secciones para obtener más detalles sobre las métricas específicas.

Supervisa el retraso de los mensajes

Para asegurarte de que los suscriptores le sigan el paso al flujo de mensajes, crea un panel. El panel puede mostrar las siguientes métricas de lista de tareas pendientes, agregadas por recurso, para todas tus suscripciones:

Crea políticas de alertas que se activen cuando estos valores estén fuera del rango aceptable en el contexto de tu sistema. Por ejemplo, la cantidad absoluta de mensajes no confirmados 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.

Problemas comunes del backlog

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 Supervisa 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 algunos 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 ofensivos estén atascados en Pub/Sub y no en tu cliente. Inicia un caso de asistencia una vez que estés seguro de que tu código procesa con éxito cada mensaje.
  • Si algunos mensajes hacen que el código falle, considera reenviar esos mensajes a un tema de mensajes no entregados.
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 antes de que venza la duración de retención de mensajes.

Supervisa el estado de la latencia de entrega

En Pub/Sub, la latencia de entrega es el tiempo que tarda un mensaje publicado en entregarse a un suscriptor. Si aumenta tu lista de tareas pendientes de mensajes, puedes usar la puntuación de estado de la latencia de entrega (subscription/delivery_latency_health_score) para verificar qué factores contribuyen a un aumento de la latencia.

Esta métrica mide el estado de una sola suscripción durante un período continuo de 10 minutos. La métrica proporciona estadísticas sobre los siguientes criterios, que son necesarios para que una suscripción logre una latencia baja y coherente:

  • Solicitudes de salto despreciables

  • Mensajes de confirmación negativa (nacked) despreciables

  • Plazo de confirmación de mensajes vencidos insignificante

  • Latencia de confirmación coherente inferior a 30 segundos

  • Utilización baja y constante, lo que significa que la suscripción tiene una capacidad adecuada para procesar mensajes nuevos de forma coherente.

La métrica Puntuación del estado de la latencia de entrega informa una puntuación de 0 o 1 para cada uno de los criterios especificados. Una puntuación de 1 indica un buen estado y una puntuación de 0 indica un mal estado.

  • Solicitudes de salto: Si la suscripción tuvo solicitudes de salto en los últimos 10 minutos, la puntuación se establece en 0. Buscar una suscripción puede hacer que se vuelvan a reproducir mensajes antiguos mucho después de que se publicaron por primera vez, lo que aumenta la latencia de entrega.

  • Mensajes con confirmación negativa (nack): Si la suscripción tuvo solicitudes de confirmación negativa (nack) en los últimos 10 minutos, la puntuación se establece en 0. Una confirmación de recepción negativa hace que un mensaje se vuelva a entregar con una latencia de entrega mayor.

  • Plazos de confirmación vencidos: Si la suscripción tuvo plazos de confirmación vencidos en los últimos 10 minutos, la puntuación se establece en 0. Los mensajes cuyos plazos de confirmación vencieron se vuelven a entregar con una latencia de entrega mayor.

  • Latencias de acuse de recibo: Si el percentil 99.9 de todas las latencias de acuse de recibo durante los últimos 10 minutos fue superior a 30 segundos, la puntuación se establece en 0. Una latencia de confirmación alta es un indicador de que un cliente suscriptor está tardando un tiempo anormalmente largo en procesar un mensaje. Esta puntuación podría implicar un error o algunas restricciones de recursos del cliente del suscriptor.

  • Utilización baja: La utilización se calcula de forma diferente para cada tipo de suscripción.

    • StreamingPull: Si no tienes suficientes transmisiones abiertas, la puntuación se establece en 0. Abre más flujos para asegurarte de tener la capacidad adecuada para los mensajes nuevos.

    • Push: Si tienes demasiados mensajes pendientes en tu extremo de envío, la puntuación se establece en 0. Agrega más capacidad a tu extremo de notificaciones push para que tengas capacidad para mensajes nuevos.

    • Extracción: Si no tienes suficientes solicitudes de extracción pendientes, la puntuación se establece en 0. Abre más solicitudes de extracción simultáneas para asegurarte de estar listo para recibir mensajes nuevos.

Para ver la métrica, en Explorador de métricas, selecciona la métrica Calificación de estado de la latencia de entrega para el tipo de recurso de suscripción de Pub/Sub. Agrega un filtro para seleccionar solo una suscripción a la vez. Selecciona el gráfico de área estratificada y señala un momento específico para verificar las puntuaciones de los criterios de la suscripción en ese momento.

La siguiente es una captura de pantalla de la métrica representada para un período de una hora con un gráfico de áreas apiladas. La puntuación de estado combinada aumenta a 5 a las 4:15 a.m., con una puntuación de 1 para cada criterio. Más tarde, la puntuación combinada disminuye a 4 a las 4:20 a.m., cuando la puntuación de utilización disminuye a 0.

Captura de pantalla de la métrica de latencia de entrega

El lenguaje de consulta de Monitoring proporciona una interfaz expresiva basada en texto para los datos de series temporales de Cloud Monitoring. La siguiente consulta MQL crea un gráfico para medir la puntuación de estado de la latencia de entrega de una suscripción.

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

Supervisa el vencimiento del plazo de confirmación

Para reducir la latencia de entrega de mensajes, Pub/Sub ofrece a los clientes suscriptores un tiempo limitado para confirmar (confirmar) un mensaje determinado. Este período se conoce como fecha límite de acuse de recibo. 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. Esta reimpresión puede ocurrir por varios motivos:

  • 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 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.

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

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 la capacidad de procesamiento de mensajes

Los suscriptores de Pull y StreamingPull pueden recibir lotes de mensajes en cada respuesta de extracción. Las suscripciones de envío reciben un solo mensaje en cada solicitud de envío. Puedes supervisar la capacidad de procesamiento de mensajes por lotes que procesan tus suscriptores con estas métricas:

Puedes supervisar la capacidad de procesamiento de mensajes individuales o sin lotes que procesan tus suscriptores con la métrica subscription/sent_message_count filtrada por la etiqueta delivery_type.

La siguiente consulta de MQL te proporciona un gráfico de series temporales que muestra la cantidad total de mensajes enviados a una suscripción específica de Pub/Sub cada 10 minutos. Reemplaza los valores de marcador de posición para $PROJECT_NAME y $SUBSCRIPTION_NAME por los identificadores de proyecto y tema reales.

fetch pubsub_subscription
| metric 'pubsub.googleapis.com/subscription/sent_message_count'
| filter resource.project_id == '$PROJECT_NAME'
&& resource.subscription_id == '$SUBSCRIPTION_NAME'
| align delta(10m)
| every 10m
| group_by [],
[value_sent_message_count_aggregate: aggregate(value.sent_message_count)]

Supervisa las suscripciones de envío

Para las suscripciones de envío, supervisa estas métricas:

  • subscription/push_request_count

    Agrupa la métrica por 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, ya que estas tasas generan una entrega lenta y una acumulación de tareas pendientes. Puedes crear una métrica filtrada por clase de respuesta. 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. Después de que la capacidad de procesamiento alcanza una tasa de aproximadamente 10,000 mensajes por segundo, el servicio ajusta el límite de la cantidad de mensajes pendientes. Esta limitación se realiza en incrementos de 1,000. No se brindan garantías específicas más allá del valor máximo, por lo que 1,000 mensajes pendientes es un buen parámetro.

  • subscription/push_request_latencies

    Esta métrica te ayuda a comprender la distribución de la latencia de respuesta del 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

Si configuras un filtro en una suscripción, Pub/Sub confirma automáticamente los mensajes que no coinciden con el filtro. Puedes supervisar este acuse de recibo automático.

Las métricas del trabajo pendiente solo incluyen mensajes que coinciden con el filtro.

Para supervisar la tasa de mensajes confirmados automáticamente que no coinciden con el filtro, usa la métrica subscription/ack_message_count con la etiqueta delivery_type establecida en filter.

Para supervisar la capacidad de procesamiento y el costo de los mensajes confirmados automáticamente que no coinciden con el filtro, usa la métrica subscription/byte_cost con la etiqueta operation_type establecida en filter_drop. Para obtener más información sobre las tarifas de estos mensajes, consulta la página de precios de Pub/Sub.

Supervisa los 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. Esta métrica muestra 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_request_count. Realiza la comparación para el tema de mensajes no entregados 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 en esta suscripción mediante las siguientes métricas:

Mantén un publicador saludable

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 (inferior al 1%) no es motivo de preocupación, ya que la mayoría de las bibliotecas cliente de Cloud reintentan las operaciones que generaron errores en los mensajes. Investiga 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 topic/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 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.

Supervisa la capacidad de procesamiento de mensajes

Los publicadores pueden enviar mensajes en lotes. Puedes supervisar la capacidad de procesamiento de mensajes que envían tus publicadores con estas métricas:

Para obtener un recuento preciso de los mensajes publicados, usa la siguiente consulta de MQL. Esta consulta de MQL recupera de manera eficaz el recuento de mensajes individuales publicados en un tema de Pub/Sub específico dentro de intervalos de tiempo definidos. Reemplaza los valores de marcador de posición para $PROJECT_NAME y $TOPIC_ID por los identificadores de proyecto y tema reales.

fetch pubsub_topic
| metric 'pubsub.googleapis.com/topic/message_sizes'
| filter resource.project_id == '$PROJECT_NAME'
&& resource.topic_id == '$TOPIC_ID'
| align delta(60m)
| every 60m
| group_by [resource.topic_id],
[value_message_sizes_sum: count(value.message_sizes)]

Para obtener una mejor visualización, especialmente de las métricas diarias, considera lo siguiente:

  • Consulta tus datos durante un período más largo para proporcionar más contexto a las tendencias diarias.

  • Usa gráficos de barras para representar los recuentos de mensajes diarios.

¿Qué sigue?