Soluciona problemas

Obtén información sobre los pasos para solucionar problemas que pueden servirte si tienes dificultades con Pub/Sub.

No se puede crear una suscripción

Comprueba si completaste estos pasos:

  • Especificaste un nombre de suscripción en el campo name. Para la versión v1beta2 y posteriores, el nombre de la suscripción debe tener el formato projects/project-identifier/subscriptions/subscription-name.
  • Especificaste el nombre de un tema existente al que deseas suscribirte, en el campo topic. Para la versión v1beta2 y posteriores, el nombre del tema debe tener el formato projects/project-identifier/topics/topic-name.
  • Especificaste https:// en minúsculas (ni http:// ni HTTPS://) como protocolo para tu URL de recepción en el campo pushEndpoint.

El suscriptor de envío no recibe ningún mensaje

Verifica lo siguiente:

  • Busca en Cloud Monitoring errores relacionados con la suscripción en cuestión.
  • En App Engine, te recomendamos que uses el prefijo /_ah/push-handlers/ en la ruta de URL de los extremos, como se describe en la página sobre cómo registrar extremos de App Engine. Este código permite que el extremo reciba mensajes de envío de la API de Pub/Sub.
  • En otros entornos, asegúrate de que se pueda acceder a tu URL del extremo desde Internet sin necesidad de iniciar sesión. Para verificar que la URL no esté restringida, accede a ella con una herramienta de diagnóstico, como cURL.
  • En el caso de dominios que no sean appspot.com, asegúrate de registrarlos en Google Cloud Console. Consulta la página sobre cómo registrar otros extremos para obtener más detalles.

La entrega de mensajes de envío tarda horas

Un mensaje de envío no confirmado puede retrasar la entrega de nuevos. No se confirma un mensaje si el extremo de envío falla o muestra un código de estado distinto de 200, 201, 202, 204 o 102. Si deseas solucionar la demora, actualiza el código del extremo para controlar los mensajes con fallas o extráelos de forma manual y, luego, confírmalos. Consulta la descripción general de Monitoring para obtener más información sobre la detección de mensajes no confirmados y la creación de alertas.

Error 403 (Forbidden)

Si recibes este error, haz lo siguiente:

  • Asegúrate de que habilitaste la API de Pub/Sub en Cloud Console.
  • Asegúrate de que la cuenta principal que realiza la solicitud tenga los permisos necesarios en los recursos relevantes de la API de Pub/Sub, en especial, si usas la API de Pub/Sub para la comunicación entre proyectos.
  • Si usas Dataflow, asegúrate de que <projectId>@cloudservices.gserviceaccount.com y la cuenta de servicio de Compute Engine <projectId>-compute@developer.gserviceaccount.com tengan los permisos necesarios en el recurso de la API de Pub/Sub relevante. Consulta Seguridad y permisos de Cloud Dataflow para obtener más información.
  • Si usas App Engine, revisa la página de permisos de tu proyecto para ver si alguna cuenta de servicio de App Engine aparece con la función de Editor. Si no es así, agrega tu cuenta de servicio de App Engine con la función de Editor. Por lo general, la cuenta de servicio de App Engine tiene el formato <project-id>@appspot.gserviceaccount.com.

Detecta mensajes duplicados y fuerza reintentos

Cuando no confirmas un mensaje antes de que venza el plazo de confirmación, Pub/Sub vuelve a enviar el mensaje. Como resultado, Pub/Sub puede enviar mensajes duplicados. Usa el paquete de operaciones de Google Cloud para supervisar operaciones de confirmación con el código de respuesta expired para detectar esta condición. Si quieres obtener estos datos, selecciona la métrica Operaciones de confirmación de mensajes (Acknowledge message operations) y, luego, agrúpala o fíltrala por la etiqueta response_code. Ten en cuenta que response_code es una etiqueta del sistema en una métrica; no es una métrica.

Usa Stackdriver para buscar plazos límite de confirmación de mensajes vencidos.

Para reducir la tasa de duplicación, extiende el plazo del mensaje.

  • Las bibliotecas cliente manejan la extensión de plazos de forma automática, pero debes tener en cuenta que existen límites máximos predeterminados para la extensión que se pueden configurar.
  • Si creas tu propia biblioteca cliente, usa el método modifyAckDeadline para extender el plazo de confirmación.

Como alternativa, para forzar a Pub/Sub a volver a enviar un mensaje, establece modifyAckDeadline en 0.

Las operaciones de publicación fallan con DEADLINE_EXCEEDED

