Entrega de inserción de mensajes e reintento con temas de espacio de nombres

Los espacios de nombres de Event Grid entrega de inserción proporcionan una entrega duradera. Event Grid intenta entregar cada mensaje al menos una vez para cada suscripción coincidente inmediatamente. Si el punto de conexión de un suscriptor no reconoce la recepción de un evento o se produce un error, Event Grid reintenta la entrega según una programación de reintentos fija y una directiva de reintentos. De forma predeterminada, Event Grid entrega un evento cada vez al suscriptor.

Nota:

Event Grid no garantiza el orden de entrega de los eventos, por lo que los suscriptores pueden recibirlos de forma desordenada.

Suscripción a eventos

Una suscripción a eventos es un recurso de configuración asociado a un único tema de espacio de nombres. Entre otras cosas, la suscripción a eventos se usa para establecer los criterios de selección de eventos que definen la colección de eventos disponible para un suscriptor del conjunto total de eventos disponibles en un tema. Con una suscripción de eventos, también se define el punto de conexión de destino al que se envían los eventos. Además, una suscripción de eventos permite establecer otras propiedades, como el número máximo de reintentos de entrega y el tiempo de vida de los eventos, que definen el comportamiento del tiempo de ejecución de la entrega de eventos.

Programación de reintentos

Cuando Event Grid recibe un error para un intento de entrega de eventos, Event Grid decide si debe reintentar la entrega en función del tipo de error.

Si el error devuelto por el punto de conexión suscrito es un error relacionado con la configuración que no se puede corregir con reintentos, Event Grid envía el evento a un destino de mensajes fallidos configurado. Si no hay mensajes fallidos configurados, se anula el evento. Por ejemplo, un evento se envía a mensajes fallidos o se anula cuando no se puede acceder al punto de conexión configurado en la suscripción de eventos porque se eliminó. El reintento de entrega no se produce para las siguientes condiciones y errores:

Condiciones:

• ArgumentException
• TimeoutException
• UnauthorizedAccessException
• OperationCanceledException
• SocketException |

Códigos de error

• 404 - NotFound
• 401 - Unauthorized
• 403 - Forbidden
• 400 -BadRequest
• 414 RequestUriTooLong

Nota:

Si no hay mensajes fallidos configurados para un punto de conexión, los eventos se quitarán cuando se produzcan los errores o condiciones anteriores. Considere la posibilidad de configurar mensajes fallidos en la suscripción de eventos si no desea que se quiten estos tipos de eventos. Los eventos con mensajes con problemas de entrega se quitarán cuando no se encuentre el destino de los mensajes con problemas de entrega.

Si la condición o error devuelto por el punto de conexión suscrito no está entre las de las listas anteriores, Event Grid vuelve a intentarlo de forma base mediante la siguiente programación de reintentos de retroceso exponencial:

• 0 segundos (reintento inmediato)
• 10 segundos
• 30 segundos
• 1 minuto.
• 5 minutos

Después de 5 minutos, Event Grid continúa reintentando cada 5 minutos hasta que se entregue el evento o se alcance el número máximo de reintentos o el tiempo de vida del evento.

Directiva de reintentos

Puede personalizar la directiva de reintento mediante las dos propiedades de configuración de la suscripción de eventos siguientes. Se quita un evento (no hay mensajes fallidos configurados) o mensajes fallidos si alguna propiedad alcanza su límite configurado.

• Número máximo de entregas: el valor debe ser un entero entre 1 y 10. El valor predeterminado es 10. Para la entrega de inserción, esta propiedad define la entrega máxima intentos.
• Retención : esta propiedad también se conoce como event time to live. El valor debe ser un valor de Duración ISO 8601 con precisión de minutos. A partir del momento en que se publicó el evento, esta propiedad define el intervalo de tiempo después del cual expira el mensaje. El valor mínimo permitido es "PT1M" (1 minuto). El valor máximo permitido es de 7 días o el tiempo de retención del tema subyacente, lo que sea menor. Azure Portal proporciona una experiencia de usuario sencilla en la que se especifican los días, horas y minutos como enteros.

