Monitor y depuración de aplicaciones basadas en eventos con el nuevo registro de Amazon Eventbridge | Servicios web de Amazon

A partir de hoy, puede utilizar la capacidad de registro mejorada en Amazon Eventbridge para monitorear y depurar sus aplicaciones basadas en eventos con registros integrales. Estas nuevas mejoras ayudan a mejorar la forma en que monitorea y soluciona los flujos de eventos.

Así es como puede encontrar esta nueva capacidad en la consola de Amazon Eventbridge:

Las nuevas capacidades de observabilidad abordan los microservicios y los desafíos de monitoreo de arquitectura de eventos al proporcionar un seguimiento integral del ciclo de vida de eventos. Eventbridge ahora genera entradas de registro detalladas cada vez que se publica, se publica, entrega, entrega a los suscriptores o encuentran fallas y reintentos.

Obtiene visibilidad en el viaje de evento completo con información detallada sobre éxitos, fallas y códigos de estado que hacen que la identificación y el diagnóstico sean directamente. Lo que solía llevar horas de depuración de prueba y error ahora lleva minutos con el seguimiento detallado del ciclo de vida del evento y herramientas de consulta incorporadas.

Uso de Amazon EventBridge Mayor Observability
Déjame guiarte a través de una demostración que muestra la capacidad de registro en Amazon Eventbridge.

Puedo habilitar el registro para un bus de eventos existente o al crear un nuevo bus de eventos personalizado. Primero, navego a la consola de eventbridge y elijo Buses de eventos En el panel de navegación izquierda. En Bus personalizadoElijo Crear bus de eventos.

Puedo ver esta nueva capacidad en el Registro sección. Tengo tres opciones para configurar el Destino de registro: Amazon CloudWatch Logs, Amazon Data FireHose Stream y Amazon Simple Storage Service (Amazon S3). Si quiero transmitir mis registros en un lago de datos, puedo seleccionar la transmisión de FireHose de Data Data de Amazon Kinesis. Los registros están encriptados en tránsito con TLS y en reposo si se proporciona una clave administrada por el cliente (CMK) para el bus de eventos. CloudWatch Logs admite claves administradas por el cliente, y Data FireHose ofrece cifrado del lado del servidor para destinos posteriores.

Para esta demostración, selecciono Logs de CloudWatch y S3 Registros.

Yo también puedo elegir Nivel de registrode error, información o rastreo. Yo elijo Rastro y seleccionar Incluir datos de ejecución Porque necesito revisar las cargas útiles. Debe tener en cuenta ya que los datos de carga útil de registro pueden contener información confidencial, y esta configuración se aplica a todos los destinos de registro que seleccione. Luego, configuro dos destinos, uno para cada uno para Grupo de registro de CloudWatch y S3 Registros. Entonces elijo Crear.

Después de habilitar el registro, puedo comenzar a publicar eventos de prueba para observar el comportamiento de registro.

Para el primer escenario, he creado una función AWS Lambda y configuré esta función Lambda como un objetivo.

Navego a mi bus de eventos para enviar un evento de muestra eligiendo Enviar eventos.

Aquí está la carga útil que uso:

{
  "Source": "ecommerce.orders",
  "DetailType": "Order Placed",
  "Detail": {
    "orderId": "12345",
    "customerId": "cust-789",
    "amount": 99.99,
    "items": [
      {
        "productId": "prod-456",
        "quantity": 2,
        "price": 49.99
      }
    ]
  }
}

Después de enviar el evento de muestra, puedo ver que los registros están disponibles en mi cubo S3.

También puedo ver las entradas de registro que aparecen en los registros de Amazon CloudWatch. Los registros muestran el ciclo de vida del evento, desde EVENT_RECEIPT a SUCCESS. Obtenga más información sobre el ciclo de vida completo del evento sobre lo que Amazon Eventbridge registra la página de documentación de los autobuses de eventos.

Ahora, evaluemos estos registros. Para la brevedad, solo incluyo unos pocos registros y los he redactado para su legibilidad. Aquí está el registro desde cuando activé el evento:

{
    "resource_arn": "arn:aws:events:us-east-1:123:event-bus/demo-logging",
    "message_timestamp_ms": 1751608776896,
    "event_bus_name": "demo-logging",
// REDACTED FOR BREVITY //
    "message_type": "EVENT_RECEIPT",
    "log_level": "TRACE",
    "details": {
        "caller_account_id": "123",
        "source_time_ms": 1751608775000,
        "source": "ecommerce.orders",
        "detail_type": "Order Placed",
        "resources": [],
        "event_detail": "REDACTED FOR BREVITY"
    }
}

