Monitorizar Pub/Sub en Cloud Monitoring

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

En este documento se explica cómo monitorizar el uso de Pub/Sub en la consola de Google Cloud con Monitoring.

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

  • De lo contrario, puedes usar los paneles de control de monitorización que se proporcionan en Pub/Sub. Consulta Monitorizar temas y Monitorizar suscripciones.

Para consultar las prácticas recomendadas sobre el uso de métricas en el escalado automático, consulte Prácticas recomendadas para usar métricas de Pub/Sub como señal de escalado.

Antes de empezar

Antes de usar Monitoring, asegúrate de que has preparado lo siguiente:

  • Una cuenta de facturación de Cloud

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

Una forma de asegurarte de que tienes ambos es completar la guía de inicio rápido sobre cómo usar la consola de Cloud.

Ver un panel de control

Los paneles de control le permiten ver y analizar datos de diferentes fuentes en el mismo contexto. Google Cloud ofrece paneles de control predefinidos y personalizados. Por ejemplo, puede ver un panel de Pub/Sub predefinido o crear uno personalizado que muestre datos de métricas, políticas de alertas y entradas de registro relacionadas con Pub/Sub.

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

  1. En la Google Cloud consola, ve a la página Monitorización.

    Ir a Monitoring

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

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

  4. En la página Resumen de los paneles de control, cree un panel de control o seleccione el panel Pub/Sub.

    Para buscar el panel de control Pub/Sub, en el filtro de Todos los paneles de control, selecciona la propiedad Nombre e introduce Pub/Sub.

Para obtener más información sobre cómo crear, editar y gestionar un panel de control personalizado, consulta el artículo Gestionar paneles de control personalizados.

Ver una sola métrica de Pub/Sub

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

  1. En la Google Cloud consola, ve a la página Monitorización.

    Ir a Monitoring

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

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

  4. En el filtro, introduce Pub/Sub.

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

  6. Desglosa la información de 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 control de monitorización, consulta la documentación de Cloud Monitoring.

Ver métricas y tipos de recursos de Pub/Sub

Acceder al editor de MQL

El explorador de métricas es una interfaz de Cloud Monitoring diseñada para explorar y visualizar los datos de métricas. En 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 uses el explorador de métricas, consulta Acceder al editor de código.

Crear una consulta de MQL

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

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

  2. Selecciona la métrica. Use | metric 'metric_name' para especificar la métrica que quiera 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 los datos. Entre los filtros habituales 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. Refina tus datos con otras cláusulas. MQL ofrece otras cláusulas, como | every (para definir la frecuencia de ejecución de las consultas) y | within (para especificar un intervalo de tiempo), entre otras.

Aquí tienes un ejemplo de consulta para monitorizar el recuento por horas 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)]

Monitorizar el uso de la cuota

En un proyecto determinado, puedes usar el panel de cuotas de gestión de identidades y accesos (IAM) y administración para ver las cuotas actuales y su uso.

Puede consultar su historial de uso de cuotas con las siguientes métricas:

Estas métricas usan el tipo de recurso monitorizado consumer_quota. Para ver más métricas relacionadas con las cuotas, consulta la lista de métricas.

Por ejemplo, la siguiente consulta de MQL crea un gráfico con la fracción de cuota de editor que se está usando 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 superará los límites de cuota predeterminados, crea políticas de alertas para todas las cuotas pertinentes. Estas alertas se activan cuando tu uso alcanza una fracción del límite. Por ejemplo, la siguiente consulta de Monitoring Query Language activa una política de alertas cuando se supera el 80% de uso de cualquier cuota de Pub/Sub:

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 obtener más información sobre cómo monitorizar y recibir alertas de forma personalizada sobre métricas de cuotas, consulta el artículo Usar métricas de cuotas.

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

Mantener una suscripción activa

Para mantener una suscripción en buen estado, puede monitorizar varias propiedades de la suscripción mediante las métricas proporcionadas por Pub/Sub. Por ejemplo, puedes monitorizar el volumen de mensajes sin confirmar, el vencimiento de los plazos de confirmación de mensajes, etc. También puedes comprobar si tu suscripción es lo suficientemente buena para conseguir una latencia de entrega de mensajes baja.

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

Monitorizar el backlog de mensajes

Para asegurarte de que tus suscriptores están al día de los mensajes, crea un panel de control. En el panel de control se pueden mostrar las siguientes métricas de la cartera de pedidos, agregadas por recurso, de todas sus suscripciones:

