Errores de funciones de AWS Lambda en C# - AWS Lambda
SintaxisCómo funcionaUso de la consola de LambdaUso de AWS Command Line Interface (AWS CLI)Administración de errores en otros servicios de AWSSiguientes pasos

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Errores de funciones de AWS Lambda en C#

Cuando el código da lugar a un error, Lambda genera una representación JSON de este. Este documento de error aparece en el registro de invocación y, en el caso de invocaciones síncronas, en la salida.

En esta página se describe cómo ver los errores de invocación de funciones de Lambda para el tiempo de ejecución de C# utilizando la consola de Lambda y el AWS CLI.

Sintaxis

En la fase de inicialización, pueden producirse excepciones para cadenas de controlador no válidas, métodos o tipos que no cumplan las reglas (consulte Restricciones del controlador de funciones de Lambda) o cualquier otro método de validación (como olvidar el atributo serializador y utilizar POCO como tipo de entrada o salida). Estas excepciones son de tipo LambdaException. Por ejemplo: 

{
  "errorType": "LambdaException",
  "errorMessage": "Invalid lambda function handler: 'http://this.is.not.a.valid.handler/'. 
  The valid format is 'ASSEMBLY::TYPE::METHOD'."
}

Si el constructor genera una excepción, el error también es del tipo LambdaException, pero la excepción generada durante la construcción se proporciona en la propiedad cause, que es un objeto de excepción modelado:

{
  "errorType": "LambdaException",
  "errorMessage": "An exception was thrown when the constructor for type 'LambdaExceptionTestFunction.ThrowExceptionInConstructor'
   was invoked. Check inner exception for more details.",
  "cause":   {
    "errorType": "TargetInvocationException",
    "errorMessage": "Exception has been thrown by the target of an invocation.",
    "stackTrace": [
      "at System.RuntimeTypeHandle.CreateInstance(RuntimeType type, Boolean publicOnly, Boolean noCheck, Boolean&canBeCached, 
      RuntimeMethodHandleInternal&ctor, Boolean& bNeedSecurityCheck)",
      "at System.RuntimeType.CreateInstanceSlow(Boolean publicOnly, Boolean skipCheckThis, Boolean fillCache, StackCrawlMark& stackMark)",
      "at System.Activator.CreateInstance(Type type, Boolean nonPublic)",
      "at System.Activator.CreateInstance(Type type)"
    ],
    "cause":     {
      "errorType": "ArithmeticException",
      "errorMessage": "Sorry, 2 + 2 = 5",
      "stackTrace": [
        "at LambdaExceptionTestFunction.ThrowExceptionInConstructor..ctor()"
      ]
    }
  }
}

Como muestra el ejemplo, las excepciones internas siempre se conservan (como la propiedad cause) y pueden anidarse profundamente.

Las excepciones también pueden producirse durante la invocación. En este caso, se conserva el tipo de excepción y la excepción se devuelve directamente como carga útil y en los CloudWatch registros. Por ejemplo: 

