En este documento, se proporcionan algunas sugerencias comunes para la solución de problemas de suscripciones de extracción de Pub/Sub. Obtén más información sobre las suscripciones de extracción en la Guía para suscriptores de extracción.
Para supervisar tu suscripción a Pub/Sub de forma eficaz, se recomienda consultar primero la puntuación del estado de la latencia de entrega (subscription/delivery_latency_health_score) para comprobar qué factores pueden contribuir a una latencia inesperada o aumentada.
La antigüedad del mensaje sin confirmación más antiguo sigue aumentando
oldest_unacked_message_age es una métrica fundamental para supervisar el estado de las suscripciones a Pub/Sub. Mide la antigüedad, en segundos, del mensaje más antiguo de las tareas pendientes de una suscripción que un suscriptor aún no confirmó (confirmó). Esta métrica ofrece estadísticas valiosas sobre posibles retrasos en el procesamiento o cuellos de botella.
Supervisar las tareas pendientes garantiza el procesamiento de mensajes oportuno y eficiente. Si haces un seguimiento de la antigüedad del mensaje sin confirmación más antiguo, puedes identificar de forma proactiva las situaciones en las que los consumidores se están quedando atrás. Esta práctica permite la intervención temprana para abordar posibles problemas relacionados con el rendimiento degradado.
Estos son algunos de los problemas comunes de tareas pendientes que puedes investigar:
Problemas de configuración del cliente
Cuando las métricas oldest_unacked_message_age y num_undelivered_messages aumentan de forma simultánea, es posible que los suscriptores no estén a la altura del volumen de mensajes. En esta situación, debes centrar tu investigación en los componentes del suscriptor:
Estado del cliente: Analiza el uso de recursos en máquinas que alojan clientes suscriptores, como CPU, memoria y ancho de banda de red. Busca puntos de presión que puedan impedir la eficiencia del procesamiento.
Código de cliente: revisa los cambios recientes del código y examina los registros de errores. Los errores o las ineficiencias en el código del suscriptor pueden afectar significativamente las tasas de procesamiento de mensajes. Ten en cuenta que podría haber problemas en mensajes específicos. Por ejemplo, es posible que varios mensajes necesiten acceder de forma simultánea a la misma fila en una base de datos. Este comportamiento puede generar contención y latencia alta.
Limitaciones de cuota: Verifica que no hayas superado las cuotas o limitaciones de Pub/Sub que impone tu servicio de hosting. Si los suscriptores están alojados en Google Cloud, revisa las cuotas de recursos de Compute Engine o GKE para evitar posibles cuellos de botella.
El suscriptor reconoció los mensajes de manera negativa
Cuando un suscriptor confirma la recepción de un mensaje de forma negativa, le indica a Pub/Sub que no se pudo procesar correctamente. Luego, Pub/Sub intenta volver a entregar el mismo mensaje. Los errores repetidos en un mensaje producen duplicados y, potencialmente, una gran demora en la entrega del mensaje.
Ten en cuenta que marcar un mensaje no garantiza que la siguiente extracción recupere un mensaje diferente. Es posible que la política de reenvío de Pub/Sub siga enviando mensajes entrantes antes que otros nuevos. Por lo tanto, no confíes en los “niños” como método para omitir mensajes específicos o filtrarlos. En cambio, establece una política de reintento, preferentemente una retirada exponencial, como una forma de retirarte de los mensajes individuales que probablemente se puedan procesar más adelante, pero que necesiten un poco más de tiempo antes de volver a entregarse.
Si necesitas omitir ciertos mensajes de forma intencional, el enfoque recomendado es confirmarlos, incluso si no los procesarás. Esto los quita de la suscripción, evita las entregas innecesarias y reduce el consumo de recursos. Dejar los mensajes sin confirmar, ya sea de forma intencional o no, crea problemas pendientes y entregas duplicadas.
Latencia de entrega alta
La latencia de entrega en Pub/Sub es el tiempo que tarda un mensaje de un publicador en llegar a un suscriptor. En las siguientes secciones, se describen algunas posibles causas de una latencia de entrega alta.
No hay suficientes suscriptores
En el caso de los clientes que usan StreamingPull, para lograr una latencia baja constante, mantén varias conexiones de StreamingPull abiertas en tu suscripción. Sin conexiones activas de suscriptores, Pub/Sub no puede entregar mensajes con rapidez. Una sola transmisión puede ser un punto único de fallo, lo que aumenta el riesgo de retrasos. La métrica subscription/open_streaming_pulls proporciona visibilidad sobre la cantidad de conexiones de transmisión activas. Úsala para asegurarte de tener de forma coherente transmisiones suficientes para manejar los mensajes entrantes.
En el caso de los clientes que usan una extracción unaria, para lograr una latencia baja constante, debes mantener múltiples solicitudes de extracción pendientes para tu suscripción. Las solicitudes poco frecuentes podrían acumular mensajes en las tareas pendientes y aumentar la latencia. Este enfoque ayuda a minimizar las brechas en la conectividad y mejorar la latencia de entrega.
La biblioteca cliente de alto nivel se recomienda para los casos en los que necesites una capacidad de procesamiento alta y baja latencia con una sobrecarga operativa y un costo de procesamiento mínimos. De forma predeterminada, la biblioteca cliente de alto nivel usa la API de StreamingPull, ya que suele ser una mejor opción para minimizar la latencia. Las bibliotecas cliente de alto nivel contienen funciones y clases precompiladas que manejan las llamadas a la API subyacentes para la autenticación, la capacidad de procesamiento y la optimización de la latencia, el formato de los mensajes y otras funciones.
Problemas de configuración del cliente
Consulta Problemas de configuración del cliente.
Tareas pendientes
Ten en cuenta que las tareas pendientes de mensajes sin confirmar en una suscripción de Pub/Sub aumentan de forma inherente la latencia de extremo a extremo, ya que los suscriptores no los procesan de inmediato.
Solicita llaves y entrega “exactamente una vez”
Las claves de pedido y la entrega exactamente una vez son características valiosas, pero requieren coordinación adicional dentro de Pub/Sub para garantizar una entrega correcta. Esta coordinación puede reducir la disponibilidad y aumentar la latencia. Si bien la diferencia es mínima en el estado estable, cualquier paso de coordinación necesario podría generar aumentos temporales en la latencia o un aumento en la tasa de errores. Si el ordenamiento está habilitado, los mensajes con una clave de ordenamiento no se pueden entregar hasta que los anteriores con la misma clave de ordenamiento se confirmen.
Considera si el ordenamiento de los mensajes o la entrega “exactamente una vez” son absolutamente esenciales para tu aplicación. Si la latencia baja es tu prioridad principal, minimizar el uso de estas funciones puede ayudar a reducir los retrasos en el procesamiento de mensajes.
de aumento en el tamaño del mensaje
Un aumento repentino en el tamaño del mensaje podría aumentar potencialmente el tiempo de transferencia entre Pub/Sub y tu cliente, y ralentizar el tiempo de procesamiento de los mensajes en el cliente.
Si observas un aumento en la latencia de entrega, puedes verificar los tamaños de los mensajes con la métrica topic/message_sizes, agrupándolos por topic_id. Correlaciona los aumentos repentinos en el tamaño del mensaje con los problemas de rendimiento observados.
Faltan mensajes
Si sospechas que los mensajes no se entregan de forma correcta a tu suscriptor, uno de los siguientes motivos podría ser el factor contribuyente.
Distribución de mensajes en suscripciones de Pub/Sub con varios consumidores
En Pub/Sub, es posible que los mensajes se distribuyan de manera desigual entre los consumidores. Este comportamiento ocurre porque Pub/Sub distribuye mensajes entre consumidores activos para mejorar la eficiencia. A veces, un solo consumidor podría recibir menos mensajes de los esperados o un subconjunto de mensajes diferente que otros consumidores.
Ten en cuenta que los mensajes ya podrían estar pendientes para los clientes y que una acumulación de mensajes no confirmados no necesariamente significa que recibirás esos mensajes en tu próxima solicitud de extracción. Ten en cuenta que un consumidor puede ser alguien que usa la extracción en la consola de Google Cloud o Google Cloud CLI, o que ejecuta un suscriptor personalizado de forma local para revisar los mensajes.
En el caso de los clientes de extracción unarios, es posible que observes algunas solicitudes de extracción que no muestran ningún mensaje. Como se explicó en la sección No hay suficientes suscriptores, se recomienda mantener varias solicitudes de extracción pendientes, ya que algunas podrían mostrar menos mensajes que la cantidad máxima configurada o incluso cero mensajes.
Si sospechas de alguno de estos comportamientos, investiga si hay varios consumidores vinculados al mismo tiempo a la suscripción y, luego, inspeccionalos.
Filtra la suscripción
Verifica si la suscripción tiene un filtro adjunto. Si es así, solo recibirás los mensajes que coincidan con el filtro. El servicio de Pub/Sub confirma automáticamente los mensajes que no coinciden con el filtro. Considera cómo los filtros afectan las métricas de tareas pendientes.
Usa la opción returnImmediately
Si tu cliente usa una extracción unaria, verifica si el campo returnImmediately está configurado como verdadero. Este es un campo obsoleto que le indica al servicio de Pub/Sub que responda a la solicitud de extracción de inmediato, incluso si se muestra sin mensajes. Esto puede hacer que las solicitudes de extracción muestren 0 mensajes incluso cuando hay una tarea pendiente.
Cómo abordar los duplicados
La duplicación de mensajes en Pub/Sub suele ocurrir cuando los suscriptores no pueden confirmar mensajes dentro del plazo. Esto provoca que los mensajes se vuelvan a entregar, lo que crea la impresión de duplicados. Puedes medir la tasa en la que los suscriptores no cumplen con la fecha límite de confirmación con la métrica subscription/expired_ack_deadlines_count. Obtén más información para supervisar el vencimiento del plazo de confirmación de recepción.
Para reducir la tasa de duplicación, extiende los plazos de los mensajes.
- Las bibliotecas cliente controlan la extensión de la fecha límite automáticamente, pero existen límites predeterminados sobre la fecha límite máxima de extensión que puedes configurar.
- Si estás compilando tu propia biblioteca cliente, usa el método
modifyAckDeadlinepara extender el plazo de confirmación.
Si los mensajes se extraen del suscriptor más rápido de lo que se pueden procesar y confirmar, algunos mensajes podrían vencer y requerir extensiones de plazos. Sin embargo, si el suscriptor sigue abrumado, las extensiones de plazos repetidas eventualmente fallan. En el peor de los casos, esto puede provocar que un suscriptor se desborde de duplicados, lo que agravaría el trabajo pendiente. Duplicados que vencen, luego generan nuevos duplicados.
Para evitar abrumar al suscriptor, reduce la cantidad de mensajes que extrae a la vez. De esta manera, el suscriptor tiene menos mensajes que procesar dentro del plazo. Caduquen menos mensajes y se volverán a enviar menos.
Para reducir la cantidad de mensajes que el suscriptor extrae a la vez, debes reducir la cantidad máxima de mensajes pendientes en la configuración de control de flujo del suscriptor. No hay un valor único para todos, por lo que debes ajustar el límite máximo de mensajes pendientes según tu capacidad de procesamiento y la de suscriptor. Ten en cuenta que cada aplicación procesa los mensajes de forma diferente y tarda cierto tiempo en confirmarlos.
Cómo forzar los reintentos
Para forzar que Pub/Sub vuelva a enviar un mensaje, envía una solicitud nack. Si no usas las bibliotecas cliente de alto nivel, envía una solicitud modifyAckDeadline con ackDeadlineSeconds establecido en 0.
Ordena claves
Cuando Pub/Sub vuelve a entregar un mensaje con una clave de ordenamiento, también vuelve a entregar todos los mensajes posteriores con la misma clave de ordenamiento, incluso si se confirmaron con anterioridad. Esto se hace para preservar el orden de la secuencia. Sin embargo, no hay una garantía estricta de que los mensajes dependientes solo se envíen después de la confirmación correcta de los mensajes anteriores de la secuencia.
El suscriptor está ingresando los mensajes
Consulta el suscriptor está almacenando los mensajes.
Soluciona problemas de una suscripción a StreamingPull
Las transmisiones de StreamingPull siempre se cierran con un estado que no es correcto. A diferencia de un estado de error para RPC unarias, este estado para StreamingPull es solo una indicación de que la transmisión está desconectada. Las solicitudes no fallan. Por lo tanto, si bien la API de StreamingPull puede tener una tasa de error sorprendente del 100%, este comportamiento es intencional.
Dado que las transmisiones de StreamingPull siempre se cierran con un error, no es útil examinar las métricas de finalización de transmisión mientras se diagnostican los errores. En cambio, concéntrate en la métrica de respuesta de StreamingPull subscription/streaming_pull_response_count, agrupada por response_code o response_class.
Busca estos errores:
Pueden ocurrir errores de condición previa fallida si hay mensajes en las tareas pendientes de suscripción que están encriptados con una clave de Cloud KMS inhabilitada. Para reanudar la extracción, restablece el acceso a la clave.
Los errores no disponibles pueden ocurrir cuando Pub/Sub no puede procesar una solicitud. Lo más probable es que esta sea una condición transitoria y la biblioteca cliente reintente las solicitudes. No es necesario que realices ninguna acción si usas una biblioteca cliente.
Los errores No encontrado pueden ocurrir cuando se borra la suscripción o si nunca existió. El último caso ocurre si proporcionaste una ruta de suscripción no válida.