Crea políticas de alertas que se activen cuando estos valores estén fuera del intervalo aceptable en el contexto de tu sistema. Por ejemplo, el número absoluto de mensajes no confirmados no tiene por qué ser significativo. Un backlog de un millón de mensajes puede ser aceptable para una suscripción de un millón de mensajes por segundo, pero no para una suscripción de un mensaje por segundo.

Problemas habituales con la cartera de pedidos

Síntomas Problema Soluciones
Tanto oldest_unacked_message_age_by_region como num_unacked_messages_by_region están creciendo al mismo ritmo. Los suscriptores no pueden seguir el ritmo del volumen de mensajes
  • Añade más procesos o subprocesos de suscriptor.
  • Añade más máquinas o contenedores de suscriptores.
  • Busca señales de errores en el código que impidan que se confirmen los mensajes o que se procesen a tiempo. Consulta Monitorizar el vencimiento del plazo de confirmación.
Si el tamaño de la cartera es pequeño y constante, pero el oldest_unacked_message_age_by_region aumenta de forma constante, es posible que haya algunos mensajes que no se puedan procesar. Mensajes bloqueados
  • Examina los registros de tu aplicación para saber si algunos mensajes están provocando que tu código falle. Es poco probable, pero posible, que los mensajes infractores se hayan quedado en Pub/Sub en lugar de en tu cliente. Abre un caso de asistencia cuando tengas la certeza de que tu código procesa correctamente cada mensaje.
  • Si algunos mensajes provocan que tu código falle, puedes reenviarlos a un tema de mensajes fallidos.
El oldest_unacked_message_age_by_region supera el periodo de retención de mensajes de la suscripción . Pérdida de datos permanente
  • Configura una alerta que se active antes de que finalice el periodo de conservación de los mensajes.

Monitorizar el estado de la latencia de entrega

En Pub/Sub, la latencia de entrega es el tiempo que tarda en entregarse un mensaje publicado a un suscriptor. Si la acumulación de mensajes aumenta, puede usar la puntuación de estado de latencia de entrega (subscription/delivery_latency_health_score) para comprobar qué factores contribuyen a que aumente la latencia.

Esta métrica mide el estado de una sola suscripción en un periodo de 10 minutos. La métrica proporciona información valiosa sobre los siguientes criterios, que son necesarios para que una suscripción consiga una latencia baja constante:

  • Solicitudes de búsqueda insignificantes.

  • Mensajes con confirmación negativa insignificante.

  • Plazos de confirmación de mensajes caducados insignificantes.

  • Latencia de confirmación constante inferior a 30 segundos.

  • Una utilización baja y constante, lo que significa que la suscripción tiene capacidad suficiente para procesar nuevos mensajes.

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

  • Solicitudes de búsqueda: si la suscripción ha tenido alguna solicitud de búsqueda en los últimos 10 minutos, la puntuación se establece en 0. Buscar una suscripción puede provocar que los mensajes antiguos se reproduzcan mucho tiempo después de que se hayan publicado por primera vez, lo que aumenta la latencia de entrega.

  • Mensajes con confirmación negativa (nack): si la suscripción ha tenido alguna solicitud de confirmación negativa (nack) en los últimos 10 minutos, la puntuación se establece en 0. Una confirmación negativa provoca que un mensaje se vuelva a enviar con una latencia de entrega mayor.

  • Plazos de confirmación caducados: si la suscripción ha tenido algún plazo de confirmación caducado en los últimos 10 minutos, la puntuación se establece en 0. Los mensajes cuyo plazo de confirmación ha caducado se vuelven a enviar con una latencia de entrega mayor.

  • Latencias de confirmación: si el percentil 99,9 de todas las latencias de confirmación de los últimos 10 minutos ha sido superior a 30 segundos, la puntuación se establece en 0. Una latencia de confirmación alta indica que un cliente de suscriptor tarda demasiado en procesar un mensaje. Esta puntuación podría implicar un error o algunas restricciones de recursos en el lado del cliente del suscriptor.

  • Bajo uso: el uso se calcula de forma diferente para cada tipo de suscripción.

    • StreamingPull si no tienes suficientes streams abiertos, la puntuación se establece en 0. Abre más flujos para asegurarte de que tienes capacidad suficiente para los mensajes nuevos.

    • Inserción: si tienes demasiados mensajes pendientes en tu endpoint de inserción, la puntuación se establece en 0. Añade más capacidad a tu endpoint de envío para que tengas capacidad para nuevos mensajes.

    • Pull: 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 que puedes recibir mensajes nuevos.

