Cómo solucionar problemas de un tema estándar

En este documento, se proporcionan algunas sugerencias comunes para solucionar 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 sobre 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 emitida por un cliente publicador. La latencia de publicación es diferente de la latencia de entrega de extremo a extremo, que es la cantidad de tiempo que tarda en entregarse a un cliente suscriptor un mensaje que se publica en Pub/Sub. Es posible que observes una latencia de publicación o una latencia de extremo a extremo altas, 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 produce 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 ofrecer una entrega de baja latencia y alta capacidad de procesamiento. Si el tema tiene una capacidad de procesamiento baja, los recursos asociados con él podrían tardar 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 los siguientes 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. Crear objetos de publicador nuevos y agregar subprocesos nuevos tiene un costo de latencia. Si usas Cloud Run Functions para publicar mensajes, ten en cuenta que las invocaciones también pueden afectar la latencia de publicación.

  • Si observas 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 explican 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 completó dentro del 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 afectan las solicitudes.

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 que se trate de un problema intermitente, verifica la tasa de error con el gráfico de la métrica topic/send_request_count que se mencionó anteriormente o la página APIs & Services en la consola de Cloud de Confiance . Si la tasa de errores es muy baja, podría tratarse de un problema intermitente.

Si las solicitudes llegan a Pub/Sub, estas son algunas 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 la red en la VM que aloja el cliente del publicador. Si una llamada a Publish devuelve DEADLINE_EXCEEDED, es posible que las llamadas Publish asíncronas se pongan 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 Publish asíncrona muestra un objeto Future. Para realizar un seguimiento de la cantidad de mensajes que se deben enviar, almacena la cantidad de mensajes que se enviarán con cada llamada de Publish y bórralo solo en la devolución de llamada del objeto Future.

  • Asegúrate de tener suficiente ancho de banda de carga entre la máquina en la que se ejecuta el publicador y Cloud de Confiance by S3NS. 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 límite de frecuencia podría 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 Cloud de Confiance by S3NS o reducir la tasa a la que publicas los mensajes para que coincidan con tu ancho de banda disponible.

  • Verificar si se observa una latencia muy alta entre el host y Cloud de Confiance by S3NS por alguno de los motivos, como la congestión de la red de inicio o los firewalls. El cálculo de la capacidad de procesamiento de la red ofrece consejos para detectar el ancho de banda y la 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 de forma horizontal 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 se ajusta en una sola VM de Cloud de Confiance con una mayor cantidad de CPU. Por ejemplo, puedes alcanzar 500 MB/s en 700 MB/s para mensajes de 1 KB en una instancia de 16 núcleos de Compute Engine.

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 lo suficientemente largo definido en la configuración de reintento del cliente publicador. En 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 provocar que se agote el tiempo de espera de las llamadas de publicación. 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 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 los sistemas de seguimiento de problemas de todas las bibliotecas cliente. Si encuentras un problema conocido que afecta la versión de la biblioteca cliente que usas, actualízala a la versión más reciente. Esto garantiza que hayas tomado las actualizaciones pertinentes, incluidas las correcciones y las mejoras de rendimiento.

Problemas de esquema

Si tus publicaciones comienzan a devolver 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 al 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 bien 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 y muestre 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.

Problemas con las transformaciones de mensaje único (SMT)

Si configuraste SMTs en tu tema de Pub/Sub, es posible que la publicación falle con errores INVALID_ARGUMENT cuando no se puedan aplicar transformaciones a los mensajes. Si algún mensaje de un lote de publicación no se puede transformar, no se publicará todo el lote. El error que se devuelve indica el motivo del error, por ejemplo:

INVALID_ARGUMENT: Pub/Sub failed to apply a message transformation to one or
more messages in the publish request. Error: Failed to execute JavaScript UDF:
`my_function`. Return value is not an object.

Supervisa los SMT

Para comprender el rendimiento y el impacto de los SMT en un tema, usa las siguientes métricas de supervisión:

La métrica topic/message_transform_latencies mide el tiempo que tardan los SMT en aplicarse a un mensaje. La métrica solo mide la latencia del SMT y no incluye otras partes del tiempo de entrega del mensaje.

La métrica proporciona dos etiquetas clave:

  • status: Informa si la transformación se realizó correctamente o si se produjo un problema.

  • filtered: Indica si el SMT provocó que se filtrara el mensaje. Cuando un SMT filtra un mensaje en un tema, Pub/Sub descarta el mensaje y este nunca se envía a los suscriptores. La etiqueta filtered es verdadera solo cuando un SMT realiza el filtrado. Los mensajes filtrados con las capacidades de filtrado integradas de Pub/Sub no se reflejan en esta métrica específica.

La métrica topic/byte_cost se usa para identificar los mensajes que filtran los SMT o en los que fallaron los SMT. Busca estos valores específicos:

  • Cuando un SMT filtra un mensaje, operation_type es smt_publish_filter_drop.

  • Si un SMT no puede transformar un mensaje, verás un response_code que no es OK.

¿Qué sigue?

Explora el seguimiento de OpenTelemetry para ayudarte a depurar la latencia de publicación.