En este documento se ofrecen algunos consejos habituales para solucionar problemas con las suscripciones de extracción de Pub/Sub. Consulta más información sobre las suscripciones de extracción en la guía del suscriptor de extracción.
Para monitorizar de forma eficaz tu suscripción a Pub/Sub, te recomendamos que primero consultes la puntuación de estado de la latencia de entrega (subscription/delivery_latency_health_score) para comprobar qué factores pueden contribuir a una latencia inesperada o mayor.
La antigüedad del mensaje no confirmado más antiguo sigue aumentando
La métrica oldest_unacked_message_age es fundamental para monitorizar el estado de las suscripciones de Pub/Sub. Mide la antigüedad, en segundos, del mensaje más antiguo del registro de una suscripción que aún no ha confirmado un suscriptor. Esta métrica ofrece información valiosa sobre posibles retrasos en el procesamiento o cuellos de botella.
Monitorizar la acumulación de mensajes asegura que los mensajes se procesen de forma oportuna y eficiente. Si monitorizas la antigüedad del mensaje no confirmado 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 intervenir pronto para solucionar posibles problemas relacionados con el rendimiento.
Estos son algunos de los problemas habituales de la cartera de pedidos que puedes investigar:
Problemas de configuración del cliente
Si las métricas oldest_unacked_message_age y num_undelivered_messages aumentan simultáneamente, puede significar que los suscriptores no están al día con el volumen de mensajes. En esta situación, centra tu investigación en los componentes del suscriptor:
Estado del cliente: analiza el uso de recursos en los equipos que alojan clientes de suscriptor, 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 de cliente: revisa los cambios recientes en el código y examina los registros de errores. Los errores o las ineficiencias en el código del suscriptor pueden afectar significativamente a las tasas de procesamiento de mensajes. Ten en cuenta que puede haber problemas en mensajes concretos. Por ejemplo, es posible que varios mensajes necesiten acceder a la misma fila de una base de datos simultáneamente. Este comportamiento puede provocar conflictos y una latencia alta.
Limitaciones de cuota: comprueba que no hayas superado ninguna cuota ni limitación de Pub/Sub impuesta por tu servicio de alojamiento. Si los suscriptores están alojados en Google Cloud, consulta las cuotas de recursos de Compute Engine o GKE para evitar posibles cuellos de botella.
El suscriptor ha confirmado negativamente los mensajes
Cuando un suscriptor envía una confirmación negativa (NACK) de un mensaje, indica a Pub/Sub que el mensaje no se ha podido procesar correctamente. A continuación, Pub/Sub intenta volver a enviar el mismo mensaje. Si se envía un NACK repetidamente para un mensaje, se duplicará y es posible que se retrase mucho el envío.
Ten en cuenta que enviar una respuesta negativa a un mensaje no garantiza que la siguiente extracción obtenga un mensaje diferente. La política de reenvío de Pub/Sub puede seguir reenviando mensajes con confirmación negativa antes que los nuevos. Por lo tanto, no utilices los nacks como método para filtrar u omitir mensajes específicos. En su lugar, define una política de reintentos, preferiblemente un retroceso exponencial, para reducir la frecuencia 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 enviarse.
Si necesitas omitir ciertos mensajes de forma intencionada, te recomendamos que envíes una confirmación, aunque no los vayas a procesar. De esta forma, se eliminan de la suscripción, se evitan reenvíos innecesarios y se reduce el consumo de recursos. Si no confirmas la recepción de los mensajes, ya sea de forma intencionada o no, se producirán problemas de trabajo acumulado y se duplicarán los envíos.
Latencia de entrega alta
La latencia de entrega en Pub/Sub es el tiempo que tarda un mensaje de un editor en llegar a un suscriptor. En las siguientes secciones se describen algunas de las posibles causas de una latencia de entrega alta.
No hay suficientes suscriptores
En el caso de los clientes que usan StreamingPull, para conseguir una latencia baja constante, mantén varias conexiones StreamingPull abiertas a tu suscripción. Si no hay conexiones de suscriptores activas, Pub/Sub no puede entregar los mensajes rápidamente. Un solo flujo podría ser un punto único de fallo, lo que aumentaría el riesgo de retrasos. La métrica subscription/open_streaming_pulls proporciona información sobre el número de conexiones de streaming activas. Úsalo para asegurarte de que siempre tienes suficientes flujos para gestionar los mensajes entrantes.
En el caso de los clientes que usan la extracción unaria, para conseguir una latencia baja constante, mantén varias solicitudes de extracción pendientes en tu suscripción. Las solicitudes poco frecuentes podrían acumular mensajes en la lista de pendientes y aumentar la latencia. Este enfoque ayuda a minimizar las interrupciones en la conectividad y a mejorar la latencia de entrega.
La biblioteca de cliente de alto nivel se recomienda en los casos en los que se necesite un rendimiento alto y una latencia baja con una sobrecarga operativa y un coste de procesamiento mínimos. De forma predeterminada, la biblioteca de cliente de alto nivel usa la API StreamingPull, ya que suele ser la mejor opción para minimizar la latencia. Las bibliotecas de cliente de alto nivel contienen funciones y clases precompiladas que gestionan las llamadas a la API subyacentes para la autenticación, la optimización del rendimiento y la latencia, el formato de los mensajes y otras funciones.
Problemas de configuración del cliente
Consulta la sección Problemas de configuración del cliente.
Backlog alto
Ten en cuenta que la acumulación de mensajes sin confirmar en una suscripción de Pub/Sub aumenta la latencia de extremo a extremo, ya que los suscriptores no procesan los mensajes inmediatamente.
Ordenación de claves y entrega exactamente una vez
Las claves de ordenación y el envío exactamente una vez son funciones valiosas, pero requieren una coordinación adicional en Pub/Sub para garantizar que el envío sea correcto. Esta coordinación puede reducir la disponibilidad y aumentar la latencia. Aunque la diferencia es mínima en el estado estable, cualquier paso de coordinación necesario podría provocar aumentos temporales de la latencia o de la tasa de errores. Si la ordenación está habilitada, los mensajes con una clave de ordenación no se pueden entregar hasta que se hayan confirmado los anteriores con la misma clave de ordenación.
Plantéate si el orden de los mensajes o el envío exactamente una vez son absolutamente esenciales para tu aplicación. Si la baja latencia es tu principal prioridad, minimizar el uso de estas funciones puede ayudarte a reducir los retrasos en el procesamiento de los mensajes.
Aumento del tamaño de los mensajes
Un aumento repentino del tamaño de los mensajes podría incrementar el tiempo de transferencia entre Pub/Sub y tu cliente, así como ralentizar el tiempo de procesamiento de los mensajes en el lado del cliente.
Si observa un aumento en la latencia de entrega, puede consultar el tamaño de los mensajes con la métrica topic/message_sizes, agrupando por topic_id. Correlaciona los picos en el tamaño de los mensajes con los problemas de rendimiento observados.
Faltan mensajes
Si sospechas que los mensajes no se entregan correctamente a tu suscriptor, puede deberse a uno de los siguientes motivos.
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 consumidor puede recibir menos mensajes de lo esperado o un subconjunto de mensajes diferente al de otros consumidores.
Ten en cuenta que es posible que ya haya mensajes pendientes para los clientes y que un registro de mensajes no confirmados no significa necesariamente que vayas a recibir esos mensajes en tu próxima solicitud de extracción. Ten en cuenta que un consumidor puede ser un usuario que utilice la extracción en la Google Cloud consola o en la CLI de Google Cloud, o que ejecute un suscriptor personalizado de forma local para comprobar los mensajes.
En el caso de los clientes de extracción unarios, es posible que algunas solicitudes de extracción devuelvan cero mensajes. Como se explica en la sección No hay suficientes suscriptores, se recomienda mantener varias solicitudes de extracción pendientes, ya que algunas solicitudes podrían devolver un número de mensajes inferior al máximo configurado o incluso cero mensajes.
Si sospechas que se produce alguno de estos comportamientos, investiga si hay varios consumidores conectados simultáneamente a la suscripción e inspecciónalos.
Filtrar por suscripción
Comprueba si la suscripción tiene un filtro adjunto. Si es así, solo recibirás los mensajes que coincidan con el filtro. El servicio Pub/Sub confirma automáticamente los mensajes que no coinciden con el filtro. Ten en cuenta cómo afectan los filtros a las métricas de la cartera de trabajo.
Usar la opción returnImmediately
Si tu cliente usa Pull unario, comprueba si el campo returnImmediately está definido como true. Este campo está obsoleto y indica al servicio Pub/Sub que responda a la solicitud de extracción inmediatamente, aunque no devuelva ningún mensaje. Esto puede provocar que las solicitudes de extracción devuelvan 0 mensajes aunque haya un backlog.
Problemas de configuración del cliente
Si usas la biblioteca de cliente de Java e inicializas tu suscriptor con un canal gRPC personalizado mediante el método setChannelProvider(), debes asegurarte de que el ajuste maxInboundMessageSize sea de al menos 20 MB (el valor predeterminado de la biblioteca) al compilar tu TransportChannelProvider. Si este valor es inferior a 10 MB, los mensajes que superen los maxInboundMessageSize no se recibirán correctamente. Algunos métodos habituales para configurar este ajuste son InstantiatingGrpcChannelProvider.Builder.setMaxInboundMetadataSize() y ManagedChannelBuilder.maxInboundMetadataSize().
Gestionar duplicados
La duplicación de mensajes en Pub/Sub suele producirse cuando los suscriptores no pueden confirmar los mensajes antes de la fecha límite de confirmación. Esto provoca que los mensajes se vuelvan a enviar, lo que da la impresión de que hay duplicados. Puede medir la frecuencia con la que los suscriptores no cumplen el plazo de confirmación mediante la métrica subscription/expired_ack_deadlines_count. Más información sobre cómo monitorizar la fecha de vencimiento de la confirmación
Para reducir la tasa de duplicación, amplía los plazos de los mensajes.
- Las bibliotecas de cliente gestionan la ampliación del plazo automáticamente, pero hay límites predeterminados en el plazo máximo que puedes configurar.
- Si estás creando tu propia biblioteca de cliente, usa el método
modifyAckDeadlinepara ampliar 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 caduquen y requieran ampliaciones del plazo. Sin embargo, si el suscriptor sigue agobiado, las prórrogas repetidas de los plazos acabarán fallando. En el peor de los casos, esto puede provocar que el suscriptor se vea inundado de duplicados, lo que agravará la acumulación de trabajo. Los duplicados caducados generan nuevos duplicados.
Para no abrumar al suscriptor, reduce el número de mensajes que extrae a la vez. De esta forma, el suscriptor tiene menos mensajes que procesar en el plazo indicado. Caducan menos mensajes y se vuelven a enviar menos mensajes.
Para reducir el número de mensajes que extrae el suscriptor a la vez, debes reducir el número máximo de mensajes pendientes en la configuración de control de flujo del suscriptor. No hay un valor único para todos los casos, por lo que debes ajustar el límite máximo de mensajes pendientes en función del rendimiento y la capacidad de los suscriptores. Ten en cuenta que cada aplicación procesa los mensajes de forma diferente y tarda un tiempo distinto en confirmar la recepción de un mensaje.
Forzar reintentos
Para forzar a Pub/Sub a reintentar el envío de un mensaje, envía una solicitud nack. Si no usas las bibliotecas de cliente de alto nivel, envía una solicitud modifyAckDeadline con un ackDeadlineSeconds definido como 0.
Claves de ordenación
Cuando Pub/Sub vuelve a enviar un mensaje con una clave de ordenación, también vuelve a enviar todos los mensajes posteriores con la misma clave de ordenación, aunque se hayan confirmado anteriormente. Esto se hace para mantener el orden de la secuencia. Sin embargo, no hay ninguna garantía estricta de que los mensajes dependientes solo se envíen después de que se haya confirmado la recepción de los mensajes anteriores de la secuencia.
El suscriptor está enviando NACKs a los mensajes
Consulta El suscriptor está enviando un ACK negativo a los mensajes.
Solucionar problemas de una suscripción de StreamingPull
Relación entre la métrica de latencia de las solicitudes y la latencia de entrega de extremo a extremo
En StreamingPull, la métrica serviceruntime.googleapis.com/api/request_latencies representa el tiempo durante el que está abierto el flujo. Esta métrica no es útil para determinar la latencia de entrega de principio a fin.
En lugar de usar la métrica de latencia de solicitud, utiliza la puntuación de estado de latencia de entrega para comprobar qué factores contribuyen a aumentar la latencia de entrega de extremo a extremo.
Las conexiones StreamingPull se cierran con un estado distinto de OK
Las transmisiones de StreamingPull siempre se cierran con un estado de error. A diferencia del estado de error de las llamadas RPC unarias, este estado de StreamingPull solo indica que la secuencia se ha desconectado. Las solicitudes no fallan. Por lo tanto, aunque la API StreamingPull pueda tener una tasa de errores del 100% sorprendente, este comportamiento es intencionado.
Como las secuencias de StreamingPull siempre se cierran con un error, no es útil examinar las métricas de finalización de la secuencia al diagnosticar errores. En su lugar, céntrate en la métrica de respuesta StreamingPull subscription/streaming_pull_response_count, agrupada por response_code o response_class.
Busca estos errores:
Los errores Failed precondition pueden producirse si hay mensajes en el backlog de la suscripción que están cifrados con una clave de Cloud KMS inhabilitada. Para reanudar la extracción, restaura el acceso a la clave.
Los errores de disponibilidad pueden producirse cuando Pub/Sub no puede procesar una solicitud. Lo más probable es que se trate de una condición transitoria y que la biblioteca de cliente vuelva a intentar enviar las solicitudes. No tienes que hacer nada si usas una biblioteca cliente.
Los errores de no encontrado pueden producirse cuando se elimina la suscripción o si nunca ha existido. Esto ocurre si has proporcionado una ruta de suscripción no válida.