Para ver la métrica, en Explorador de métricas, selecciona la métrica Puntuación de estado de latencia de entrega del tipo de recurso de suscripción de Pub/Sub. Añade un filtro para seleccionar solo una suscripción a la vez. Selecciona el gráfico de áreas apiladas y apunta a un momento concreto para consultar las puntuaciones de los criterios de la suscripción en ese momento.

A continuación, se muestra una captura de pantalla de la métrica representada durante un periodo de una hora mediante un gráfico de áreas apiladas. La puntuación de salud combinada llega a 5 a las 4:15, con una puntuación de 1 en cada criterio. Más adelante, la puntuación combinada disminuye a 4 a las 4:20, cuando la puntuación de utilización baja a 0.

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

Monitoring Query Language proporciona una interfaz expresiva basada en texto para los datos de series temporales de Cloud Monitoring. La siguiente consulta de 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

Monitorizar la caducidad del plazo de confirmación

Para reducir la latencia de entrega de mensajes, Pub/Sub permite a los clientes suscriptores un tiempo limitado para confirmar la recepción de un mensaje determinado. Este periodo se conoce como plazo de confirmación. Si tus suscriptores tardan demasiado en confirmar los mensajes, estos se volverán a enviar, lo que provocará que los suscriptores vean mensajes duplicados. Esta nueva entrega puede deberse a varios motivos:

  • Tus suscriptores no tienen suficientes recursos (necesitas más hilos o máquinas).

  • El tiempo necesario para procesar cada mensaje es superior al plazo de confirmación del mensaje. Las bibliotecas de cliente de Cloud suelen ampliar el plazo de los mensajes individuales hasta un máximo configurable. Sin embargo, también se aplica un plazo máximo de prórroga a las bibliotecas.

  • Algunos mensajes provocan que el cliente falle constantemente.

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 las tasas de vencimiento del plazo de confirmación son excesivas, se pueden producir ineficiencias costosas en tu sistema. Pagas por cada reenvío y por intentar procesar cada mensaje repetidamente. Por el contrario, una tasa de caducidad baja (por ejemplo, del 0,1 al 1%) podría ser adecuada.

Monitorizar el rendimiento de los mensajes

Los suscriptores de extracción y extracción por streaming pueden recibir lotes de mensajes en cada respuesta de extracción, mientras que las suscripciones push reciben un solo mensaje en cada solicitud push. Puedes monitorizar el rendimiento de los mensajes por lotes que procesan tus suscriptores con estas métricas:

Puedes monitorizar el rendimiento de los mensajes individuales o sin agrupar que procesan tus suscriptores con la métrica subscription/sent_message_count filtrada por la etiqueta delivery_type.

La siguiente consulta de MQL muestra un gráfico de serie temporal con el número total de mensajes enviados a una suscripción de Pub/Sub específica cada 10 minutos. Sustituye los valores de los marcadores de posición $PROJECT_NAME y $SUBSCRIPTION_NAME por los identificadores del proyecto y del tema.

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

Monitorizar las suscripciones push

En el caso de las suscripciones push, monitoriza estas métricas:

  • subscription/push_request_count

    Agrupa la métrica por response_code y subcription_id. Como las suscripciones push de Pub/Sub usan códigos de respuesta como confirmaciones implícitas de mensajes, es importante monitorizar los códigos de respuesta de las solicitudes push. Como las suscripciones push se retiran exponencialmente cuando se producen errores o se agota el tiempo de espera, tu lista de pendientes puede crecer rápidamente en función de cómo responda tu endpoint.

    Te recomendamos que configures una alerta para las frecuencias de errores altas, ya que provocan que la entrega sea lenta y que se acumulen pedidos. Puedes crear una métrica filtrada por clase de respuesta. Sin embargo, es probable que los recuentos de solicitudes push sean más útiles como herramienta para investigar el tamaño y la antigüedad crecientes de la cartera de pedidos.

  • subscription/num_outstanding_messages

    Por lo general, Pub/Sub limita el número de mensajes pendientes. En la mayoría de los casos,intenta que haya menos de 1000 mensajes pendientes. Una vez que el rendimiento alcanza una tasa del orden de 10.000 mensajes por segundo, el servicio ajusta el límite del número de mensajes pendientes. Esta limitación se aplica en incrementos de 1000. No se ofrecen garantías específicas más allá del valor máximo, por lo que 1000 mensajes pendientes es una buena referencia.

  • subscription/push_request_latencies

    Esta métrica te ayuda a comprender la distribución de la latencia de respuesta del endpoint push. Debido al límite en el número de mensajes pendientes, la latencia del endpoint afecta al rendimiento de la suscripción. Si se tarda 100 milisegundos en procesar cada mensaje, es probable que tu límite de rendimiento sea de 10 mensajes por segundo.

