AWS Lambda-Funktionsfehler in C# - AWS Lambda
SyntaxFunktionsweiseVerwenden von Lambda-KonsoleVerwenden von AWS Command Line Interface (AWS CLI)Fehlerbehandlung in anderen AWS-ServicesAls nächstes

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

AWS Lambda-Funktionsfehler in C#

Wenn Ihr Code einen Fehler auslöst, generiert Lambda eine JSON-Darstellung des Fehlers. Dieses Fehlerdokument wird im Aufrufprotokoll und im Fall eines synchronen Aufrufs in der Ausgabe angezeigt.

Auf dieser Seite wird beschrieben, wie Lambda-Funktionsaufruffehler für die C#-Laufzeit mithilfe der Lambda-Konsole und AWS CLI angezeigt werden.

Syntax

In der Initialisierungsphase können Ausnahmen für ungültige Handlerzeichenfolgen, für gegen die Regeln verstoßende Typen oder Methoden (siehe Einschränkungen des Lambda-Funktionshandlers) bzw. für beliebige andere Validierungsmethoden (wie etwa Vergessen des Serializer-Attributs und POCO als Eingabe- und Ausgabetyp) ausgeworfen werden. Diese Ausnahmen sind vom Typ LambdaException. Zum Beispiel: 

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

Falls Ihr Konstruktor eine Ausnahme auswirft, weist der Fehlertyp auch den Typ LambdaException auf, aber die während der Konstruktion ausgeworfene Ausnahme wird in der cause-Eigenschaft bereitgestellt, bei der es sich ebenso um ein modelliertes Ausnahmenobjekt handelt:

{
  "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()"
      ]
    }
  }
}

Wie das Beispiel zeigt, werden die inneren Ausnahmen stets aufrecht erhalten (wie die cause-Eigenschaft) und können tief verschachtelt sein.

Ausnahmen können auch während des Aufrufens auftreten. In diesem Fall wird der Ausnahmetyp beibehalten und die Ausnahme wird direkt als Nutzlast und in den CloudWatch Protokollen zurückgegeben. Beispielsweise: 

{
  "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)"
          ]
        }
      }
    }
  }
}

Die Methode, in der Fehlerinformationen übertragen werden, hängt vom Aufruftyp ab:

  • RequestResponseWenn Sie den Aufruftyp (synchrone Ausführung) verwenden, wird die Fehlermeldung zurückgegeben.

    Wenn Sie beispielsweise eine Lambda-Funktion über die Lambda-Konsole aufrufen, ist der Aufruftyp stets RequestResponse und in der Konsole werden die Fehlermeldungen angezeigt, die von AWS Lambda im Abschnitt Ausführungsergebnis der Konsole zurückgegeben werden.

  • Wenn Sie den Aufruftyp Event (asynchrone Ausführung) verwenden, gibt AWS Lambda nichts zurück. Stattdessen werden die Fehlerinformationen in CloudWatch Protokollen und CloudWatch Metriken protokolliert.

Funktionsweise

Wenn Sie eine Lambda-Funktion aufrufen, erhält Lambda die Aufrufanfrage und validiert die Berechtigungen in Ihrer Ausführungsrolle, überprüft, ob das Ereignisdokument ein gültiges JSON-Dokument ist, und prüft Parameterwerte.

Wenn die Anforderung die Validierung besteht, sendet Lambda die Anfrage an eine Funktions-Instance. Die Lambda-Laufzeitumgebung wandelt das Ereignisdokument in ein Objekt um und leitet es an Ihren Funktions-Handler weiter.

Wenn Lambda auf einen Fehler stößt, gibt er einen Ausnahmetyp, eine Meldung und einen HTTP-Statuscode zurück, der die Ursache des Fehlers angibt. Der Client oder Service, der die Lambda-Funktion aufgerufen hat, kann den Fehler behandeln oder ihn an einen Endbenutzer weitergeben. Das korrekte Fehlerbehandlungsverhalten hängt von der Art der Anwendung, der Zielgruppe und der Fehlerquelle ab.

Die folgende Liste beschreibt den Bereich der Statuscodes, die Sie von Lambda erhalten können.

2xx

Ein 2xx-Serienfehler mit einem X-Amz-Function-Error-Header in der Antwort weist auf einen Lambda-Laufzeit- oder -Funktionsfehler hin. Ein 2xx-Serienstatuscode zeigt an, dass Lambda die Anfrage akzeptiert hat, aber anstelle eines Fehlercodes zeigt Lambda den Fehler an, indem der X-Amz-Function-Error-Header in die Antwort aufgenommen wird.

4xx

Ein 4xx-Serienfehler weist auf einen Fehler hin, den der aufrufende Client oder Dienst beheben kann, indem er die Anfrage ändert, eine Berechtigung beantragt oder die Anfrage wiederholt. 4xx-Serienfehler, abgesehen von 429, weisen allgemein auf einen Fehler bei der Anfrage hin.

5xx

Ein 5xx-Serienfehler weist auf ein Problem mit Lambda oder ein Problem mit der Konfiguration oder Ressourcen der Funktion hin. 5xx-Serienfehler können auf einen temporären Zustand hinweisen, der ohne Eingreifen des Benutzers behoben werden kann. Diese Probleme können vom aufrufenden Client oder Service nicht behoben werden, aber der Eigentümer einer Lambda-Funktion kann das Problem möglicherweise beheben.

