En este documento, se proporcionan algunas sugerencias comunes para solucionar problemas cuando se publican mensajes en un tema de Pub/Sub estándar.
Obtén más información para publicar mensajes en temas y las diferentes funciones.
Latencia de publicación alta
La latencia de publicación es la cantidad de tiempo que lleva completar una solicitud de publicación que emite un cliente publicador. La latencia de publicación es distinta de la latencia de entrega de extremo a extremo, que es la cantidad de tiempo que tarda un mensaje publicado en Pub/Sub en entregarse a un cliente suscriptor. Es posible que observes una latencia de publicación o de extremo a extremo alta, incluso cuando el valor del otro tipo de latencia sea bajo. Se puede incurrir en una latencia de publicación alta en el cliente publicador de Pub/Sub, en tránsito entre el cliente y el backend de Pub/Sub, o en el backend de Pub/Sub. Puedes inspeccionar la latencia de publicación que se genera en el backend de Pub/Sub con la métrica topic/send_request_latencies. La latencia alta de publicación del backend podría estar relacionada con los siguientes factores:
Pub/Sub está diseñado para la entrega de baja latencia y alta capacidad de procesamiento. Si el tema tiene una capacidad de procesamiento baja, es posible que los recursos asociados con él tarden más en inicializarse.
Si usas una política de almacenamiento de mensajes, podría afectar la latencia general de las solicitudes al tema y la suscripción. Consulta las Implicaciones de rendimiento y disponibilidad de usar esta configuración.
Si tu cliente publicador observa una latencia de publicación significativamente más alta que la que se refleja en la métrica, podría ser un signo de uno de estos factores del cliente:
Asegúrate de no crear un editor nuevo para cada publicación. Se recomienda usar un solo cliente publicador por tema y por aplicación para publicar todos los mensajes. El inicio de nuevos objetos del publicador y la adición de subprocesos nuevos tienen un costo de latencia. Si usas funciones de Cloud Run para publicar mensajes, ten en cuenta que las invocaciones también pueden afectar la latencia de publicación.
Si consideras que la configuración de reintento predeterminada no es suficiente para tu caso de uso, realiza los ajustes correspondientes. Sin embargo, verifica que los valores nuevos no sean demasiado altos. Consulta cómo configurar las solicitudes de reintento.
Ten en cuenta que una latencia de publicación alta puede generar errores DEADLINE_EXCEEDED, que se analizan en la siguiente sección.
Se produjo un error en las operaciones de publicación con DEADLINE_EXCEEDED
Un error DEADLINE_EXCEEDED durante una solicitud de publicación indica que la solicitud no se pudo completar en el tiempo asignado. Esto podría deberse a varios factores, como que las solicitudes no llegan al servicio de Pub/Sub o que hay problemas de rendimiento que las afectan.
Para verificar que las solicitudes de publicación lleguen al servicio de Pub/Sub, supervisa el tema con la métrica topic/send_request_count, agrupada por response_code. Esta métrica te ayuda a determinar si las solicitudes fallan antes de llegar al tema de Pub/Sub. Si la métrica está vacía, significa que hay un factor externo que impide que los mensajes lleguen al servicio de Pub/Sub. Además, para descartar la posibilidad de un problema intermitente, comprueba la tasa de errores con el gráfico de métricas topic/send_request_count mencionado anteriormente o con el menú de APIs & Servicios de la consola de Google Cloud. Si la tasa de errores es muy baja, este podría ser un problema intermitente.
Si las solicitudes llegan a Pub/Sub, estas son algunas de las posibles causas de que las operaciones de publicación fallen con un error DEADLINE_EXCEEDED:
Cuello de botella del cliente
Es probable que las fallas de publicación se deban a un cuello de botella del cliente, como memoria insuficiente, presión de la CPU, mal estado del subproceso o congestión de red en la VM que aloja al cliente del publicador. Si una llamada a Publish muestra DEADLINE_EXCEEDED, podría deberse a que las llamadas a Publish asíncronas se ponen en cola más rápido de lo que se envían al servicio, lo que aumenta la latencia de la solicitud de forma progresiva. Además, verifica si alguna de las siguientes opciones ayuda a determinar un posible cuello de botella en el sistema:
Verificar si se publican mensajes más rápido de lo que el cliente puede enviarlos. Por lo general, cada llamada
Publishasíncrona muestra un objetoFuture. Para realizar un seguimiento de la cantidad de mensajes en espera para enviarse, almacena la cantidad de mensajes que se enviarán con cada llamada aPublishy bórrala solo en la devolución de llamada del objetoFuture.Asegúrate de tener suficiente ancho de banda de carga entre la máquina en la que se ejecuta el publicador y Google Cloud. Por lo general, las redes Wi-Fi de desarrollo tienen un ancho de banda de 1 a 10 Mbps o de 1,000 a 10,000 mensajes típicos por segundo. Publicar mensajes en un bucle sin límite de frecuencia puede crear un aumento de actividad de ancho de banda durante un período breve. Para evitar esto, puedes ejecutar el publicador en una máquina dentro de Google Cloud o reducir la velocidad a la que publicas los mensajes para que coincidan con tu ancho de banda disponible.
Verifica si se observa una latencia muy alta entre el host y Google Cloud por alguno de los motivos, como la congestión de la red de inicio o los firewalls. Calcular la capacidad de procesamiento de la red tiene sugerencias para descubrir tu ancho de banda y latencia en diferentes situaciones.
Por último, se aplican límites sobre la cantidad de datos que puede publicar una sola máquina. Es posible que debas intentar escalar horizontalmente o ejecutar varias instancias del cliente publicador en varias máquinas. Prueba los clientes de Cloud Pub/Sub para maximizar el rendimiento de la transmisión demuestra cómo Pub/Sub escala en una sola VM de Google Cloud con una mayor cantidad de CPU. Por ejemplo, puedes alcanzar de 500 MBps a 700 MBps para mensajes de 1 KB en una instancia de Compute Engine de 16 núcleos.
Duración inadecuada del tiempo de espera de publicación
Para reducir la tasa de tiempo de espera de las llamadas de publicación, asegúrate de tener un tiempo de espera suficiente definido en la configuración de reintento del cliente publicador. Para la configuración de reintentos, establece el plazo inicial en 10 segundos y el tiempo de espera total en 600 segundos. Incluso si no acumulas una gran cantidad de mensajes pendientes no enviados, los aumentos repentinos ocasionales de latencia de solicitud pueden hacer que las llamadas de publicación se agoten. Sin embargo, si los problemas se producen por un cuello de botella persistente, en lugar de tiempos de espera ocasionales, volver a intentarlo más veces podría generar más errores.
Problemas con las bibliotecas cliente
Es posible que estés ejecutando una versión de la biblioteca cliente con un problema conocido. La siguiente lista incluye los sistemas de seguimiento de problemas de todas las bibliotecas cliente. Si encuentras un problema conocido que afecta a la versión de la biblioteca cliente que usas, actualízala a la versión más reciente. De esta manera, te aseguras de haber seleccionado las actualizaciones relevantes, incluidas las correcciones y las mejoras de rendimiento.
C++
Herramienta de seguimiento de problemas de bibliotecas cliente
C#
Herramienta de seguimiento de problemas de bibliotecas cliente
Go
Herramienta de seguimiento de errores de la biblioteca cliente
Java
Herramienta de seguimiento de problemas de bibliotecas cliente
Node.js
Herramienta de seguimiento de problemas de bibliotecas cliente
PHP
Herramienta de seguimiento de errores de la biblioteca cliente
Python
Herramienta de seguimiento de problemas de bibliotecas cliente
Ruby
Herramienta de seguimiento de errores de la biblioteca cliente
Problemas de esquema
Si tus publicaciones comienzan a mostrar INVALID_ARGUMENT, es posible que alguien haya actualizado el tema para cambiar el esquema asociado, haya borrado el esquema o haya borrado las revisiones del esquema asociadas con el tema. En este caso, actualiza la configuración del esquema del tema a un esquema y un conjunto de revisiones que coincidan con los mensajes que se publican, o ajusta el formato del mensaje para que coincida con el esquema actual.
Problemas con la encriptación de mensajes
Si configuraste tu tema de Pub/Sub para encriptar los mensajes publicados con una clave de encriptación administrada por el cliente, es posible que la publicación falle con un error FAILED_PRECONDITION. Este error puede ocurrir si la clave de Cloud KMS está inhabilitada o si ya no se puede acceder a las claves administradas de forma externa a través de Cloud EKM. Para reanudar la publicación, restablece el acceso a la clave.