{
  "errorType": "AggregateException",
  "errorMessage": "One or more errors occurred. (An unknown web exception occurred!)",
  "stackTrace": [
    "at System.Threading.Tasks.Task.ThrowIfExceptional(Boolean includeTaskCanceledExceptions)",
    "at System.Threading.Tasks.Task`1.GetResultCore(Boolean waitCompletionNotification)",
    "at lambda_method(Closure , Stream , Stream , ContextInfo )"
  ],
  "cause":   {
    "errorType": "UnknownWebException",
    "errorMessage": "An unknown web exception occurred!",
    "stackTrace": [
      "at LambdaDemo107.LambdaEntryPoint.<GetUriResponse>d__1.MoveNext()",
      "--- End of stack trace from previous location where exception was thrown ---",
      "at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)",
      "at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)",
      "at System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()",
      "at LambdaDemo107.LambdaEntryPoint.<CheckWebsiteStatus>d__0.MoveNext()"
    ],
    "cause":     {
      "errorType": "WebException",
      "errorMessage": "An error occurred while sending the request. SSL peer certificate or SSH remote key was not OK",
      "stackTrace": [
        "at System.Net.HttpWebRequest.EndGetResponse(IAsyncResult asyncResult)",
        "at System.Threading.Tasks.TaskFactory`1.FromAsyncCoreLogic(IAsyncResult iar, Func`2 endFunction, Action`1 endAction, Task`1 promise, Boolean requiresSynchronization)",
        "--- End of stack trace from previous location where exception was thrown ---",
        "at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)",
        "at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)",
        "at System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()",
        "at LambdaDemo107.LambdaEntryPoint.<GetUriResponse>d__1.MoveNext()"
      ],
      "cause":       {
        "errorType": "HttpRequestException",
        "errorMessage": "An error occurred while sending the request.",
        "stackTrace": [
          "at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)",
          "at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)",
          "at System.Net.Http.HttpClient.<FinishSendAsync>d__58.MoveNext()",
          "--- End of stack trace from previous location where exception was thrown ---",
          "at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)",
          "at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)",
          "at System.Net.HttpWebRequest.<SendRequest>d__63.MoveNext()",
          "--- End of stack trace from previous location where exception was thrown ---",
          "at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)",
          "at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)",
          "at System.Net.HttpWebRequest.EndGetResponse(IAsyncResult asyncResult)"
        ],
        "cause":         {
          "errorType": "CurlException",
          "errorMessage": "SSL peer certificate or SSH remote key was not OK",
          "stackTrace": [
            "at System.Net.Http.CurlHandler.ThrowIfCURLEError(CURLcode error)",
            "at System.Net.Http.CurlHandler.MultiAgent.FinishRequest(StrongToWeakReference`1 easyWrapper, CURLcode messageResult)"
          ]
        }
      }
    }
  }
}

El método con el que se comunica la información del error depende del tipo de invocación:

  • Tipo de invocación RequestResponse (es decir, ejecución síncrona): en este caso, se obtiene el mensaje de error.

    Por ejemplo, si invoca una función de utilizando la consola de Lambda, RequestResponse siempre es el tipo de invocación, y la consola muestra la información de error devuelta por AWS Lambda en la sección Execution result (Resultado de ejecución) de la consola.

  • Tipo de invocación Event (es decir, ejecución asíncrona): en este caso, AWS Lambda no devuelve nada. En su lugar, registra la información del error en CloudWatch los registros y CloudWatch las métricas.

Cómo funciona

Al invocar una función de Lambda, Lambda recibe la solicitud de invocación y valida los permisos de su rol de ejecución, comprueba que el documento de evento es un documento JSON válido y comprueba los valores de los parámetros.

Si la solicitud pasa la validación, Lambda envía la solicitud a una instancia de función. El entorno de tiempo de ejecución de Lambda convierte el documento de evento en un objeto y lo pasa al controlador de funciones.

Si Lambda encuentra algún error, devuelve un tipo de excepción, mensaje y código de estado HTTP que indican la causa del error. El cliente o servicio que invocó la función de Lambda puede manejar el error mediante programación, o pasarlo a un usuario final. El comportamiento adecuado en la administración de errores dependerá del tipo de aplicación, la audiencia y el origen del error.

En la siguiente lista se describe el rango de códigos de estado de los que puede recibir de Lambda.

2xx

Un error de serie 2xx con un encabezado X-Amz-Function-Error en la respuesta indica un error de tiempo de ejecución o función de Lambda. Un código de estado de 2xx serie indica que Lambda aceptó la solicitud, pero en lugar de un código de error, Lambda indica el error al incluir el encabezado X-Amz-Function-Error en la respuesta.

4xx

Un error de serie 4xx indica un error que el cliente o servicio invocador puede corregir modificando la solicitud, solicitando permiso o reintentando la solicitud. 4xx errores de serie distintos de 429 lo general indican un error con la solicitud.

5xx

Un error de serie 5xx indica un problema con Lambda, o un problema con la configuración o los recursos de la función. Los errores de serie 5xx pueden indicar una condición temporal que se puede resolver sin ninguna acción del usuario. Estos problemas no pueden ser resueltos por el cliente o servicio invocador, pero el propietario de una función de Lambda puede solucionar el problema.

Para obtener una lista completa de los errores de invocación, consulta InvokeFunction errores.