Nota:

Si establece Retention y Maximum delivery count, Event Grid los usa para determinar cuándo detener la entrega de eventos. Cualquiera de las dos detiene la entrega de eventos. Por ejemplo, si establece 20 minutos como retención y 10 intentos de entrega máximos, esto significa que, cuando un evento no se entrega después de 20 minutos o no se entrega después de 10 intentos, lo que ocurra primero, el evento está en mensajes fallidos. Sin embargo, debido a la programación de reintento, establecer el número máximo de intentos de entrega en 10 no tiene ningún impacto, ya que los eventos se enviarán primero después de 20 minutos. Esto se debe al hecho en el minuto 20, se produce el intento de entrega n.º 8 (0, 10s, 30s, 1m, 5m, 10m, 15m, 20m), pero en ese momento el evento está fallido.

Procesamiento por lotes de salida

Cuando se usan Webhooks como tipo de punto de conexión de destino, Event Grid tiene como valor predeterminado enviar cada evento individualmente a los suscriptores. Puede configurar Event Grid para procesar por lotes los eventos para su entrega con el fin de mejorar el rendimiento HTTP en escenarios de alto rendimiento. El procesamiento por lotes está desactivado de manera predeterminada y se puede activar por suscripción de eventos.

Cuando se usa Event Hubs como tipo de punto de conexión de destino, Event Grid siempre agrupa eventos para lograr una máxima eficacia y rendimiento. No hay ninguna configuración de directiva por lotes disponible, ya que Event Grid controla de manera predeterminada el comportamiento de procesamiento por lotes al entregar a Azure Event Hubs.

Directiva de procesamiento por lotes

La entrega por lotes tiene dos opciones:

• Número máximo de eventos por lote: es el número máximo de eventos que Event Grid entrega por lote. El valor debe ser un entero entre 1 y 5000. Este número nunca se supera. Sin embargo, se pueden entregar menos eventos si no hay más eventos disponibles en el momento de la entrega. Event Grid no retrasa los eventos para crear un lote si hay menos eventos disponibles.
• Tamaño de lote preferido en kilobytes: es el límite superior de destino para el tamaño de lote en kilobytes. El valor debe ser un número comprendido entre 1 y 1024. De forma similar a los eventos máximos, el tamaño del lote puede ser menor si no hay suficientes eventos disponibles en el momento de la entrega. Es posible que un lote sea mayor que el tamaño de lote preferido si un solo evento es mayor que el tamaño preferido. Por ejemplo, si el tamaño preferido es de 4Kb y se inserta un evento de 10Kb en Event Grid, el evento 10Kb se entrega en lugar de quitarse.

La entrega por lotes se configura por cada suscripción de eventos a través del portal, la CLI, PowerShell o los SDK.

Comportamiento de procesamiento por lotes

• Todos o ninguno

  Event Grid funciona con la semántica de todos o ninguno. No admite el procesamiento parcial de una entrega por lotes. Los suscriptores deben tener cuidado de solicitar solo los eventos por lote que puedan controlar de forma razonable en 30 segundos.

• Procesamiento por lotes optimista

  La configuración de la directiva de procesamiento por lotes no tiene límites estrictos acerca del comportamiento del procesamiento por lotes, y se respeta en función del mejor esfuerzo. A velocidades de eventos bajas, a menudo observa que el tamaño del lote es menor que los eventos máximos solicitados por lote.

• De forma predeterminada, este valor está desactivado.

  De forma predeterminada, Event Grid solo agrega un evento a cada solicitud de entrega. La manera de activar el procesamiento por lotes es establecer una de las opciones de configuración mencionadas en directiva de procesamiento por lotes.

