Esta página se ha traducido con Cloud Translation API.

Solucionar problemas con un tema estándar

En este documento se ofrecen algunos consejos para solucionar problemas habituales al publicar mensajes en un tema estándar de Pub/Sub.

Consulta más información sobre cómo publicar mensajes en temas y sobre las diferentes funciones.

Latencia de publicación alta

La latencia de publicación es el tiempo que se tarda en completar una solicitud de publicación emitida por un cliente editor. La latencia de publicación es distinta de la latencia de entrega de extremo a extremo, que es el tiempo que tarda en entregarse a un cliente suscriptor un mensaje que se publica en Pub/Sub. Puede que observes una latencia de publicación o una latencia de extremo a extremo altas, aunque el valor del otro tipo de latencia sea bajo. La latencia de publicación alta se puede producir en el cliente de publicación de Pub/Sub, durante el 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 incurrida en el backend de Pub/Sub mediante la métrica topic/send_request_latencies. Una latencia de publicación backend alta puede estar relacionada con los siguientes factores:

Pub/Sub se ha diseñado para ofrecer una entrega de baja latencia y alto rendimiento. Si el tema tiene un rendimiento bajo, los recursos asociados al tema pueden tardar más en inicializarse.
Si usas una política de almacenamiento de mensajes, podría afectar a la latencia general de las solicitudes al tema y a la suscripción. Consulta las implicaciones en el rendimiento y la disponibilidad de usar esta configuración.

Si el cliente de tu editor observa una latencia de publicación significativamente mayor que la que se refleja en la métrica, podría deberse a uno de estos factores del lado del cliente:

Asegúrate de no crear un nuevo editor para cada publicación. Se recomienda usar un solo cliente de editor por tema y por aplicación para publicar todos los mensajes. Crear objetos de editor y añadir nuevos subprocesos tiene un coste de latencia. Si usas funciones de Cloud Run para publicar mensajes, ten en cuenta que las invocaciones también pueden afectar a la latencia de publicación.
Si considera que la configuración predeterminada de reintentos no es suficiente para su caso práctico, haga los ajustes correspondientes. Sin embargo, compruebe que los nuevos valores no sean demasiado altos. Consulta cómo configurar la opción Reintentar solicitudes.

Ten en cuenta que una latencia de publicación alta puede provocar errores DEADLINE_EXCEEDED, que se explican en la siguiente sección.

Las operaciones de publicación fallan con DEADLINE_EXCEEDED

Un error DEADLINE_EXCEEDED durante una solicitud de publicación indica que no se ha podido completar en el tiempo asignado. Esto puede deberse a varios factores, como que las solicitudes no lleguen al servicio Pub/Sub o que haya problemas de rendimiento que afecten a las solicitudes.

Para verificar que las solicitudes de publicación llegan al servicio Pub/Sub, monitoriza el tema con la métrica topic/send_request_count, agrupada por response_code. Esta métrica le 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 Pub/Sub. Además, para descartar la posibilidad de que se trate de un problema intermitente, comprueba la tasa de errores con el gráfico de la métrica topic/send_request_count mencionado anteriormente o en la página APIs & Services (APIs y servicios) de la consola de Google Cloud . Si la tasa de errores es muy baja, puede que se trate de un problema intermitente.

Si las solicitudes llegan a Pub/Sub, estos son algunos de los posibles motivos por los que las operaciones de publicación fallan con un error DEADLINE_EXCEEDED:

Cuello de botella del lado del cliente

Es probable que los errores de publicación se deban a un cuello de botella del lado del cliente, como memoria insuficiente, presión de la CPU, estado incorrecto de los hilos o congestión de la red en la VM que aloja al cliente del editor. Si una llamada Publish devuelve DEADLINE_EXCEEDED, puede que las llamadas Publish asíncronas se estén poniendo en cola más rápido de lo que se envían al servicio, lo que aumenta progresivamente la latencia de las solicitudes. Además, comprueba si alguno de los siguientes elementos te ayuda a determinar un posible cuello de botella en tu sistema:

Comprueba si estás publicando mensajes más rápido de lo que el cliente puede enviarlos. Normalmente, cada llamada asíncrona Publish devuelve un objeto Future. Para hacer un seguimiento del número de mensajes que están pendientes de envío, almacena el número de mensajes que se van a enviar con cada llamada Publish y elimínalo solo en la retrollamada del objeto Future.
Asegúrate de que haya suficiente ancho de banda de subida entre el equipo en el que se ejecuta el editor y Google Cloud. Las redes Wi-Fi de desarrollo suelen tener un ancho de banda de entre 1 y 10 MBps, o entre 1000 y 10.000 mensajes típicos por segundo. Publicar mensajes en un bucle sin limitar la frecuencia podría crear un breve pico de ancho de banda alto durante un periodo corto. Para evitarlo, puedes ejecutar el editor en un equipo que esté dentro de Google Cloud o reducir la frecuencia con la que publicas los mensajes para que coincida con el ancho de banda disponible.
Comprueba si hay una latencia muy alta entre tu host y Google Cloud por alguno de los motivos, como la congestión de la red de inicio o los cortafuegos. En Calcular el rendimiento de la red se explica cómo averiguar el ancho de banda y la latencia en diferentes situaciones.
En última instancia, hay límites en la cantidad de datos que puede publicar una sola máquina. Es posible que tengas que intentar escalar horizontalmente o ejecutar varias instancias del cliente editor en varios equipos. En Prueba de clientes de Cloud Pub/Sub para maximizar el rendimiento del streaming se muestra cómo se escala Pub/Sub en una sola Google Cloud VM con un número creciente de CPUs. Por ejemplo, puedes alcanzar entre 500 y 700 MBps para mensajes de 1 KB en una instancia de Compute Engine de 16 núcleos.

Duración de tiempo de espera de publicación inadecuada

Para reducir la tasa de tiempo de espera de las llamadas de publicación, asegúrese de que el tiempo de espera definido en los ajustes de reintento del cliente editor sea lo suficientemente largo. En la configuración de reintentos, define el plazo inicial en 10 segundos y el tiempo de espera total en 600 segundos. Aunque no acumules un gran número de mensajes sin enviar, los picos ocasionales en la latencia de las solicitudes pueden provocar 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 a tiempos de espera ocasionales, volver a intentar la operación más veces podría provocar más errores.

Problemas con las bibliotecas de cliente

Es posible que estés usando 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 de cliente. Si detectas un problema conocido que afecta a la versión de la biblioteca de cliente que estás usando, actualízala a la versión más reciente. De esta forma, te aseguras de que has recibido todas las actualizaciones pertinentes, incluidas las correcciones y las mejoras de rendimiento.

Problemas con el esquema

Si tus publicaciones empiezan a devolver INVALID_ARGUMENT, es posible que alguien haya actualizado el tema para cambiar el esquema asociado, haya eliminado el esquema o haya eliminado las revisiones del esquema asociadas al tema. En este caso, actualiza la configuración del esquema del tema a un esquema y a 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 el cifrado de mensajes

Si has configurado tu tema de Pub/Sub para cifrar los mensajes publicados con una clave de cifrado gestionada por el cliente, es posible que la publicación falle y se produzca un error FAILED_PRECONDITION. Este error puede producirse si la clave de Cloud KMS está inhabilitada o si ya no se puede acceder a las claves gestionadas de forma externa a través de Cloud EKM. Para reanudar la publicación, restaura el acceso a la clave.

Problemas con la transformación de un solo mensaje (SMT)

Si has configurado SMTs en tu tema de Pub/Sub, es posible que la publicación falle y se produzcan errores INVALID_ARGUMENT cuando no se puedan aplicar transformaciones a los mensajes. Si falla la transformación de algún mensaje de un lote de publicación, no se podrá publicar todo el lote. El error devuelto indica el motivo del fallo. 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.

Monitorizar SMTs

Para conocer el rendimiento y el impacto de las SMTs en un tema, usa las siguientes métricas de monitorización:

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

La métrica proporciona dos etiquetas clave:

status: indica si la transformación se ha realizado correctamente o si se ha producido un problema.
filtered: indica si el SMT ha provocado que el mensaje se filtre. Cuando un SMT filtra un mensaje en un tema, Pub/Sub descarta el mensaje y este nunca se envía a los suscriptores. Esta etiqueta filtered solo es verdadera cuando un SMT realiza el filtrado. Los mensajes filtrados mediante las funciones 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 por SMTs o en los que los SMTs han fallado. Busca estos valores específicos:

Cuando un SMT filtra un mensaje, el valor de operation_type es smt_publish_filter_drop.
Si un SMT no puede transformar un mensaje, verás un response_code que no es OK.

Siguientes pasos

Consulta la monitorización de OpenTelemetry para depurar la latencia de publicación.

Solucionar problemas con un tema estándar Organízate con las colecciones Guarda y clasifica el contenido según tus preferencias.