Aquí está el registro cuando el evento fue invocado con éxito:

{
    "resource_arn": "arn:aws:events:us-east-1:123:event-bus/demo-logging",
    "message_timestamp_ms": 1751608777091,
    "event_bus_name": "demo-logging",
// REDACTED FOR BREVITY //
    "message_type": "INVOCATION_SUCCESS",
    "log_level": "INFO",
    "details": {
// REDACTED FOR BREVITY //
        "total_attempts": 1,
        "final_invocation_status": "SUCCESS",
        "ingestion_to_start_latency_ms": 105,
        "ingestion_to_complete_latency_ms": 183,
        "ingestion_to_success_latency_ms": 183,
        "target_duration_ms": 53,
        "target_response_body": "",
        "http_status_code": 202
    }
}

Las entradas de registro adicionales incluyen metadatos ricos que hacen que la resolución de problemas sea directa. Por ejemplo, en un evento exitoso, puedo ver el momento de la latencia desde comenzar a completar el evento, la duración del objetivo de finalizar el procesamiento y el código de estado HTTP.

Fallas de depuración con seguimiento completo del ciclo de vida del evento
El beneficio del registro de eventbridge se hace evidente cuando las cosas salen mal. Para probar los escenarios de falla, configivo intencionalmente los permisos de una función Lambda y cambio la regla para apuntar a una función Lambda diferente sin los permisos adecuados.

El intento falló con una falla permanente debido a los permisos faltantes. El registro muestra que es un FIRST intento que resultó en NO_PERMISSIONS estado.

{
    "message_type": "INVOCATION_ATTEMPT_PERMANENT_FAILURE",
    "log_level": "ERROR",
    "details": {
        "rule_arn": "arn:aws:events:us-east-1:123:rule/demo-logging/demo-order-placed",
        "role_arn": "arn:aws:iam::123:role/service-role/Amazon_EventBridge_Invoke_Lambda_123",
        "target_arn": "arn:aws:lambda:us-east-1:123:function:demo-evb-fail",
        "attempt_type": "FIRST",
        "attempt_count": 1,
        "invocation_status": "NO_PERMISSIONS",
        "target_duration_ms": 25,
        "target_response_body": "{\"requestId\":\"a4bdfdc9-4806-4f3e-9961-31559cb2db62\",\"errorCode\":\"AccessDeniedException\",\"errorType\":\"Client\",\"errorMessage\":\"User: arn:aws:sts::123:assumed-role/Amazon_EventBridge_Invoke_Lambda_123/db4bff0a7e8539c4b12579ae111a3b0b is not authorized to perform: lambda:InvokeFunction on resource: arn:aws:lambda:us-east-1:123:function:demo-evb-fail because no identity-based policy allows the lambda:InvokeFunction action\",\"statusCode\":403}",
        "http_status_code": 403
    }
}

La entrada de registro final resume la falla completa con métricas de tiempo y el mensaje de error exacto.

{
    "message_type": "INVOCATION_FAILURE",
    "log_level": "ERROR",
    "details": {
        "rule_arn": "arn:aws:events:us-east-1:123:rule/demo-logging/demo-order-placed",
        "role_arn": "arn:aws:iam::123:role/service-role/Amazon_EventBridge_Invoke_Lambda_123",
        "target_arn": "arn:aws:lambda:us-east-1:123:function:demo-evb-fail",
        "total_attempts": 1,
        "final_invocation_status": "NO_PERMISSIONS",
        "ingestion_to_start_latency_ms": 62,
        "ingestion_to_complete_latency_ms": 114,
        "target_duration_ms": 25,
        "http_status_code": 403
    },
    "error": {
        "http_status_code": 403,
        "error_message": "User: arn:aws:sts::123:assumed-role/Amazon_EventBridge_Invoke_Lambda_123/db4bff0a7e8539c4b12579ae111a3b0b is not authorized to perform: lambda:InvokeFunction on resource: arn:aws:lambda:us-east-1:123:function:demo-evb-fail because no identity-based policy allows the lambda:InvokeFunction action",
        "aws_service": "AWSLambda",
        "request_id": "a4bdfdc9-4806-4f3e-9961-31559cb2db62"
    }
}

