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 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 en entregarse a un cliente suscriptor un mensaje que se publica en Pub/Sub. Es posible que observes una latencia de publicación o de extremo a extremo alta, incluso cuando el valor del otro tipo de latencia es bajo. La latencia de publicación alta se puede generar 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 topic/send_request_latencies métrica. La latencia de publicación alta 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, los recursos asociados con el tema 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 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, podría ser un signo 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 por aplicación para publicar todos los mensajes. Activar objetos publicadores 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 descubres 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 la 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 completó dentro del tiempo asignado. Esto puede deberse a varios factores, como que las solicitudes no lleguen al servicio de Pub/Sub o problemas de rendimiento que afecten las solicitudes.

Para verificar que las solicitudes de publicación lleguen al servicio de Pub/Sub, supervisa el tema con la topic/send_request_count métrica, 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, verifica la tasa de errores con el gráfico de la métrica topic/send_request_count que se mencionó anteriormente o la página APIs y servicios en la Google Cloud consola. Si la tasa de errores es muy baja, podría ser 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 CPU, mal estado del subproceso o congestión de la red en la VM que aloja el cliente publicador. Si una llamada a Publish muestra 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 asíncrona Publish muestra un Future objeto. 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 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 Google Cloud. Las redes Wi-Fi de desarrollo suelen tener 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, 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 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 Google Cloud 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. Probar clientes de Cloud Pub/Sub para maximizar el rendimiento de la transmisión demuestra cómo Pub/Sub escala en una sola Google Cloud VM 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. Para la configuración de reintento, 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 en la latencia de solicitud pueden hacer 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. La siguiente lista incluye las herramientas de seguimiento de errores para todas las bibliotecas cliente. Si encuentras un problema conocido que afecta la versión de la biblioteca cliente que usas, actualiza a la versión más reciente de la biblioteca cliente. Esto garantiza que hayas tomado las actualizaciones relevantes, incluidas las correcciones y las mejoras en el rendimiento.

Problemas de esquema

Si tus publicaciones comienzan a mostrar INVALID_ARGUMENT, es posible que alguien haya actualizado el tema para cambiar el esquema asociado schema, borrado el esquema, o 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 de 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, la publicación podría fallar 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 externamente a través de Cloud EKM. Para reanudar la publicación, restablece el acceso a la clave.

Problemas de la política de almacenamiento de mensajes

Si tus suscripciones no reciben mensajes publicados, es posible que el tema tenga una política de almacenamiento de mensajes vigente. Si es así, es posible que veas errores FAILED_PRECONDITION en tus métricas de publicación.

Por lo general, estos errores contienen mensajes como los siguientes:

Cannot publish messages that contain ordering keys
to topic projects/...  due a message storage policy on the topic that would
require the messages to be forwarded to another region. Please either change
the topic's message storage policy or publish to an allowed region using
the appropriate regional Cloud Pub/Sub endpoint.

o

The topic's message storage policy requires enforcement
in transit, but the Publish request was received by a Pub/Sub server in
a non-allowed region. Please either publish via a regional Pub/Sub endpoint
corresponding to an allowed region, or update the topic's message storage policy.

Para solucionar este problema, realiza una de las siguientes acciones:

  • Actualiza la política de almacenamiento de mensajes del tema para permitir la región.
  • Configura tu cliente publicador para publicar en una región permitida con el extremo regional de Pub/Sub adecuado.

Problemas de la transformación de mensaje único (SMT)

Si configuraste SMT en tu tema de Pub/Sub, la publicación podría fallar con INVALID_ARGUMENT errores cuando no se puedan aplicar las transformaciones a los mensajes. Si algún mensaje de un lote de publicación no se transforma, no se publicará todo el lote. El error que se muestra indica el motivo de la falla, 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 las SMT

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

La métrica topic/message_transform_latencies mide cuánto tardan las SMT en aplicarse a un mensaje. La métrica solo mide la latencia de 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 la SMT hizo que se filtrara el mensaje. Cuando una SMT filtra un mensaje en un tema, Pub/Sub descarta el mensaje y nunca se envía a los suscriptores. Esta etiqueta filtered es verdadera solo cuando una 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 se filtran con SMT o en los que fallaron las SMT. Busca estos valores específicos:

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

  • Si una 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.