Uso de la consola de Lambda

Puede invocar su función en la consola de Lambda configurando un evento de prueba y viendo la salida. La salida se captura en los registros de ejecución de la función y, cuando el seguimiento activo está habilitado, en AWS X-Ray.

Para invocar una función en la consola de Lambda

  1. Abra la página de Funciones en la consola de Lambda.

  2. Elija la función que desea probar y elija Pruebas.

  3. En Evento de prueba, seleccione Nuevo evento.

  4. Seleccione una plantilla.

  5. En Nombre, escriba un nombre para la prueba. En el cuadro de entrada de texto, introduzca el evento de prueba JSON.

  6. Elija Guardar cambios.

  7. Seleccione Probar.

La consola de Lambda invoca la función de forma sincrónica y muestra el resultado. Para ver la respuesta, los registros y otra información, expanda la sección Details (Detalles).

Uso de AWS Command Line Interface (AWS CLI)

La AWS CLI es una herramienta de código abierto que lo habitlita para interactuar con los servicios de AWS mediante el uso de comandos en el shell de la línea de comandos. Para completar los pasos de esta sección, debe disponer de lo siguiente:

Cuando se invoca una función de Lambda en la AWS CLI, la AWS CLI divide la respuesta en dos documentos. La respuesta AWS CLI se muestra en el símbolo del sistema. Si se ha producido un error, la respuesta contiene un campo FunctionError. La respuesta de invocación o error devuelto por la función se escribe en un archivo de salida. Por ejemplo, output.json o output.txt.

En el siguiente ejemplo de comando invoke se muestra cómo invocar una función y escribir la respuesta de invocación en un archivo output.txt.

aws lambda invoke   \
  --function-name my-function   \
      --cli-binary-format raw-in-base64-out  \
          --payload '{"key1": "value1", "key2": "value2", "key3": "value3"}' output.txt

La opción cli-binary-format es obligatoria si va a utilizar la versión 2 de la AWS CLI. Para que esta sea la configuración predeterminada, ejecute aws configure set cli-binary-format raw-in-base64-out. Para obtener más información, consulte Opciones de la línea de comandos globales compatibles con AWS CLI en la Guía del usuario de la AWS Command Line Interface versión 2.

Debería ver la respuesta AWS CLI en su símbolo del sistema:

{
    "StatusCode": 200,
    "FunctionError": "Unhandled",
    "ExecutedVersion": "$LATEST"
}

Debería ver la respuesta de invocación de función en el archivo output.txt. En el mismo símbolo del sistema, también puede ver la salida en el símbolo del sistema usando:

cat output.txt

Debería ver la respuesta de invocación en el símbolo del sistema.

Lambda también registra hasta 256 KB del objeto de error en los registros de la función. Para obtener más información, consulte Registro de funciones de Lambda en C#.

Administración de errores en otros servicios de AWS

Cuando otro servicio de AWS invoca su función, el servicio elige el tipo de invocación y el comportamiento de reintento. AWS pueden invocar su función según una programación, en respuesta a un evento de ciclo de vida en un recurso o para atender una solicitud de un usuario. Algunos servicios invocan funciones de forma asíncrona y permiten que Lambda administre los errores, mientras que otros vuelven a intentarlo o pasan los errores al usuario.

Por ejemplo, API Gateway trata todos los errores de invocación y función como errores internos. Si la API de Lambda rechaza la solicitud de invocación, API Gateway devuelve un código de error de 500. Si la función se ejecuta pero devuelve un error o devuelve una respuesta con un formato incorrecto, API Gateway muestra un código de error 502. Para personalizar la respuesta del error, debe detectar errores en el código y elaborar una respuesta en el formato que desee.

Para determinar la fuente de un error y su causa, recomendamos usar AWS X-Ray. X-Ray le permite averiguar en qué componente se produjo un error y ver los detalles sobre los errores. En el ejemplo siguiente, se muestra un error de una función que generó una respuesta 502 de API Gateway.

Mapa de seguimiento de un error de función con API Gateway.

Para obtener más información, consulte Instrumentación de código C# en AWS Lambda.

Siguientes pasos