Los registros proporcionan métricas de rendimiento detalladas que ayudan a identificar cuellos de botella. El ingestion_to_start_latency_ms: 62 muestra el tiempo desde la ingestión de eventos hasta comenzar la invocación, mientras ingestion_to_complete_latency_ms: 114 Representa el tiempo total desde la ingestión hasta la finalización. Además, target_duration_ms: 25 Indica cuánto tiempo tardó el servicio objetivo para responder, ayudando a distinguir entre el tiempo de procesamiento de eventbridge y el rendimiento del servicio objetivo.

El mensaje de error establece claramente lo que falló, lambda:InvokeFunction actionpor qué falló, (no identity-based policy allows the action), qué papel estaba involucrado (Amazon_EventBridge_Invoke_Lambda_1428392416), y qué recurso específico se vio afectado, lo cual fue indicado por la función Lambda Nombre de recursos de Amazon (ARN).

Destinos API de depuración con EventBridge Logging
Un caso de uso particular que creo que la capacidad de registro de eventBridge será útil es depurar problemas con destinos de API. Los destinos API de EventBridge son puntos finales HTTPS que puede invocar como el objetivo de una regla o tubería de bus de eventos. Los puntos finales de HTTPS lo ayudan a enrutar eventos de su bus de eventos a sistemas externos, aplicaciones de software como servicio (SaaS) o API de terceros que utilizan llamadas HTTPS. Utilizan conexiones para manejar la autenticación y las credenciales, lo que facilita la integración de su arquitectura basada en eventos con cualquier servicio basado en HTTPS.

Los destinos API se usan comúnmente para enviar eventos a puntos finales HTTPS externos y las fallas de depuración desde el punto final externo pueden ser un desafío. Estos problemas generalmente se derivan de los cambios a los requisitos de autenticación de punto final o credenciales modificadas.

Para demostrar esta capacidad de depuración, configuré intencionalmente un destino API con credenciales incorrectas en el recurso de conexión.

Cuando envío un evento a este punto final mal configurado, el registro mejorado muestra la causa raíz de esta falla.

{
    "resource_arn": "arn:aws:events:us-east-1:123:event-bus/demo-logging",
    "message_timestamp_ms": 1750344097251,
    "event_bus_name": "demo-logging",
    //REDACTED FOR BREVITY//,
    "message_type": "INVOCATION_FAILURE",
    "log_level": "ERROR",
    "details": {
        //REDACTED FOR BREVITY//,
        "total_attempts": 1,
        "final_invocation_status": "SDK_CLIENT_ERROR",
        "ingestion_to_start_latency_ms": 135,
        "ingestion_to_complete_latency_ms": 549,
        "target_duration_ms": 327,
        "target_response_body": "",
        "http_status_code": 400
    },
    "error": {
        "http_status_code": 400,
        "error_message": "Unable to invoke ApiDestination endpoint: The request failed because the credentials included for the connection are not authorized for the API destination."
    }
}

El registro proporciona una claridad inmediata sobre la falla. El Target_arn muestra que esto implica un destino API, el final_invocation_status indica SDK_CLIENT_ERRORy el http_status_code de 400 que apunta a un problema del lado del cliente. Lo más importante, el error_message establece explícitamente que: Unable to invoke ApiDestination endpoint: The request failed because the credentials included for the connection are not authorized for the API destination.

Esta secuencia de registro completa proporciona información útil de depuración porque puedo ver exactamente cómo se movió el evento a través de EventBridge, desde el recibo del evento, hasta la ingestión, la coincidencia de reglas, hasta intentos de invocación. Este nivel de detalle elimina las conjeturas y apunta directamente a la causa raíz del problema.

Cosas adicionales que saber
Aquí hay un par de cosas a tener en cuenta:

• Soporte de arquitectura – El registro funciona con todas las características de EventBridge, incluidos autobuses de eventos personalizados, fuentes de eventos asociados y destinos API para puntos finales HTTPS.
• Impacto en el rendimiento – El registro funciona de manera asincrónica sin un impacto medible en la latencia o rendimiento del procesamiento de eventos.
• Fijación de precios – Paga a Amazon S3 estándar, registros de Amazon CloudWatch o un precio de Amazon Data Firehose para almacenamiento y entrega de registros. El registro de eventbridge no incurre en cargos adicionales. Para más detalles, visite la página de precios de Amazon Eventbridge.
• Disponibilidad – La capacidad de registro de Amazon Eventbridge está disponible en todas las regiones de AWS donde es compatible con EventBridge.
• Documentación – Para obtener más detalles, consulte la documentación de monitoreo y depuración de Amazon Eventbridge.

Comience con la capacidad de registro de Amazon Eventbridge visitando la consola Eventbridge y habilitando el registro en sus autobuses de eventos.

¡Feliz edificio!
– Donnie