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 Stackdriver Monitoring los 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 su plazo de confirmación, Pub/Sub lo reenvía. Como resultado, Pub/Sub puede enviar mensajes duplicados. Usa Stackdriver para supervisar operaciones de confirmación con el código de respuesta expired para detectar esta condición. Para 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 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 predeterminados para el plazo de extensión máxima que se puede 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.

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
    }