• Valores predeterminados

  No es necesario especificar ambas opciones (eventos máximos por lote y tamaño de lote aproximado en kilo bytes) al crear una suscripción de eventos. Si solo se establece una configuración, Event Grid usa valores predeterminados. Vea las siguientes secciones para ver los valores predeterminados y aprender a reemplazarlos.

Azure portal

Verá estas opciones en la pestaña Características adicionales de la página de Suscripción a eventos o una vez creada la suscripción de eventos, en la opción de menú Configuración al acceder a la suscripción de eventos.

Eventos fallidos

Cuando Event Grid no puede entregar un evento dentro de un período de tiempo determinado o después de intentar entregar el evento un número determinado de veces, envía el evento a una cuenta de almacenamiento. Este proceso se conoce como colas de mensajes fallidos. Event Grid pone en la cola de mensajes fallidos un evento cuando se cumple una de las siguientes condiciones.

• El evento no se entrega dentro del período de período de vida (retención definida en la suscripción de eventos).
• El número de intentos de entrega del evento ha superado el límite.

Si se cumple, el evento se quita o se envía mensajes fallidos. De forma predeterminada, Event Grid no tiene activada esta opción. Para habilitarla, debe especificar una cuenta de almacenamiento para contener los eventos no entregados al crear la suscripción a eventos. Leerá los eventos de esta cuenta de almacenamiento para resolver las entregas.

Event Grid envía un evento a la ubicación de la cola de mensajes fallidos cuando ha intentado todos los reintentos. Si Event Grid recibe un código de respuesta 400 (solicitud incorrecta) o 413 (entidad de solicitud demasiado grande), programa inmediatamente el evento para los mensajes con problemas de entrega. Estos códigos de respuesta indican que la entrega del evento nunca se realizará correctamente.

La expiración del período de vida SOLO se comprueba en el siguiente intento de entrega programada. Por lo tanto, incluso si expira el período de vida antes del siguiente intento de entrega programada, la expiración del evento se comprueba solo en el momento de la siguiente entrega y, a continuación, en la cola de mensajes fallidos.

Hay un retraso de cinco minutos entre el último intento de entregar un evento y su entrega a la ubicación con mensajes fallidos. Este retraso está pensado para reducir el número de operaciones de almacenamiento de blobs. Si la ubicación de la cola de mensajes fallidos no está disponible durante cuatro horas, se elimina el evento.

Antes de establecer la ubicación de mensajes fallidos, debe tener una cuenta de almacenamiento con un contenedor. Puede proporcionar el punto de conexión de este contenedor al crear la suscripción a eventos. El punto de conexión tiene este formato: /subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.Storage/storageAccounts/<storage-name>/blobServices/default/containers/<container-name>

Es posible que desee recibir una notificación cuando un evento se envía a la ubicación de la cola de mensajes fallidos. Para utilizar Event Grid para responder a eventos no entregados, cree una suscripción a eventos para el almacenamiento de blobs de los eventos fallidos. Cada vez que el almacenamiento de blobs de eventos fallidos recibe un evento no entregado, Event Grid lo notifica al controlador. El controlador responderá con las acciones que debe realizar para conciliar los eventos no entregados.

Al configurar mensajes fallidos, debe agregar la identidad administrada al rol de control de acceso basado en rol (RBAC) adecuado en la cuenta de Azure Storage que contendrá los eventos fallidos. Para obtener más información, consulte Destinos admitidos y roles de Azure.

Formatos de eventos de entrega

En esta sección se proporcionan ejemplos de eventos y eventos fallidos mediante el esquema CloudEvents 1.0, el formato de metadatos del mensaje admitido en temas de espacio de nombres.

Esquema CloudEvents 1.0

Evento

{
    "id": "caee971c-3ca0-4254-8f99-1395b394588e",
    "source": "mysource",
    "dataversion": "1.0",
    "subject": "mySubject",
    "type": "fooEventType",
    "datacontenttype": "application/json",
    "data": {
        "prop1": "value1",
        "prop2": 5
    }
}

