Fehlerbehebung bei Cloud Run-Funktionen (1. Generation)

Hinweis: Dieser Inhalt gilt nur für Cloud Run-Funktionen (1. Generation), früher Cloud Functions (1. Generation).

Informationen zur Version dieses Dokuments für Cloud Run Functions finden Sie unter Fehlerbehebung bei Cloud Run-Funktionen.

In diesem Dokument erfahren Sie, wie Sie Fehlermeldungen beheben und Probleme bei der Verwendung von Cloud Run Functions der 1. Generation beheben.

Bereitstellung

In diesem Abschnitt sind mögliche Probleme mit der Bereitstellung sowie Vorschläge zu deren Behebung aufgeführt. Viele Probleme, die bei der Bereitstellung auftreten können, stehen im Zusammenhang mit Rollen und Berechtigungen oder einer falschen Konfiguration.

Bereitstellungsdienstkonto fehlen zum Bereitstellen einer ereignisgesteuerten Funktion Pub/Sub-Berechtigungen

Der Cloud Functions-Dienst verwendet beim Ausführen von administrativen Aufgaben das Dienstkonto des Cloud Functions-Dienst-Agents ([e-mail]). Standardmäßig wird diesem Konto die Cloud Functions-Rolle cloudfunctions.serviceAgent zugewiesen. Zum Bereitstellen von ereignisgesteuerten Funktionen muss der Cloud Functions-Dienst auf Pub/Sub zugreifen, um Themen und Abos zu konfigurieren. Wenn sich die dem Dienstkonto zugewiesene Rolle ändert und die entsprechenden Berechtigungen nicht aktualisiert werden, kann der Cloud Functions-Dienst nicht auf Pub/Sub zugreifen und die Bereitstellung schlägt fehl.

Fehlermeldung

Console

Failed to configure trigger PubSub projects/PROJECT_ID/topics/FUNCTION_NAME

gcloud

ERROR: (gcloud.functions.deploy) OperationError: code=13, message=Failed to configure trigger PubSub projects/PROJECT_ID/topics/FUNCTION_NAME

Die Lösung

Sie können Ihr Dienstkonto auf die Standardrolle cloudfunctions.serviceAgent zurücksetzen.

Das Standard-Laufzeitdienstkonto ist nicht vorhanden

Wenn kein vom Nutzer verwaltetes Dienstkonto angegeben ist, verwenden Cloud Run-Funktionen der 1. Generation standardmäßig das App Engine-Dienstkonto. Bereitstellungen schlagen fehl, wenn Sie das Standardkonto löschen, ohne ein vom Nutzer verwaltetes Dienstkonto anzugeben.

Fehlermeldung

gcloud