Eine vollständige Liste der Aufruffehler finden Sie unter InvokeFunction Fehler .

Verwenden von Lambda-Konsole

Sie können Ihre Funktion auf der Lambda-Konsole aufrufen, indem Sie ein Testereignis konfigurieren und die Ausgabe anzeigen. Die Fehlerausgabe wird in den Ausführungsprotokollen der Funktion erfasst und, wenn die aktives Tracing in AWS X-Ray aktiviert ist.

So rufen Sie eine Funktion in der Lambda-Konsole auf

  1. Öffnen Sie die Seite Funktionen der Lambda-Konsole.

  2. Wählen Sie die zu testende Funktion aus und wählen Sie Test.

  3. Wählen Sie unter Testereignis die Option Neues Ereignis aus.

  4. Wählen Sie eine Vorlage aus.

  5. Geben Sie für Name einen Namen für den Test ein. Geben Sie im Texteingabefeld das JSON-Testereignis ein.

  6. Wählen Sie Änderungen speichern aus.

  7. Wählen Sie Test aus.

Die Lambda-Konsole ruft Ihre Funktion synchron auf und zeigt das Ergebnis an. Um die Antwort, Protokolle und andere Informationen anzuzeigen, erweitern Sie den Abschnitt Details .

Verwenden von AWS Command Line Interface (AWS CLI)

Die AWS CLI ist ein Open-Source-Tool, mit dem Sie über Befehle in Ihrer Befehlszeilen-Shell mit den AWS-Services interagieren können. Zur Durchführung der Schritte in diesem Abschnitt benötigen Sie Folgendes:

Wenn Sie eine Lambda-Funktion in AWS CLI aufrufen, teilt AWS CLI die Antwort in zwei Dokumente auf. Die AWS CLI-Antwort wird in Ihrer Eingabeaufforderung angezeigt. Wenn ein Fehler aufgetreten ist, enthält die Antwort ein FunctionError-Feld. Die Aurufantwort oder der Fehler, die bzw. der von der Funktion zurückgegeben wird, wird in die Ausgabedatei geschrieben. Beispiel: output.json oder output.txt.

Das folgende Beispiel für den Befehl invoke zeigt, wie Sie eine Funktion aufrufen und die Aufrufantwort in eine output.txt-Datei schreiben.

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

Die cli-binary-format-Option ist erforderlich, wenn Sie AWS CLI Version 2 verwenden. Um dies zur Standardeinstellung zu machen, führen Sie aws configure set cli-binary-format raw-in-base64-out aus. Weitere Informationen finden Sie unter Von AWS CLI unterstützte globale Befehlszeilenoptionen im AWS Command Line Interface-Benutzerhandbuch für Version 2.

Sie sollten die AWS CLI-Antwort in Ihrer Eingabeaufforderung sehen:

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

Sie sollten die Antwort auf den Funktionsaufruf in der output.txt-Datei sehen. In derselben Eingabeaufforderung können Sie die Ausgabe auch in Ihrer Eingabeaufforderung anzeigen mit:

cat output.txt

Sie sollten die Aufrufantwort in Ihrer Eingabeaufforderung sehen.

Lambda zeichnet auch bis zu 256 KB des Fehlerobjekts in den Protokollen der Funktion auf. Weitere Informationen finden Sie unter Lambda-Funktionsprotokollierung in C#.

Fehlerbehandlung in anderen AWS-Services

Wenn ein anderer AWS-Service Ihre Funktion aufruft, wählt der Service den Aufruftyp und das Wiederholungsverhalten aus. AWS-Services können Ihre Funktion nach einem Zeitplan aufrufen, als Reaktion auf ein Lebenszyklusereignis auf einer Ressource oder um eine Anfrage von einem Benutzer zu bedienen. Einige Services rufen Funktionen asynchron auf und lassen Fehler von Lambda verarbeiten, während es bei anderen Fehlern erneut versucht wird, oder sie an den Benutzer zurückgeben werden.

API Gateway behandelt beispielsweise alle Aufruf- und Funktionsfehler als interne Fehler. Wenn die Lambda-API die Aufruf-Anforderung ablehnt, gibt API Gateway einen 500-Fehlercode zurück. Wenn die Funktion ausgeführt wird, aber einen Fehler oder eine Antwort im falschen Format zurückgibt, gibt API Gateway den Fehlercode 502 zurück. Um die Fehlerantwort anzupassen, müssen Sie Fehler im Code abfangen und eine Antwort im erforderlichen Format formatieren.

Wir empfehlen die Verwendung von AWS X-Ray, um die Fehlerquelle und deren Ursache zu ermitteln. Mit X-Ray können Sie herausfinden, bei welcher Komponente ein Fehler aufgetreten ist, und Details zu den Fehlern anzeigen. Das folgende Beispiel zeigt einen Funktionsfehler, der zu einer 502-Antwort von API Gateway führte.

Ablaufverflogungszuweisung für einen Funktionsfehler mit API Gateway.

Weitere Informationen finden Sie unter Instrumentieren von C#-Code in AWS Lambda.

Als nächstes