En este documento, se proporcionan algunas sugerencias comunes para solucionar problemas de las suscripciones de extracción de Pub/Sub. Obtén más información sobre las suscripciones de extracción en la guía del suscriptor de extracción.
Para supervisar de manera eficaz tu suscripción a Pub/Sub, te recomendamos que primero observes la puntuación de estado de la latencia de entrega (subscription/delivery_latency_health_score) para verificar 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 del trabajo pendiente de una suscripción que un suscriptor aún no confirmó. Esta métrica ofrece estadísticas valiosas sobre posibles retrasos o cuellos de botella en el procesamiento.
Supervisar el retraso de los mensajes garantiza un procesamiento de mensajes oportuno y eficiente. Si realizas un seguimiento de la antigüedad del mensaje no confirmado más antiguo, puedes identificar de forma proactiva las situaciones en las que los consumidores se retrasan. Esta práctica permite una intervención temprana para abordar posibles problemas relacionados con el rendimiento degradado.
Estos son algunos de los problemas comunes de la lista 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 le sigan el paso al volumen de mensajes. En esta situación, enfócate en los componentes del suscriptor:
Estado del cliente: Analiza el uso de recursos en las máquinas que alojan clientes de suscriptores, como la CPU, la memoria y el ancho de banda de la red. Busca puntos de presión que puedan impedir la eficiencia del procesamiento.
Código del cliente: Revisa los cambios de código recientes y examina los registros de errores. Los errores o las ineficiencias en el código del suscriptor pueden afectar de forma significativa 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 deban acceder a la misma fila de una base de datos de forma simultánea. Este comportamiento puede generar contención y latencia alta.
Limitaciones de cuota: Verifica que no hayas excedido ninguna cuota o limitación de Pub/Sub que haya impuesto tu servicio de hosting. Si los suscriptores se alojan en Google Cloud, revisa las cuotas de recursos de Compute Engine o GKE para evitar posibles cuellos de botella.
El suscriptor confirmó negativamente los mensajes
Cuando un suscriptor confirma de forma negativa (rechaza) un mensaje, le indica a Pub/Sub que no se pudo procesar correctamente. Luego, Pub/Sub intenta volver a entregar el mismo mensaje. Los nacks repetidos para un mensaje generan duplicados y, posiblemente, una gran demora en la entrega de mensajes.
Ten en cuenta que si descartas un mensaje, no se garantiza que la próxima extracción recupere un mensaje diferente. Es posible que la política de reenvío de Pub/Sub siga reenviando mensajes sin encabezado antes que los nuevos. Por lo tanto, no confíes en los rechazos como método para filtrar o omitir mensajes específicos. En su lugar, configura una política de reintento, preferiblemente una retirada exponencial, como una forma de retirar mensajes individuales que es probable que se puedan procesar más adelante, pero que necesitan un poco más de tiempo antes de la nueva entrega.
Si necesitas omitir intencionalmente ciertos mensajes, el enfoque recomendado es confirmarlos, incluso si no los procesarás. Esto los quita de la suscripción, evita las reentregas innecesarias y reduce el consumo de recursos. Si no confirmas los mensajes, ya sea de forma intencional o no, se crean problemas de acumulación 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 de las posibles causas de una latencia de publicación alta.
No hay suficientes suscriptores
Para los clientes que usan StreamingPull, mantén varias conexiones abiertas de StreamingPull a tu suscripción para lograr una latencia baja de forma coherente. Sin conexiones activas de suscriptores, Pub/Sub no puede entregar mensajes de forma oportuna. Una sola transmisión podría ser un punto único de fallo, lo que aumenta el riesgo de demoras. La métrica subscription/open_streaming_pulls proporciona visibilidad sobre la cantidad de conexiones de transmisión activas. Úsala para asegurarte de tener siempre suficientes transmisiones para controlar los mensajes entrantes.
Para los clientes que usan la extracción unaria, mantén varias solicitudes de extracción pendientes en tu suscripción para lograr una latencia baja de forma coherente. Las solicitudes poco frecuentes podrían acumular mensajes en la lista de tareas pendientes y aumentar la latencia. Este enfoque ayuda a minimizar las brechas en la conectividad y mejorar la latencia de entrega.
Se recomienda la biblioteca cliente de alto nivel para los casos en los que se requiere una alta capacidad de procesamiento y una 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 controlan las llamadas a la API subyacentes para la autenticación, la optimización de la latencia y el rendimiento, el formato de mensajes y otras funciones.
Problemas de configuración del cliente
Consulta Problemas de configuración del cliente.
Tareas pendientes
Ten en cuenta que un retraso de mensajes de mensajes no confirmados en una suscripción de Pub/Sub aumenta de forma inherente la latencia de extremo a extremo porque los suscriptores no procesan los mensajes de inmediato.
Claves de ordenamiento y entrega “exactamente una vez”
Las claves de ordenamiento y la entrega exactamente una vez son funciones 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 provocar 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 se confirme la recepción de los anteriores con la misma clave de ordenamiento.
Considera si el orden de los mensajes o la entrega exactamente una vez son absolutamente esenciales para tu aplicación. Si tu prioridad es la baja latencia, minimizar el uso de estas funciones podría ayudar a reducir las demoras en el procesamiento de mensajes.
Aumento del tamaño de los mensajes
Un aumento repentino en el tamaño del mensaje podría aumentar el tiempo de transferencia entre Pub/Sub y tu cliente, y ralentizar el tiempo de procesamiento de los mensajes en el lado del 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, agrupando por topic_id. Correlaciona cualquier aumento repentino en el tamaño de los mensajes con los problemas de rendimiento observados.
Mensajes faltantes
Si sospechas que los mensajes no se entregan correctamente a tu suscriptor, es posible que uno de los siguientes motivos sea el factor que contribuye a ello.
Distribución de mensajes en suscripciones de Pub/Sub con varios consumidores
En Pub/Sub, los mensajes pueden distribuirse de forma desigual entre los consumidores. Este comportamiento se produce porque Pub/Sub distribuye los mensajes entre los consumidores activos para mejorar la eficiencia. A veces, un solo consumidor puede recibir menos mensajes de los esperados o un subconjunto de mensajes diferente al de otros consumidores.
Ten en cuenta que los mensajes ya podrían estar pendientes para los clientes y que un retraso de mensajes no confirmados no significa necesariamente 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 verificar los mensajes.
En el caso de los clientes de extracción unarios, es posible que observes que algunas solicitudes de extracción no muestran ningún mensaje. Como se explica en la sección No hay suficientes suscriptores, se recomienda mantener varias solicitudes de extracción pendientes, ya que algunas podrían mostrar menos de la cantidad máxima de mensajes configurada o incluso cero mensajes.
Si sospechas que se produce alguno de estos comportamientos, investiga si hay varios consumidores conectados de forma simultánea a la suscripción y, luego, inspecciona la situación.
Filtra por 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. Ten en cuenta cómo los filtros afectan las métricas de lista de tareas pendientes.
Usa la opción returnImmediately
Si tu cliente usa el método de 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 no muestra ningún mensaje. Esto puede provocar que las solicitudes de extracción muestren 0 mensajes, incluso cuando hay un trabajo pendiente.
Cómo abordar los duplicados
La duplicación de mensajes en Pub/Sub suele ocurrir cuando los suscriptores no pueden confirmar los mensajes dentro del plazo de confirmación. Esto hace que los mensajes se vuelvan a entregar, lo que crea la impresión de que son duplicados. Puedes medir la frecuencia con la que los suscriptores no cumplen el plazo 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.
Para reducir la tasa de duplicación, extiende los plazos de los mensajes.
- Las bibliotecas cliente manejan la extensión de plazos de forma automática, pero existen límites máximos predeterminados para la extensión que puedes configurar.
- Si creas 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, es posible que algunos mensajes venzan y requieran extensiones de plazo. Sin embargo, si el suscriptor sigue sin poder cumplir con la tarea, las extensiones de plazos repetidas eventualmente fallarán. En el peor de los casos, esto puede provocar que un suscriptor tenga una gran cantidad de duplicados, lo que agravará la acumulación. Los duplicados con vencimiento, luego, generan duplicados nuevos.
Para evitar abrumar al suscriptor, reduce la cantidad de mensajes que extrae a la vez. De esta manera, el suscriptor tiene menos mensajes para procesar dentro de la fecha límite. Vencerán menos mensajes y se volverán a entregar menos.
Para reducir la cantidad de mensajes que extrae el suscriptor 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 de suscriptores. Ten en cuenta que cada aplicación procesa los mensajes de manera diferente y tarda una cantidad de tiempo diferente en confirmarlos.
Cómo forzar reintentos
Para forzar a Pub/Sub a volver a enviar un mensaje, envía una solicitud nack. Si no usas las bibliotecas cliente de alto nivel, envía una solicitud modifyAckDeadline con un ackDeadlineSeconds establecido en 0.
Claves de ordenamiento
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 anteriormente. 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 que se aprueben correctamente los mensajes anteriores de la secuencia.
El suscriptor está rechazando los mensajes
Consulta El suscriptor está anulando los mensajes.
Cómo solucionar problemas de una suscripción a StreamingPull
Relación entre la métrica de latencia de la solicitud y la latencia de entrega de extremo a extremo
Para StreamingPull, la métrica serviceruntime.googleapis.com/api/request_latencies representa el tiempo durante el cual está abierta la transmisión. La métrica no es útil para determinar la latencia de entrega de extremo a extremo.
En lugar de usar la métrica de latencia de la solicitud, usa la puntuación de estado de la latencia de entrega para verificar qué factores contribuyen a aumentar la latencia de entrega de extremo a extremo.
Las conexiones de StreamingPull se cierran con un estado que no es correcto
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 de StreamingPull es solo un indicador de que el flujo está desconectado. Las solicitudes no fallan. Por lo tanto, aunque la API de StreamingPull puede tener una tasa de error del 100% que parece sorprendente, así se diseñó.
Dado que las transmisiones de StreamingPull siempre se cierran con un error, no es útil examinar las métricas de finalización de la transmisión cuando diagnosticas errores. Más bien, enfócate 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 los trabajos acumulados de suscripciones que están encriptados con una clave de Cloud KMS inhabilitada. Para reanudar la extracción, restablece el acceso a la clave.
Los errores de no disponibilidad 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 reintenta las solicitudes. No es necesario que realices ninguna acción si usas una biblioteca cliente.
Los errores de no encontrado pueden ocurrir cuando se borra la suscripción o si nunca existió. El último caso ocurre si proporcionaste una ruta de acceso de suscripción no válida.