Evento en la cola de mensajes fallidos

[
  {
    "deadLetterProperties": {
      "deadletterreason": "Maximum delivery attempts was exceeded.",
      "deliveryattempts": 1,
      "deliveryresult": "Event was not acknowledged nor rejected.",
      "publishutc": "2023-11-01T20:33:51.4521467Z",
      "deliveryattemptutc": "2023-11-01T20:33:52.3692079Z"
    },
    "event": {
      "comexampleextension1": "value1",
      "id": "A234-1234-1234",
      "comexampleothervalue": "5",
      "datacontenttype": "text/xml",
      "specversion": "1.0",
      "time": "2018-04-05T17:31:00Z",
      "source": "/mycontext",
      "type": "com.example.someevent",
      "data": <your-event-data>
    }
  }
]

LastDeliveryOutcome: Probation

Event Grid pone en prueba una suscripción de eventos durante algún tiempo si las entregas de eventos al destino inician un error. El tiempo del período de prueba es diferente para los distintos errores que devuelve el punto de conexión de destino. Si una suscripción de eventos está en período de prueba, los eventos pueden recibir mensajes fallidos o eliminarse sin ni siquiera intentar realizar la entrega en función del código de error debido al cual está en período de prueba.

Error	Duración del período de prueba
Ocupado	10 segundos
NotFound	5 minutos
SocketError	30 segundos
ResolutionError	5 minutos
Disabled	5 minutos
Completo	5 minutos
TimedOut	10 segundos
No autorizado	5 minutos
Prohibido	5 minutos
InvalidAzureFunctionDestination	10 minutos

Nota

Event Grid usa la duración del período de prueba para una mejor administración de la entrega; la duración puede cambiar en el futuro.

Estado de entrega de mensajes

Event Grid usa códigos de respuesta HTTP para acusar recibo de eventos.

Códigos de éxito

Event Grid solo considera entregas correctas los siguientes códigos de respuesta HTTP. Todos los demás códigos de estado se consideran entregas con error y se reintentarán o enviarán mensajes fallidos según corresponda. Cuando Event Grid recibe un código de estado correcto, considera que la entrega ha finalizado.

• 200 OK
• 201 Creado
• 202 - Aceptado
• 203 Información no autoritativa
• 204 No Content

Códigos de error

Todos los demás códigos que no están en el conjunto anterior (200-204) se consideran errores y se reintentarán, si es necesario. Algunos tienen directivas de reintento específicas vinculadas a ellas descritas a continuación, todas las demás siguen la programación de reintento estándar. Es importante recordar que, debido a la naturaleza altamente paralela de la arquitectura de Event Grid, el comportamiento de reintento no es determinista.

status code	Comportamiento de reintento
400 - Solicitud incorrecta	No se ha intentado de nuevo
401 No autorizado	Reintentar después de 5 minutos o más para los puntos de conexión de recursos de Azure
403 Prohibido	No se ha intentado de nuevo
404 No encontrado	Reintentar después de 5 minutos o más para los puntos de conexión de recursos de Azure
Tiempo de espera de solicitud 408	Reintentar después de 2 minutos o más
413 Entidad de solicitud demasiado larga	No se ha intentado de nuevo
Servicio no disponible 503	Reintentar después de 30 segundos o más
Todos los demás	Reintentar después de 10 segundos o más

Propiedades de entrega personalizadas

Las suscripciones a eventos permiten configurar encabezados HTTP que se incluyen en los eventos entregados. Esta capacidad permite establecer encabezados personalizados que un destino requiere. Puede configurar hasta 10 encabezados al crear una suscripción de eventos. Cada valor de encabezado no debe ser mayor que 4 096 (4 K) bytes. Puede establecer encabezados personalizados en los eventos que se entregan a los destinos siguientes:

• webhooks
• Azure Event Hubs

Pasos siguientes

• Entrega de eventos a puntos de conexión de Webhook.