Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
In Error Reporting werden Fehler aus Ihren laufenden Cloud-Diensten zusammengefasst. Diese Fehler werden entweder von der Error Reporting API gemeldet oder als Fehler erkannt, wenn Error Reporting Logeinträge auf häufige Textmuster wie Stacktraces untersucht. Error Reporting gruppiert Fehler, von denen angenommen wird, dass sie dieselbe Ursache haben.
Error Reporting wird automatisch aktiviert.
Error Reporting zeigt bis zu 1.000 Fehlerbeispiele pro Stunde.
Ist dieses Limit erreicht, wird eine Schätzung der Anzahl angezeigt. Wenn zu viele Ereignisse erfasst wurden, kann Error Reporting 100 Fehlerbeispiele pro Stunde anzeigen und die Anzahl danach hochrechnen.
Wann analysiert Error Reporting Logeinträge?
Error Reporting ist ein globaler Dienst, der auf Cloud Logging basiert und Logeinträge analysieren kann, wenn alle folgenden Bedingungen erfüllt sind:
Vom Kunden verwaltete Verschlüsselungsschlüssel (CMEK) sind für alle Log-Buckets deaktiviert, in denen der Logeintrag gespeichert wird. In Error Reporting können keine Logeinträge in Log-Buckets mit aktiviertem CMEK gespeichert werden. Informationen dazu, wie Sie die CMEK-Konfiguration für einen Log-Bucket ermitteln, finden Sie unter Schlüsselaktivierung prüfen.
Der Log-Bucket erfüllt eine der folgenden Bedingungen:
Der Log-Bucket wird im selben Projekt gespeichert, aus dem die Logeinträge stammen.
Die Logeinträge wurden an ein Projekt weitergeleitet und dieses Projekt hat die Logeinträge dann in einem eigenen Log-Bucket gespeichert.
Informationen zu Fehlergruppierungen
Bei der Auswertung von Logeinträgen ignoriert Error Reporting Logeinträge mit den folgenden Bedingungen:
In einer App-Engine-Standardumgebung werden Fehler mit einem geringeren Schweregrad als ERROR ignoriert.
Stapelframes, die keinem Nutzer gehören, werden ignoriert (z. B. wenn diese zu einer öffentlichen Bibliothek gehören).
Sequenzen, die sich für mehr als einen Stack-Frame wiederholen, werden durch ein einzelnes Vorkommen für diese Sequenz ersetzt.
Methoden und Symbole des Compilers werden entfernt.
Als Nächstes werden Fehler in Error Reporting nach folgenden Regeln gruppiert:
Ausnahmen werden gruppiert, wenn die Ausnahme gleich und die Stacks ähnlich sind.
Der Stacktrace wird für Ausnahmen, die in der Regel nicht in Zusammenhang mit der Quelle stehen, ignoriert.
Fehler ohne Ausnahme-Stack werden gruppiert, wenn sie vom gleichen Logeintrag erstellt wurden, angenähert vom Ort der Quelle, aus der sie gemeldet wurden (reportLocation).
Konkret werden die folgenden Gruppierungsregeln in dieser Reihenfolge angewendet:
Fehlertyp
Gruppiert nach
Fehler durch ein allgemeines Problem in der Umgebung.
Fehler mit einem Stacktrace. Im Fall von verschachtelten Ausnahmen wird die innerste Ausnahme berücksichtigt.
Beispiel:
runtime error: index out of range
package1.func1()
file1:20
package2.func2()
file2:33
Gruppiert nach Ausnahmetyp und den 5 meistgenutzten Frames
Fehler ohne Stacktrace, aber mit einer Meldung.
Beispiel:
runtime error: index out of range
func1()
Gruppiert nach Meldung und Funktionsname (falls vorhanden). nur die ersten 3 Literal-Tokens der Nachricht werden berücksichtigt. Im Beispiel links sind dies runtime, error und index.
Regionalität der Daten
Wenn Sie Assured Workloads für Anforderungen an den Datenstandort oder Impact Level 4 (IL4) einrichten, wird Error Reporting automatisch deaktiviert. Google Cloud
In Cloud Logging können Sie Ihre Logs regionalisieren, indem Sie sie an einen bestimmten Standort weiterleiten. Auf der Seite Fehlergruppen werden Fehlergruppen in Error Reporting anhand der Region des Log-Buckets, der die Logeinträge enthält, organisiert und angezeigt. Eine Fehlergruppe, die unter us-central-1 aufgeführt ist, enthält beispielsweise nur Fehlerlogs, die zu einem Log-Bucket in us-central-1 gehören. Globale Fehlergruppen enthalten nur Fehlerlogs, die zu einem Log-Bucket in der Region global gehören.
Wenn Sie die Region der auf der Seite Fehlergruppen angezeigten Fehlergruppen filtern möchten, wählen Sie einen Wert aus dem Menü Region aus. Das Menü hat den Standardwert global.
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Schwer verständlich","hardToUnderstand","thumb-down"],["Informationen oder Beispielcode falsch","incorrectInformationOrSampleCode","thumb-down"],["Benötigte Informationen/Beispiele nicht gefunden","missingTheInformationSamplesINeed","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 2025-08-11 (UTC)."],[[["\u003cp\u003eError Reporting aggregates and groups errors from cloud services, either reported via its API or inferred from log entries that match common error patterns like stack traces.\u003c/p\u003e\n"],["\u003cp\u003eThe service is automatically enabled, sampling up to 1,000 errors per hour, and if this limit is exceeded, it scales down to 100 errors per hour while extrapolating counts.\u003c/p\u003e\n"],["\u003cp\u003eError Reporting's log analysis depends on certain conditions, including disabled Assured Workloads and customer-managed encryption keys (CMEK) on log buckets, unless the Error Reporting API or client libraries are utilized.\u003c/p\u003e\n"],["\u003cp\u003eError grouping is based on factors like exception type, stack trace similarity, message content, and source location, with specific rules for errors with or without stack traces.\u003c/p\u003e\n"],["\u003cp\u003eError Reporting is a global service, but error groups can be filtered by the region of the log bucket containing the error logs, though the service itself can access error data from any region.\u003c/p\u003e\n"]]],[],null,["Error Reporting aggregates errors produced in your running cloud\nservices. These errors are either reported by the\n[Error Reporting API](/error-reporting/reference/rest) or are inferred\nto be errors when Error Reporting inspects log entries for common\ntext patterns such as stack traces. Error Reporting groups errors\nwhich are considered to have the same root cause.\n\nError Reporting is automatically enabled.\n\nError Reporting samples up to 1,000 errors per hour.\nWhen this\nlimit is reached, the displayed counts are estimated. If too many events are\nreceived, then Error Reporting samples up to\n100 errors per hour and continue to extrapolate the counts.\n\nWhen Error Reporting analyzes log entries\n\nError Reporting is a global service built on\nCloud Logging and can analyze log entries when all of the following are true:\n\n- Assured workloads are disabled. For more information, see [Overview of Assured Workloads](/assured-workloads/docs/overview).\n- [Customer-managed encryption keys (CMEK)](/logging/docs/routing/managed-encryption-storage) are disabled on all log buckets that store the log entry. Error Reporting can't store log entries in log buckets that have CMEK enabled. For information about how to determine the CMEK configuration for a log bucket, see [Verify key enablement](/logging/docs/routing/managed-encryption-storage#verify-key).\n- The log bucket satisfies one of the following:\n - The log bucket is stored in the same project where the log entries originated.\n - The log entries were routed to a project, and then that project stored those log entries in a log bucket that it owns.\n\n\u003cbr /\u003e\n\nHow errors are grouped\n\nWhen Error Reporting evaluates log entries, it ignores\nlog entries with the following conditions:\n\n- On App Engine standard environment, errors logged with a severity lower than `ERROR` are ignored.\n- Stack frames which are not owned by the user are ignored (for instance, those that belong to public libraries).\n- Any repeating sequence of one or more stack frames is replaced by a single occurrence of that sequence.\n- Compiler-introduced methods and symbols are removed.\n\nNext, Error Reporting follows these rules to group errors:\n\n- Exceptions are grouped together if they have the same exception type and similar stacks.\n- The stack trace is ignored for exceptions that are typically unrelated to the source location where they occur.\n- Errors without an exception stack are grouped together if they were created by the same log entry, approximated by the source location it was reported from (`reportLocation`).\n\nSpecifically, the following grouping rules are applied in this order:\n\n| Error type | Grouped by |\n|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| **Errors caused by a general problem in the environment** . For example, App Engine specific problems: ``` com.google.apphosting.runtime.HardDeadlineExceededError ``` ``` com.google.appengine.api.datastore.DatastoreTimeoutException ``` Java problems: ``` java.util.concurrent.CancellationException ``` | Grouped by exception type. |\n| **Errors with a stack trace** . In the case of nested exceptions, the innermost exception is considered. For example: ``` runtime error: index out of range package1.func1() file1:20 package2.func2() file2:33 ``` | Grouped by exception type and the 5 top-most frames. |\n| **Errors without a stack trace, but with a message.** For example: ``` runtime error: index out of range func1() ``` | Grouped by message and (if present) function name. Only the first 3 literal tokens of the message are considered. In the example to the left, these are `runtime`, `error`, and `index`. |\n\nData regionality\n\nIf you set up [Assured Workloads](/assured-workloads)\nfor data-residency or [Impact Level 4 (IL4)](/security/compliance/disa)\nrequirements, then Google Cloud automatically disables\nError Reporting.\n\nIn Cloud Logging, you can [regionalize your logs](/logging/docs/regionalized-logs) by routing\nthem to a specific location. On the **Error Groups** page,\nError Reporting organizes and shows error groups based on the\nregion of the log bucket that contains the log entries. For example,\nan error group listed under `us-central-1` contains only error logs\nthat are part of a log bucket in `us-central-1`. Global error groups contain\nonly error logs that are part of a log bucket in the `global` region.\n\nTo filter the region of the error groups displayed on the **Error Groups** page,\nselect a value from the **Region** menu. This menu has a default value of\n`global`.\n\n| **Note:** Because Error Reporting is a global service, error groups can be accessed from any region. This behavior isn't configurable.\n\nWhat's next\n\n- [Collect error data by using Error Reporting](/error-reporting/docs/setup)\n- [View errors](/error-reporting/docs/viewing-errors)"]]