Para acceder a límites de mensajes pendientes más altos, los suscriptores de notificaciones push deben confirmar más del 99% de los mensajes que reciban.

Puedes calcular la fracción de mensajes que confirman los suscriptores mediante el lenguaje de consulta de monitorización. La siguiente consulta de MQL crea un gráfico con la fracción de mensajes que los suscriptores confirman en 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

Monitorizar 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 monitorizar esta confirmación automática.

Las métricas de la cartera de pedidos solo incluyen los mensajes que coinciden con el filtro.

Para monitorizar 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 definida como filter.

Para monitorizar el rendimiento y el coste de los mensajes confirmados automáticamente que no coinciden con el filtro, usa la métrica subscription/byte_cost con la etiqueta operation_type definida como filter_drop. Para obtener más información sobre las tarifas de estos mensajes, consulta la página de precios de Pub/Sub.

Monitorizar suscripciones con SMTs

Si tu suscripción contiene un SMT que filtra mensajes, las métricas de backlog incluyen los mensajes filtrados hasta que el SMT se ejecute en ellos. Esto significa que la cartera de pedidos puede parecer más grande y la antigüedad del mensaje más antiguo sin confirmar puede parecer mayor de lo que se enviará a tu suscriptor. Es especialmente importante tenerlo en cuenta si usas estas métricas para escalar automáticamente los suscriptores.

Monitorizar los mensajes no entregados reenviados

Para monitorizar los mensajes que no se pueden entregar y que Pub/Sub reenvía a un tema de mensajes fallidos, usa la métrica subscription/dead_letter_message_count. Esta métrica muestra el número de mensajes que no se pueden entregar que Pub/Sub reenvía desde una suscripción.

Para verificar que Pub/Sub reenvía los mensajes que no se pueden entregar, puede comparar la métrica subscription/dead_letter_message_count con la métrica topic/send_request_count. Compara el tema de mensajes fallidos al que Pub/Sub reenvía estos mensajes.

También puede adjuntar una suscripción al tema de mensajes fallidos y, a continuación, monitorizar los mensajes no entregados reenviados en esta suscripción mediante las siguientes métricas:

Mantener un editor en buen estado

El objetivo principal de un editor es conservar los datos de los mensajes rápidamente. Monitoriza este rendimiento con topic/send_request_count agrupado por response_code. Esta métrica te indica si Pub/Sub está en buen estado y acepta solicitudes.

Una tasa de errores reintentables en segundo plano (inferior al 1%) no es motivo de preocupación, ya que la mayoría de las bibliotecas de cliente de Cloud vuelven a intentar enviar los mensajes que han fallado. Investigue las tasas de error superiores al 1%. Como tu aplicación gestiona los códigos que no se pueden volver a intentar (en lugar de la biblioteca de cliente), debes examinar los códigos de respuesta. Si tu aplicación de editor no tiene una forma adecuada de indicar un estado incorrecto, considera la posibilidad de definir una alerta en la métrica topic/send_request_count.

Es igual de importante registrar las solicitudes de publicación fallidas en tu cliente de publicación. Aunque las bibliotecas de cliente suelen reintentar las solicitudes fallidas, no garantizan la publicación. Consulta la sección Publicar mensajes para ver cómo detectar errores de publicación permanentes al usar las bibliotecas de cliente de Cloud. Como mínimo, tu aplicación de editor 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.

Monitorizar el rendimiento de los mensajes

Los editores pueden enviar mensajes en lotes. Puede monitorizar el volumen de mensajes enviados por sus editores con estas métricas:

Para obtener un recuento preciso de los mensajes publicados, usa la siguiente consulta de MQL. Esta consulta de MQL obtiene el recuento de mensajes individuales publicados en un tema de Pub/Sub específico en intervalos de tiempo definidos. Sustituye los valores de los marcadores de posición $PROJECT_NAME y $TOPIC_ID por los identificadores del proyecto y del tema.

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 que la visualización sea más cómoda, sobre todo en el caso de las métricas diarias, ten en cuenta lo siguiente:

  • Consulta tus datos durante un periodo más largo para obtener más contexto sobre las tendencias diarias.

  • Usa gráficos de barras para representar el número de mensajes diarios.

Siguientes pasos