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.

Se produjo un error en las operaciones de publicación con DEADLINE_EXCEEDED

Es posible que esto se deba a un cuello de botella del cliente, como CPU de servicio insuficientes, mal estado del subproceso o congestión en la red. Si una llamada a Publish muestra DEADLINE_EXCEEDED, las llamadas 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. 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 los clientes de Cloud Pub/Sub para maximizar el rendimiento de la transmisión. También puedes ejecutar una versión de la biblioteca cliente con un problema conocido. Revisa la herramienta de seguimiento de errores de la biblioteca cliente de la lista.

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

Verifica si alguna de las siguientes opciones ayuda:

  • 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 esta llamada de publicación y bórralo solo en la devolución de llamada del objeto Future. Cuando realizas llamadas Publish más rápido que las solicitudes correspondientes al servicio de Pub/Sub se puede completar, la latencia para una llamada Publish individual posterior aumentará en forma drástica.
  • Verificar que se tiene 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 de 1,000 a 10,000 mensajes típicos por segundo. Publicar estos mensajes en un bucle, sin límite de frecuencia, puede crear un aumento de actividad de ancho de banda durante un período breve. Puedes obtener más ancho de banda si ejecutas el publicador en una máquina dentro de GCP o si reduces la tasa a la que publicas los mensajes para que coincidan con tu ancho de banda disponible.
  • Asegurarse de tener un tiempo de espera suficiente para la llamada que se define en la configuración de reintento. Habrá casos en los que los aumentos repentinos de latencia de solicitud generen errores, incluso si no acumulas una gran cantidad de mensajes pendientes no enviados. Aumentar el plazo inicial a 10 segundos y el tiempo de espera total a 600 segundos genera una caída en la tasa de tiempos de espera. Ten en cuenta que si los problemas se producen por un cuello de botella persistente, en lugar de tiempos de espera ocasionales, volver a intentarlo más veces generará más errores.
  • 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.
  • Actualizar a la versión más reciente de la biblioteca cliente. Asegúrate de haber tomado las actualizaciones relevantes que puedan incluir correcciones, como mejoras en el rendimiento.
  • Verificar si la VM que aloja el cliente publicador se queda sin recursos, incluidos CPU, RAM y los subprocesos. Esto puede deberse a que la llamada espera mucho tiempo para programarse, antes de realizar una solicitud al servicio.
  • 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 VM de Google Cloud 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.

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
    }