Es probable que esto se deba a un cuello de botella del lado del cliente, como CPU de servicio insuficientes, mal estado de los subprocesos o congestión de red. Si una llamada Publish muestra DEADLINE_EXCEEDED, las llamadas Publish asíncronas se ponen en cola más rápido que las que se envían al servicio, lo que aumenta progresivamente la latencia de la solicitud. A fin de determinar la capacidad de procesamiento de Publish con una sola VM para diferentes parámetros (núcleos, trabajadores, tamaño del mensaje), consulta Prueba clientes de Cloud Pub/Sub a fin de maximizar el rendimiento de transmisión. Como alternativa, puedes ejecutar una versión de la biblioteca cliente con un problema conocido. verifica el seguimiento de problemas de tu biblioteca cliente en la lista.

Por último, puedes establecer un plazo inferior al rendimiento de latencia de publicación típico de Pub/Sub (se recomienda establecer el plazo inicial en 10 segundos y el tiempo de espera total en 600 segundos).

Comprueba si alguna de las siguientes opciones es útil:

  • Comprueba si publicas mensajes más rápido de lo que el cliente puede enviar. Por lo general, cada llamada Publish asíncrona muestra un objeto Future. Para realizar un seguimiento de la cantidad de mensajes en espera de envío, almacene la cantidad de mensajes que se enviarán con esta llamada de publicación y bórrelos solo en la devolución de llamada del objeto Future. Cuando realizas llamadas Publish más rápidas que las solicitudes correspondientes al servicio de Pub/Sub, la latencia de una llamada Publish individual aumentará drásticamente.
  • Comprueba que tienes suficiente ancho de banda de carga entre la máquina en la que se ejecuta el publicador y Google Cloud. Es común que las redes Wi-Fi que se usan para el desarrollo tengan un ancho de banda de 1 a 10 MB/s, o 1,000 a 10,000 mensajes típicos por segundo. Publicar estos mensajes en un bucle, sin ningún límite de frecuencia, puede crear una breve ráfaga de ancho de banda alto durante un período corto. Es posible que obtenga más ancho de banda si ejecuta el publicador en una máquina dentro de GCP o reduce la velocidad a la que publica los mensajes para que coincidan con su ancho de banda disponible.
  • Asegúrate de tener un tiempo de espera suficiente para la llamada definida en la configuración de reintento. Habrá casos en los que los aumentos de latencia de la solicitud generen errores, incluso si no acumulas una gran cantidad de mensajes pendientes. Aumentar el plazo inicial a 10 segundos y el tiempo de espera total a 600 segundos genera una disminución en la tasa de tiempos de espera. Ten en cuenta que si tus problemas son causados por un cuello de botella persistente, en lugar de tiempos de espera ocasionales, volver a intentarlo más veces generará más errores.
  • Comprueba si ves una latencia muy alta entre tu host y Google Cloud por alguna de las razones, como la congestión de la red de inicio o los firewalls. El cálculo de la capacidad de procesamiento de la red tiene indicadores sobre cómo averiguar el ancho de banda y la latencia para diferentes situaciones.
  • Actualiza a la versión más reciente de la biblioteca cliente. Asegúrate de haber seleccionado las actualizaciones relevantes que podrían incluir correcciones, como mejoras en el rendimiento.
  • Verifica si la VM que aloja el cliente del publicador se está quedando sin recursos, incluidos CPU, RAM y subprocesos. Es posible que la llamada esté programada mucho tiempo antes de realizar una solicitud al servicio.
  • En última instancia, hay una cantidad limitada de datos que puede publicar una sola máquina. Es posible que deba escalar horizontalmente o ejecutar varias instancias del cliente del publicador en varias máquinas. Probar clientes de Cloud Pub/Sub para maximizar el rendimiento de transmisión demuestra cómo Pub/Sub escala en una sola VM de Google Cloud con una cantidad cada vez mayor de CPU. Por ejemplo, puedes alcanzar entre 500 MB y 700 MB / s para mensajes de 1 KB en una instancia de 16 núcleos de Compute Engine.

Uso de operaciones administrativas excesivas

Si descubres que consumes demasiado tu cuota para operaciones administrativas, es posible que debas reestructurar el código. A modo de ilustración, considera este seudocódigo. En este ejemplo, se usa una operación administrativa (GET) para verificar la presencia de una suscripción antes de que intente consumir sus recursos. GET y CREATE son operaciones administrativas:


    if !GetSubscription my-sub {
     CreateSubscription my-sub
    }
    Consume from subscription my-sub
            

Una opción más eficaz es intentar consumir los mensajes de la suscripción (siempre que puedas estar seguro del nombre de la suscripción). Con este enfoque optimista, solo obtienes o creas la suscripción si hay un error. Considera el siguiente ejemplo:

    try {
      Consume from subscription my-sub
    } catch NotFoundError {
      CreateSubscription my-sub
      Consume from subscription my-sub
    }