ERROR: (gcloud.functions.deploy) ResponseError: status=[400], code=[Ok], message=[Default service account '[e-mail]' doesn't exist. Please recreate this account or specify a different account. Please visit https://cloud.google.com/functions/docs/troubleshooting for in-depth troubleshooting documentation.]

Die Lösung

Führen Sie einen der folgenden Schritte aus, um das Problem zu beheben:

• Geben Sie beim Bereitstellen Ihrer Funktion ein vom Nutzer verwaltetes Laufzeitdienstkonto an.

• Erstellen Sie das Standarddienstkonto [e-mail] für Ihr Projekt neu.

• Stellen Sie das Standarddienstkonto wieder her.

Nutzer fehlen beim Bereitstellen einer Funktion die Berechtigungen für das Laufzeitdienstkonto

Jede Funktion ist einem Dienstkonto zugeordnet, das als Identität dient, wenn die Funktion auf andere Ressourcen zugreift. Dieses Laufzeitdienstkonto kann das Standarddienstkonto oder ein vom Nutzer verwaltetes Dienstkonto sein. Damit Cloud Functions ein Laufzeitdienstkonto verwenden kann, muss der Bereitsteller die Berechtigung iam.serviceAccounts.actAs für dieses Dienstkonto haben. Ein Nutzer, der ein Konto erstellt, das kein Standardlaufzeitdienstkonto ist, erhält diese Berechtigung automatisch. Anderen Bereitstellern muss diese Berechtigung jedoch von einem Nutzer mit den entsprechenden Berechtigungen gewährt werden.

Nutzern, denen die Rolle „Projektbetrachter“, „Cloud Functions-Entwickler“ oder „Cloud Functions-Administrator“ zugewiesen wurde, muss zusätzlich die Berechtigung iam.serviceAccounts.actAs für das Laufzeitdienstkonto zugewiesen werden.

Fehlermeldung

Console

You must have the iam.serviceAccounts.actAs permission on the selected service account. To obtain this permission, you can grant a role that includes it like the Service Account User role, on the project.

gcloud

Für das Standarddienstkonto wird der folgende Fehler ausgegeben:

ERROR: (gcloud.functions.deploy) ResponseError: status=[403], code=[Ok], message=[Caller USER is missing permission 'iam.serviceaccounts.actAs' on service account [e-mail]. Grant the role 'roles/iam.serviceAccountUser' to the caller on the service account [e-mail]. You can do that by running 'gcloud iam service-accounts add-iam-policy-binding
[e-mail] --member MEMBER --role roles/iam.serviceAccountUser' where MEMBER has a prefix like 'user:' or 'serviceAccount:'.

Für das nicht standardmäßige Dienstkonto wird der folgende Fehler ausgegeben:

ERROR: (gcloud.functions.deploy) ResponseError: status=[403], code=[Ok], message=[Caller USER is missing permission 'iam.serviceaccounts.actAs' on service account SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com. Grant the role 'roles/iam.serviceAccountUser' to the caller on the service account SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com. You can do that by running 'gcloud iam service-accounts add-iam-policy-binding SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com --member MEMBER --role roles/iam.serviceAccountUser' where MEMBER has a prefix like 'user:' or 'serviceAccount:'.

Hinweis: [e-mail] ist das Standard-Laufzeitdienstkonto für Cloud Run-Funktionen(1. Generation). Wenn Sie ein nicht standardmäßiges Dienstkonto verwenden, wird dieser Wert in der Fehlermeldung durch das nutzerverwaltete Dienstkonto SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com ersetzt.

Die Lösung

Weisen Sie dem Nutzer die Rolle roles/iam.serviceAccountUser für das Standard- oder nutzerverwaltete Dienstkonto zu. Diese Rolle umfasst die Berechtigung iam.serviceAccounts.actAs.

Cloud Run Functions-Dienst-Agent-Dienstkonto fehlt Berechtigungen für Projekt-Buckets bei der Bereitstellung einer Funktion

Cloud Run-Funktionen können nur von Ereignissen ausgelöst werden, die aus Cloud Storage-Buckets im selben Google Cloud-Projekt stammen. Darüber hinaus muss das Dienstkonto des Cloud Functions-Dienst-Agents ([e-mail]) für Ihr Projekt die Rolle cloudfunctions.serviceAgent haben.

Fehlermeldung

Console

Deployment failure: Insufficient permissions to (re)configure a trigger
(permission denied for bucket BUCKET_ID). Please, give owner permissions
to the editor role of the bucket and try again.

gcloud

ERROR: (gcloud.functions.deploy) OperationError: code=7, message=Insufficient
permissions to (re)configure a trigger (permission denied for bucket BUCKET_ID).
Please, give owner permissions to the editor role of the bucket and try again.

Die Lösung

Setzen Sie das Dienstkonto für den Dienst-Agenten auf die Standardrolle zurück, um diesen Fehler zu beheben.

Nutzer mit der Rolle „Projektbearbeiter“ können keine Funktion veröffentlichen

Die Rolle „Projektbearbeiter“ hat umfassende Berechtigungen zum Verwalten von Ressourcen innerhalb eines Projekts, aber nicht die Berechtigung, Cloud Run-Funktionen zu veröffentlichen. Sie müssen dem Nutzer oder Dienst, der die Funktion bereitstellt, die Berechtigung cloudfunctions.functions.setIamPolicy erteilen.

Fehlermeldung

gcloud

 ERROR: (gcloud.functions.add-iam-policy-binding) ResponseError: status=[403], code=[Forbidden], message=[Permission 'cloudfunctions.functions.setIamPolicy' denied on resource 'projects/PROJECT_ID/locations/LOCATION/functions/FUNCTION_NAME (or resource may not exist).]

Die Lösung

So beheben Sie diesen Fehler:

• Weisen Sie dem Bereitsteller die Rolle Projektinhaber oder Cloud Functions-Administrator zu. Beide haben die Berechtigung cloudfunctions.functions.setIamPolicy.

• Erteilen Sie die Berechtigung manuell. Erstellen Sie dazu eine benutzerdefinierte Rolle.

• Prüfen Sie, ob die domaineingeschränkte Freigabe für das Projekt erzwungen wird.

Die Bereitstellung der Funktion schlägt fehl, wenn die Organisationsrichtlinie „Beschränkung der Ressourcenstandorte“ verwendet wird

Wenn Ihre Organisation eine Richtlinie zur Beschränkung von Ressourcenstandorten verwendet, wird die Bereitstellung von Funktionen in den durch die Richtlinie eingeschränkten Regionen eingeschränkt. In der Google Cloud Console ist die eingeschränkte Region beim Bereitstellen einer Funktion nicht im Drop-down-Menü „Region“ verfügbar.

Fehlermeldung

gcloud

  ERROR: (gcloud.functions.deploy) ResponseError: status=[400], code=[Ok], message=[The request has violated one or more Org Policies. Please refer to the respective violations for more information. violations {
    type: "constraints/gcp.resourceLocations"
    subject: "orgpolicy:projects/PROJECT_ID"
    description: "Constraint constraints/gcp.resourceLocations violated for projects/PROJECT_ID attempting GenerateUploadUrlActionV1 with location set to RESTRICTED_LOCATION. See https://cloud.google.com/resource-manager/docs/organization-policy/org-policy-constraints for more information."
  }

Die Lösung

Fügen Sie Standorte zu den Listen allowed_values oder denied_values der Einschränkung der Ressourcenstandorte hinzu oder entfernen Sie sie daraus, damit die Bereitstellung erfolgreich ist.

Fehler bei der Funktionsbereitstellung während der Ausführung des globalen Bereichs der Funktion

Dieser Fehler gibt an, dass ein Problem mit Ihrem Code vorliegt. Die Bereitstellungspipeline hat die Bereitstellung der Funktion abgeschlossen, ist aber im letzten Schritt fehlgeschlagen. Es wird eine Systemdiagnose an die Funktion gesendet. Diese Systemdiagnose dient dazu, den globalen Bereich einer Funktion auszuführen, wodurch eine Ausnahme, ein Absturz oder eine Zeitüberschreitung ausgelöst werden kann. Im globalen Bereich werden Bibliotheken häufig geladen und Clients initialisiert.

Fehlermeldung

Console

Deployment failure: Function failed on loading user code. This is likely due to a bug in the user code.

gcloud

ERROR: (gcloud.functions.deploy) OperationError: code=3, message=Function
failed on loading user code. This is likely due to a bug in the user code.

In Cloud Logging-Logs:

  "Function failed on loading user code. This is likely due to a bug in the user code."

Die Lösung

Führen Sie einen der folgenden Schritte aus, um das Problem zu beheben:

• Eine ausführlichere Fehlermeldung finden Sie in den Build-Logs und den Laufzeit-Logs Ihrer Funktion.

• Wenn unklar ist, warum die Funktion ihren globalen Bereich nicht ausführen konnte, können Sie den Code vorübergehend mit der verzögerten Initialisierung der globalen Variablen in den Anfrageaufruf verschieben. Dadurch können Sie zusätzliche Logberichte zu Ihren Clientbibliotheken hinzufügen, die bei der Instanziierung möglicherweise eine Zeitüberschreitung auslösen (insbesondere wenn sie andere Dienste aufrufen) oder abstürzen oder Ausnahmen ausgeben.

• Erhöhen Sie das Zeitlimit für die Funktion.

• Der Quellcode muss eine Einstiegspunktfunktion enthalten, die in der Bereitstellung korrekt angegeben wurde, entweder über die Console oder gcloud.

Ein Nutzer mit der Rolle "Betrachter" kann keine Funktion bereitstellen.

Nutzer mit der Rolle „Projektbetrachter“ oder „Cloud Functions-Betrachter“ haben Lesezugriff auf Funktionen und Funktionsdetails und können keine neuen Funktionen bereitstellen. Die Funktion Funktion erstellen ist in der Google Cloud Console ausgegraut und Sie sehen den folgenden Fehler:

Fehlermeldung

gcloud

ERROR: (gcloud.functions.deploy) PERMISSION_DENIED: Permission
'cloudfunctions.functions.sourceCodeSet' denied on resource
'projects/PROJECT_ID/locations/LOCATION` (or resource may not exist)

Die Lösung

Weisen Sie dem Nutzer die Rolle Cloud Functions-Entwickler zu.

Build-Dienstkonto fehlt Berechtigungen

Fehlermeldung

Im Fehler beim Bereitstellen der Funktion oder in den Build-Logs wird möglicherweise einer der folgenden Fehler angezeigt:

The service account running this build does not have permission to write logs.
To fix this, grant the Logs Writer (roles/logging.logWriter) role to the service
account.

Step #0 - "fetch": failed to Fetch: failed to download archive gs://gcf-sources-PROJECT_NUMBER-LOCATION/FUNCTION_NAME/version-VERSION_NUMBER/function-source.zip: Access to bucket gcf-sources-PROJECT_NUMBER-LOCATION denied. You must grant Storage Object Viewer permission to [e-mail].

Step #2 - "build": ERROR: failed to create image cache: accessing cache image "LOCATION-docker.pkg.dev/PROJECT/gcf-artifacts/FUNCTION_NAME/cache:latest": connect to repo store "LOCATION-docker.pkg.dev/PROJECT/gcf-artifacts/FUNCTION_NAME/cache:latest": GET https://LOCATION-docker.pkg.dev/v2/token?scope=repository%3APROJECT%2Fgcf-artifacts%2FFUNCTION_NAME%2Fcache%3Apull&service=: DENIED: Permission "artifactregistry.repositories.downloadArtifacts" denied on resource "projects/PROJECT/locations/LOCATION/repositories/gcf-artifacts" (or it may not exist)

Could not build the function due to a missing permission on the build service account. If  you didn't revoke that permission explicitly, this could be caused by a change in the organization policies.

Die Lösung

Das Build-Dienstkonto benötigt Leseberechtigungen für den Quell-Bucket sowie Lese- und Schreibberechtigungen für das Artifact Deployment-Repository. Dieser Fehler kann aufgrund einer Änderung des Standardverhaltens für die Verwendung von Dienstkonten durch Cloud Build auftreten. Weitere Informationen finden Sie unter Änderung des Cloud Build-Dienstkontos.

Verwenden Sie eine der folgenden Lösungen, um dieses Problem zu beheben:

• Erstellen Sie ein benutzerdefiniertes Build-Dienstkonto für Funktionsbereitstellungen.
• Fügen Sie dem Standard-Compute-Dienstkonto die Rolle Cloud Build-Dienstkonto (roles/cloudbuild.builds.builder) hinzu.
• Lesen Sie die Cloud Build-Anleitung zu Änderungen am Standarddienstkonto und deaktivieren Sie diese Änderungen.

Build-Dienstkonto deaktiviert

Fehlermeldung

Could not build the function due to disabled service account used by Cloud Build. Please make sure that the service account is active.

Die Lösung

Das Build-Dienstkonto muss aktiviert sein, damit eine Funktion bereitgestellt werden kann. Dieser Fehler kann aufgrund einer Änderung des Standardverhaltens für die Verwendung von Dienstkonten durch Cloud Build auftreten. Weitere Informationen finden Sie unter Änderung des Cloud Build-Dienstkontos.

Verwenden Sie eine der folgenden Lösungen, um dieses Problem zu beheben:

• Erstellen Sie ein benutzerdefiniertes Build-Dienstkonto für Funktionsbereitstellungen.
• Aktivieren Sie das Standard-Compute-Dienstkonto.
• Lesen Sie die Cloud Build-Anleitung zu Änderungen am Standarddienstkonto und deaktivieren Sie diese Änderungen.

Bereitstellung

In diesem Abschnitt sind mögliche Probleme mit der Auslieferung sowie Vorschläge zu deren Behebung aufgeführt.

Berechtigungsfehler beim Bereitstellen aufgrund der Funktion, die eine Authentifizierung erfordert

HTTP-Funktionen ohne aktivierte nicht authentifizierte Aufrufe zulassen beschränken den Zugriff auf Endnutzer und Dienstkonten, die nicht die entsprechenden Berechtigungen haben.

Wenn Sie die Cloud Run-Funktions-URL in einem Browser aufrufen, wird der Authentifizierungsheader nicht automatisch hinzugefügt.

Fehlermeldung

HTTP-Fehlerantwortcode: 403 Unzulässig

HTTP-Fehlerantworttext:

Error: Forbidden Your client does not have permission
to get URL /FUNCTION_NAME from this server.

Die Lösung

So beheben Sie diesen Fehler:

• Weisen Sie dem Nutzer die Rolle Cloud Run-Funktionen-Aufrufer zu.

• Stellen Sie die Funktion noch einmal bereit, um nicht authentifizierte Aufrufe zuzulassen, wenn dies von Ihrer Organisation unterstützt wird. Dies kann zu Testzwecken nützlich sein.

Berechtigungsfehler beim Bereitstellen aufgrund der allow internal traffic only-Konfiguration

Mit den Einstellungen für eingehenden Traffic wird festgelegt, ob eine HTTP-Funktion von Ressourcen außerhalb des Google Cloud-Projekts oder des Dienstperimeters für VPC Service Controls aufgerufen werden kann. Wenn Sie für eingehenden Netzwerktraffic die Einstellung Nur internen Traffic zulassen konfigurieren, weist diese Fehlermeldung darauf hin, dass nur Anfragen von VPC-Netzwerken im selben Projekt oder Perimeter für VPC Service Controls zulässig sind.

Hinweis: Wenn Sie die Cloud Run-Funktions-URL in einem Browser aufrufen, wird der Authentifizierungsheader nicht automatisch hinzugefügt.

Fehlermeldung

HTTP-Fehlerantwortcode: 404 NICHT GEFUNDEN

HTTP-Fehlerantworttext:

404 Page not found

Die Lösung

So beheben Sie diesen Fehler:

• Prüfen Sie, ob die Anfrage von Ihrem Google Cloud-Projekt oder dem Dienstperimeter für VPC Service Controls stammt.

• Ändern Sie die Einstellungen für eingehenden Traffic so, dass der gesamte Traffic für die Funktion zugelassen wird.

• Der Quellcode von Cloud Run-Funktionen kann aufgrund einer falschen Funktions-URL, falscher HTTP-Methoden oder Logikfehler zu einem 404-Fehler führen.

Der Funktionsaufruf enthält keine gültigen Anmeldedaten für die Authentifizierung

Für Funktionen, die mit eingeschränktem Zugriff konfiguriert wurden, ist ein ID-Token erforderlich. Die Funktionsaufruf schlägt fehl, wenn Sie Zugriffstokens oder Aktualisierungstokens verwenden.

Fehlermeldung

HTTP-Fehlerantwortcode: 401 Nicht autorisiert

HTTP-Fehlerantworttext:

Your client does not have permission to the requested URL </FUNCTION_NAME>

Die Lösung

So beheben Sie diesen Fehler:

• Achten Sie darauf, dass Ihre Anfragen einen Authorization: Bearer ID_TOKEN-Header enthalten und das Token ein ID-Token und kein Zugriffs- oder Aktualisierungstoken ist. Wenn Sie dieses Token manuell mit dem privaten Schlüssel eines Dienstkontos generieren, müssen Sie das selbst signierte JWT-Token gegen ein von Google signiertes Identitätstoken austauschen. Weitere Informationen finden Sie unter Für Aufruf authentifizieren.

• Rufen Sie Ihre HTTP-Funktion mit Authentifizierungsdaten im Anfrageheader auf. So können Sie z. B. mit gcloud ein Identitätstoken abrufen:

  curl  -H "Authorization: Bearer $(gcloud auth print-identity-token)" \
    https://REGION-PROJECT_ID.cloudfunctions.net/FUNCTION_NAME

  Weitere Informationen finden Sie unter Für Aufruf authentifizieren .

Die Funktion wird während der Ausführung beendet oder nach Beendigung des Codes weiter ausgeführt.

Bei einigen Cloud Run-Laufzeiten können Nutzer asynchrone Aufgaben ausführen. Wenn Ihre Funktion solche Aufgaben erstellt, muss sie auch explizit warten, bis diese Aufgaben abgeschlossen sind. Andernfalls kann die Funktion mit der falschen Zeit nicht mehr ausgeführt werden.

Fehlerverhalten

Ihre Funktion zeigt eine dieser Verhaltenweisen:

• Ihre Funktion wird beendet, während asynchrone Aufgaben noch ausgeführt werden, bevor die festgelegte Zeitüberschreitung verstrichen ist.
• Die Ausführung der Funktion wird nicht gestoppt, wenn diese Aufgaben abgeschlossen sind, und wird bis zum Ablauf des Zeitlimits fortgesetzt.

Die Lösung

Wenn Ihre Funktion vorzeitig beendet wird, sollten Sie überprüfen, ob alle asynchronen Aufgaben der Funktion abgeschlossen sind, bevor die Funktion eine der folgenden Aktionen ausführt:

• Wert zurückgeben
• Ein zurückgegebenes Promise-Objekt auflösen oder ablehnen (nur Node.js-Funktionen)
• Nicht erfasste Ausnahmen und Fehler auslösen
• HTTP-Antwort senden
• Callback-Funktion aufrufen

Wenn Ihre Funktion nach Abschluss asynchroner Aufgaben nicht beendet wird, sollten Sie prüfen, ob die Funktion nach Abschluss alle Cloud Run-Funktionen richtig anzeigt. Wichtig ist, dass Sie eine der oben aufgeführten Vorgänge ausführen, sobald Ihre Funktion die asynchronen Aufgaben abgeschlossen hat.

Laufzeitfehler beim Zugriff auf Ressourcen, die durch VPC Service Controls geschützt sind

Cloud Run-Funktionen verwenden standardmäßig öffentliche IP-Adressen, um ausgehende Anfragen an andere Dienste zu senden. Funktionen, die sich nicht im VPC Service Controls-Perimeter befinden, erhalten möglicherweise HTTP-403-Antworten, wenn sie versuchen, auf Google Cloud-Dienste zuzugreifen, die durch VPC Service Controls aufgrund von Ablehnungen von Dienstperimetern geschützt sind.

Fehlermeldung

In Logs von geprüften Ressourcen ein Eintrag wie der Folgende:

"protoPayload": {
  "@type": "type.googleapis.com/google.cloud.audit.AuditLog",
  "status": {
    "code": 7,
    "details": [
      {
        "@type": "type.googleapis.com/google.rpc.PreconditionFailure",
        "violations": [
          {
            "type": "VPC_SERVICE_CONTROLS",
  ...
  "authenticationInfo": {
    "principalEmail": "CLOUD_FUNCTION_RUNTIME_SERVICE_ACCOUNT",
  ...
  "metadata": {
    "violationReason": "NO_MATCHING_ACCESS_LEVEL",
    "securityPolicyInfo": {
      "organizationId": "ORGANIZATION_ID",
      "servicePerimeterName": "accessPolicies/NUMBER/servicePerimeters/SERVICE_PERIMETER_NAME"
  ...

Die Lösung

So beheben Sie diesen Fehler:

• Die Funktion sollte den gesamten ausgehenden Traffic über das VPC-Netzwerk leiten. Weitere Informationen finden Sie im Abschnitt Funktionen bereitstellen, die mit VPC Service Controls kompatibel sind.

• Alternativ können Sie dem Laufzeitdienstkonto der Funktion Zugriff auf den Perimeter gewähren. Dazu erstellen Sie entweder eine Zugriffsebene und fügen die Zugriffsebene zum Dienstperimeter hinzu oder erstellen eine Ingress-Richtlinie für den Perimeter. Weitere Informationen finden Sie unter VPC Service Controls mit Funktionen außerhalb eines Perimeters verwenden.

Skalierbarkeit

In diesem Abschnitt sind Skalierungsprobleme sowie Vorschläge zu deren Behebung aufgeführt.

Cloud Logging-Fehler im Zusammenhang mit abgebrochenen ausstehenden Warteschlangenanfragen

Die folgenden Bedingungen können mit Skalierungsfehlern verknüpft sein.

• Ein starker Anstieg des Traffics.
• Lange Kaltstartzeit.
• Lange Verarbeitungszeit für Anfragen.
• Hohe Fehlerrate der Funktion.
• Das maximale Instanzlimit wird erreicht.
• Temporäre Faktoren, die dem Cloud Run Functions-Dienst zugeordnet sind.

In allen Fällen wird Cloud Run möglicherweise nicht schnell genug hochskaliert, um den Traffic zu verwalten.

Fehlermeldung

 The request was aborted because there was no available instance.

Für Cloud Run-Funktionen gibt es die folgenden Schweregrade:

* `severity=WARNING` ( Response code: 429 ) Cloud Run functions cannot scale due
  to the [`max-instances`](/functions/docs/configuring/max-instances) limit you set
  during configuration.
* `severity=ERROR` ( Response code: 500 ) Cloud Run functions intrinsically
  cannot manage the rate of traffic.

Die Lösung

• Implementieren Sie für HTTP-Trigger-basierte Funktionen exponentiellen Backoff und Wiederholungen für Anfragen, die nicht verworfen werden dürfen. Wenn Sie Cloud Run-Funktionen über Workflows auslösen, können Sie dazu die try/retry-Syntax verwenden.
• Für Hintergrund- oder ereignisgesteuerte Funktionen unterstützt Cloud Run Functions mindestens einmalige Übermittlung. Auch wenn die Wiederholung nicht explizit aktiviert wird, wird das Ereignis automatisch noch einmal gesendet und die Funktionsausführung wird wiederholt. Weitere Informationen finden Sie unter Wiederholungen für ereignisgesteuerte Funktionen aktivieren.
• Wenn die Ursache des Problems eine Periode erhöhter transienter Fehler ist, die ausschließlich Cloud Run-Funktionen zugeschrieben werden, oder wenn Sie Unterstützung bei Ihrem Problem benötigen, wenden Sie sich an den Cloud Customer Care.

Logging

Im folgenden Abschnitt werden Probleme mit dem Logging und deren Behebung beschrieben.

Logeinträge haben keine oder falsche Schweregradebenen

Cloud Run-Funktionen bieten standardmäßig Laufzeit-Logging. In stdout oder stderr geschriebene Logs werden automatisch in der Google Cloud Console angezeigt. Sie enthalten jedoch standardmäßig nur Stringnachrichten.

Die Lösung

Wenn Sie Log-Schweregrade einschließen möchten, müssen Sie stattdessen einen strukturierten Logeintrag senden.

Hinweis: Seit September 2020 verwendet jede neu veröffentlichte Laufzeit die standardmäßige Logebene für Schweregrade gemäß der Laufzeitbibliothek. Python 3.8 setzt die standardmäßige Logebene für Schweregrade beispielsweise auf WARNING oder höher. Wenn Sie Ereignisse mit dem Schweregrad DEBUG oder INFO mit Python 3.8 erfassen möchten, müssen Sie auch Ihre Logebene programmatisch so festlegen, dass diese Ebenen enthalten sind.

Ausnahmen bei einem Absturz anders behandeln oder protokollieren

Sie haben die Möglichkeit, die Verwaltung und das Logging von Absturzinformationen anzupassen.

Die Lösung

Das Wrappen Ihrer Funktion ist ein try-Block, mit dem die Handhabung von Ausnahmen und das Logging von Stacktraces angepasst werden kann.

Das Hinzufügen eines try-Blocks kann zu unbeabsichtigten Nebenwirkungen bei ereignisgesteuerten Funktionen mit der retry on failure-Konfiguration führen. Wiederholungen fehlgeschlagener Ereignisse können ebenfalls scheitern.

Beispiel

import logging
import traceback
def try_catch_log(wrapped_func):
  def wrapper(*args, **kwargs):
    try:
      response = wrapped_func(*args, **kwargs)
    except Exception:
      # Replace new lines with spaces so as to prevent several entries which
      # would trigger several errors.
      error_message = traceback.format_exc().replace('\n', '  ')
      logging.error(error_message)
      return 'Error';
    return response;
  return wrapper;

#Example hello world function

@try_catch_log
def python_hello_world(request):
  request_args = request.args

  if request_args and 'name' in request_args:
    1 + 's'
  return 'Hello World!'

Logs zu groß in Node.js 10 und höher sowie in Python 3.8, Go 1.13 und Java 11

Die maximale Größe für einen regulären Logeintrag in diesen Laufzeiten ist 105 KiB.

Die Lösung

Senden Sie Logeinträge, die kleiner als dieses Limit sind.

Fehlende Protokolle, obwohl Cloud Run-Funktionen Fehler zurückgeben

Cloud Run Functions streamt Cloud Run-Funktionsprotokolle in einen Standard-Bucket. Wenn Sie ein Projekt erstellen, wird der Standard-Bucket von Cloud Run-Funktionen erstellt und aktiviert. Wenn der Standard-Bucket deaktiviert ist oder wenn sich Cloud Run-Funktions-Logs im Ausschlussfilter befinden, werden die Logs nicht im Log-Explorer angezeigt.

Die Lösung

Aktivieren Sie Standardprotokolle und achten Sie darauf, dass kein Ausschlussfilter festgelegt ist.

Hinweis: Beim Aktivieren von Cloud Logging können Gebühren anfallen.

Cloud Run-Funktionslogs werden nicht im Log-Explorer angezeigt

Einige Cloud Logging-Clientbibliotheken verwenden einen asynchronen Prozess, um Logeinträge zu schreiben. Wenn eine Funktion abstürzt oder anderweitig beendet wird, ist es möglich, dass einige Logeinträge noch nicht geschrieben wurden und später angezeigt werden. Es ist auch möglich, dass einige Logs verloren gehen und im Log-Explorer nicht sichtbar sind.

Die Lösung

Verwenden Sie die Benutzeroberfläche der Clientbibliothek, um gepufferte Logeinträge zu leeren, bevor Sie die Funktion beenden, oder verwenden Sie die Bibliothek, um Logeinträge synchron zu schreiben. Sie können Logs auch synchron direkt in stdout oder stderr schreiben.

Cloud Run-Funktionslogs werden nicht über die Logs Router-Senke angezeigt

Logs Router-Senken leiten Logeinträge an verschiedene Ziele weiter.

In den Einstellungen sind Ausschlussfilter enthalten, mit denen Einträge definiert werden, die sich verwerfen lassen.

Die Lösung

Entfernen Sie den Ausschlussfilter für resource.type="cloud_functions".

Datenbankverbindungen

Viele Datenbankfehler hängen mit dem Überschreiten der Verbindungslimits oder der Zeitüberschreitung zusammen. Wenn in Ihren Logs eine Cloud SQL-Warnung angezeigt wird, z. B. Context deadline exceeded, müssen Sie möglicherweise Ihre Verbindungskonfiguration anpassen. Weitere Informationen finden Sie unter Best Practices für Cloud SQL.

Netzwerk

In diesem Abschnitt sind Netzwerkprobleme sowie Vorschläge zu deren Behebung aufgeführt.

Netzwerkverbindung

Wenn alle ausgehenden Anfragen von einer Cloud Run-Funktion auch nach dem Konfigurieren der Einstellungen für ausgehenden Traffic fehlschlagen, können Sie Konnektivitätstests ausführen, um alle zugrunde liegenden Netzwerkverbindungsprobleme zu identifizieren. Weitere Informationen finden Sie unter Konnektivitätstests erstellen und ausführen.

Connector für serverlosen VPC-Zugriff ist nicht bereit oder nicht vorhanden

Wenn ein Connector für Serverloser VPC-Zugriff fehlschlägt, wird möglicherweise keine /28-Subnetzmaske als erforderlich für den Connector verwendet.

Fehlermeldung

VPC connector projects/xxxxx/locations/REGION/connectors/xxxx
is not ready yet or does not exist.

Wenn Cloud Run-Funktionen mit einem Connector bereitgestellt werden, der aufgrund einer fehlenden Berechtigung für das Dienstkonto „Google APIs Service Agent“ [e-mail] in einem fehlerhaften Status ist, wird die folgende Fehlermeldung ausgegeben:

Fehlermeldung

Failed to prepare VPC connector. Please try again later.

Die Lösung

Listen Sie Ihre Subnetze auf, um zu prüfen, ob Ihr Connector eine /28-Subnetzmaske verwendet. Wenn für Ihren Connector nicht die Subnetzmaske /28 verwendet wird, erstellen Sie einen neuen Connector oder stellen Sie den vorhandenen wieder her.

Führen Sie einen der folgenden Schritte aus, um das Problem zu beheben:

• Wenn Sie den Connector neu erstellen, müssen Sie andere Funktionen nicht noch einmal bereitstellen. Während der Connector neu erstellt wird, kann es zu einer Netzwerkunterbrechung kommen.

• Wenn Sie einen neuen alternativen Connector erstellen, stellen Sie Ihre Funktionen neu bereit, damit der neue Connector verwendet wird, und löschen Sie dann den ursprünglichen Connector. Bei dieser Methode wird eine Netzwerkunterbrechung vermieden.

• Die Cloud Run-Funktionen und der zugehörige Connector müssen in derselben Region bereitgestellt werden.

• Für die Konfiguration der freigegebene VPC gilt Folgendes :

  • Achten Sie darauf, dass den Dienstkonten [e-mail] und [e-mail], die vom VPC-Connector zum Bereitstellen von Ressourcen im Projekt verwendet werden, keine Berechtigungen fehlen. Diese Dienstkonten sollten die Rolle roles/compute.networkUser im Hostprojekt der freigegebene VPC-Konfiguration haben, wenn sich der Connector im Dienstprojekt befindet. Andernfalls ist roles/compute.networkAdmin erforderlich.

  • Wenn der Connector im Hostprojekt erstellt wird, muss die Rolle Serverless VPC Access User Cloud Run functions Service Agent im Hostprojekt gewährt werden.

  • Wenn der Status des Connectors den Fehler Connector is in a bad state, manual deletion recommended anzeigt und dem Google APIs-Dienst-Agent die erforderlichen Berechtigungen zum Bereitstellen von Rechenressourcen im Projekt des Connectors fehlen, gewähren Sie dem Dienstkonto [e-mail] die Berechtigung roles/compute.admin. In einigen Fällen müssen Sie den Connector nach dem Aktualisieren der Berechtigungen neu erstellen.

Der SMTP-Traffic zu externen Ziel-IP-Adressen, die den TCP-Port 25 verwenden, ist blockiert

Für zusätzliche Sicherheit blockiert Google Cloud Verbindungen zum TCP-Zielport 25, wenn E-Mails von Cloud Run-Funktionen gesendet werden.

Die Lösung

Wählen Sie eine der folgenden Optionen aus, um die Blockierung dieser Verbindungen aufzuheben:

• Stellen Sie über einen anderen Port, z. B. TCP-Port 587 oder 465, eine Verbindung zu Ihrem SMTP-Server her.

• E-Mail-Dienst eines Drittanbieters verwenden

Sonstiges

In diesem Abschnitt werden zusätzliche Probleme beschrieben, die nicht in andere Kategorien fallen, und es werden Lösungen für jedes Problem angeboten.

VPC Service Controls-Fehler bei Methode google.storage.buckets.testIamPermissions in Cloud-Audit-Logs

Wenn Sie in der Google Cloud Console die Seite Funktionsdetails öffnen, wird geprüft, ob Sie das Speicher-Repository des Container-Images ändern und öffentlich darauf zugreifen können. Zur Bestätigung sendet Cloud Run Functions eine Anfrage an den Container Registry-Bucket mit der Methode google.storage.buckets.testIamPermissions im folgenden Format: [REGION].artifacts.[PROJECT_ID].appspot.com. Der einzige Unterschied zwischen den Prüfungen besteht darin, dass bei der einen mit Authentifizierung geprüft wird, ob der Nutzer Berechtigungen zum Ändern des Speicherorts hat, während bei der anderen ohne Authentifizierung geprüft wird, ob der Speicherort öffentlich zugänglich ist.

Wenn die storage.googleapis.com API durch den VPC Service Controls-Perimeter eingeschränkt ist, wird in der Google Cloud Console in den Cloud-Audit-Logs ein Fehler für die google.storage.buckets.testIamPermissions-Methode angezeigt.

Fehlermeldung

Bei der Prüfung des öffentlichen Zugriffs ohne Authentifizierungsinformationen enthält das Audit-Log für die VPC SC-Richtlinie zum Ablehnen von Zugriffen einen Eintrag ähnlich dem folgenden:

"protoPayload": {
  "@type": "type.googleapis.com/google.cloud.audit.AuditLog",
  "status": {
    "code": 7,
    "details": [
      {
        "@type": "type.googleapis.com/google.rpc.PreconditionFailure",
        "violations": [
          {
            "type": "VPC_SERVICE_CONTROLS",
  ...
  "authenticationInfo": {},
  "requestMetadata": {
    "callerIp": "END_USER_IP"
  },
  "serviceName": "storage.googleapis.com",
  "methodName": "google.storage.buckets.testIamPermissions",
  "resourceName": "projects/PROJECT_NUMBER",
  "metadata": {
    "ingressViolations": [
      {
        "servicePerimeter": "accessPolicies/ACCESS_POLICY_ID/servicePerimeters/VPC_SC_PERIMETER_NAME",
        "targetResource": "projects/PROJECT_NUMBER"
      }
    ],
    "resourceNames": [
      "projects/_/buckets/REGION.artifacts.PROJECT_ID.appspot.com"
    ],
    "securityPolicyInfo": {
      "servicePerimeterName": "accessPolicies/ACCESS_POLICY_ID/servicePerimeters/VPC_SC_PERIMETER_NAME",
      "organizationId": "ORG_ID"
    },
    "violationReason": "NO_MATCHING_ACCESS_LEVEL",
  ...

Bei der Prüfung des öffentlichen Zugriffs mit Authentifizierungsinformationen enthält das Audit-Log für die VPC SC-Ablehnungsrichtlinie einen Eintrag, mit dem der Nutzer die Bucket-Einstellungen ähnlich wie im folgenden Beispiel ändern kann:

"protoPayload": {
  "@type": "type.googleapis.com/google.cloud.audit.AuditLog",
  "status": {
    "code": 7,
    "details": [
      {
        "@type": "type.googleapis.com/google.rpc.PreconditionFailure",
        "violations": [
          {
            "type": "VPC_SERVICE_CONTROLS",
  ...
  "authenticationInfo": {
    "principalEmail": "END_USER_EMAIL"
  },
  "requestMetadata": {
    "callerIp": "END_USER_IP",
    "requestAttributes": {},
    "destinationAttributes": {}
  },
  "serviceName": "storage.googleapis.com",
  "methodName": "google.storage.buckets.testIamPermissions",
  "resourceName": "projects/PROJECT_NUMBER",
  "metadata": {
    "ingressViolations": [
      {
        "servicePerimeter": "accessPolicies/ACCESS_POLICY_ID/servicePerimeters/VPC_SC_PERIMETER_NAME",
        "targetResource": "projects/PROJECT_NUMBER"
      }
    ],
    "resourceNames": [
      "projects/_/buckets/REGION.artifacts.PROJECT_ID.appspot.com"
    ],
    "securityPolicyInfo": {
      "servicePerimeterName": "accessPolicies/ACCESS_POLICY_ID/servicePerimeters/VPC_SC_PERIMETER_NAME",
      "organizationId": "ORG_ID"
    },
    "violationReason": "NO_MATCHING_ACCESS_LEVEL",
  ...

Die Lösung

Wenn der Container Registry-Bucket nicht öffentlich zugänglich ist, können Sie die VPC Service Controls-Fehler ignorieren.

Alternativ können Sie eine Eingangsregel für VPC Service Controls hinzufügen, um die google.storage.buckets.testIamPermissions-Methode zuzulassen, wie im folgenden Beispiel gezeigt:

ingress_from {
  sources {
    access_level: "*"
  }
  identity_type: ANY_IDENTITY
}
ingress_to {
  operations {
    service_name: "storage.googleapis.com"
    method_selectors {
      method: "google.storage.buckets.testIamPermissions"
    }
  }
  resources: "projects/PROJECT_NUMBER"
}

Nach Möglichkeit können Sie die Ingress-Regel weiter verfeinern, indem Sie die Zugriffsebene mit Nutzer-IP-Adressen definieren.