En este documento, se proporcionan algunas sugerencias comunes para la solución de problemas cuando se publican mensajes en un tema estándar de Pub/Sub.
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 se tarda en 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 alta o una latencia de extremo a extremo, incluso cuando el valor del otro tipo de latencia es bajo. El cliente publicador de Pub/Sub puede generar una latencia de publicación alta, ya sea 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 alta latencia 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 tiempo 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 del uso de 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, esto podría ser un indicador de uno de estos factores del cliente:
Asegúrate de no crear un publicador nuevo para cada publicación. Se recomienda usar un solo cliente publicador por tema y por aplicación para publicar todos los mensajes. La puesta en marcha de objetos de publicador nuevos y la adición de subprocesos nuevos tiene un costo de latencia. Si usas Cloud Functions para publicar mensajes, ten en cuenta que las invocaciones también pueden afectar la latencia de publicación.
Si notas que la configuración predeterminada de reintentos 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, 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, consulta la tasa de errores. 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 causas posibles por las que las operaciones de publicación fallan 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 en el lado del cliente, como memoria insuficiente, presión de la CPU, mal estado de los subprocesos o congestión de la red en la VM que aloja al cliente 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 tu 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 MB/s o de 1,000 a 10,000 mensajes típicos por segundo. Publicar mensajes en un bucle sin ningún límite de frecuencia podría crear un pico de actividad breve de ancho de banda alto en un período corto. 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 ves una latencia muy alta entre tu host y Google Cloud por alguno de los motivos, como la congestión de la red del 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. Probar 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 cantidad creciente de CPU. Por ejemplo, puedes alcanzar entre 500 MB/s y 700 MB/s 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 para las llamadas de publicación, asegúrate de definir un tiempo de espera lo suficientemente largo en la configuración de reintentos 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 ocasionales en la latencia de la solicitud pueden hacer que se agote el tiempo de espera de las llamadas de publicación. Sin embargo, si los problemas se deben a 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 de la biblioteca cliente
Es posible que estés ejecutando una versión de la biblioteca cliente con un problema conocido. En la siguiente lista, se incluyen las herramientas de seguimiento de errores de todas las bibliotecas cliente. Si encuentras un problema conocido que afecta a la versión de la biblioteca cliente que estás usando, actualízala a la última versión. De esta manera, te aseguras de haber seleccionado las actualizaciones relevantes, incluidas las correcciones y las mejoras de rendimiento.
C++
Herramienta de seguimiento de errores de la biblioteca cliente
C#
Herramienta de seguimiento de errores de la biblioteca cliente
Go
Herramienta de seguimiento de errores de la biblioteca cliente
Java
Herramienta de seguimiento de errores de la biblioteca cliente
Node.js
Herramienta de seguimiento de errores de la biblioteca cliente
PHP
Herramienta de seguimiento de errores de la biblioteca cliente
Python
Herramienta de seguimiento de errores de la biblioteca cliente
Rita
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, borrado el esquema o borrado las revisiones del esquema asociadas con el tema. En este caso, actualiza la configuración de 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 de encriptación de mensajes
Si configuraste tu tema de Pub/Sub para encriptar mensajes publicados con una clave de encriptación administrada por el cliente, la publicación podría fallar y mostrar el 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.