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.
Führen Sie den folgenden Befehl aus, um eine Liste der von Ihnen konfigurierten Senken aufzurufen:
gcloud logging sinks list
Die Ausgabe des Befehls sieht in etwa so aus:
NAME DESTINATION FILTER
_Default logging.googleapis.com/projects/my-team-project/locations/global/buckets/_Default NOT LOG_ID("cloudaudit.googleapis.com/activity") AND NOT LOG_ID("externalaudit.googleapis.com/activity") AND NOT LOG_ID("cloudaudit.googleapis.com/system_event") AND NOT LOG_ID("externalaudit.googleapis.com/system_event") AND NOT LOG_ID("cloudaudit.googleapis.com/access_transparency") AND NOT LOG_ID("externalaudit.googleapis.com/access_transparency")
_Required logging.googleapis.com/projects/my-team-project/locations/global/buckets/_Required LOG_ID("cloudaudit.googleapis.com/activity") OR LOG_ID("externalaudit.googleapis.com/activity") OR LOG_ID("cloudaudit.googleapis.com/system_event") OR LOG_ID("externalaudit.googleapis.com/system_event") OR LOG_ID("cloudaudit.googleapis.com/access_transparency") OR LOG_ID("externalaudit.googleapis.com/access_transparency")
logs-from-samples logging.googleapis.com/projects/my-team-project/locations/global/buckets/sample-bucket (empty filter)
regional_logs logging.googleapis.com/projects/my-team-project/locations/europe-west1/buckets/bucket_for_regional_logs (empty filter)
test-logs logging.googleapis.com/projects/team-b-project/locations/global/buckets/test-bucket (empty filter)
In diesem Beispiel lautet das Google Cloud -Quellprojekt der Logeinträge my-team-project. Deshalb gilt Folgendes:
Error Reporting kann die Logeinträge analysieren, die von den Senken _Default, _Required und logs-from-samples weitergeleitet werden, da der Log-Bucket vom selben Projekt gespeichert wird, das die Logeinträge weiterleitet.
Error Reporting kann die Logeinträge, die im Log-Bucket mit dem Namen test-logs gespeichert sind, nicht analysieren, da die Senke in my-team-project die Logeinträge an einen Log-Bucket in einem anderen Projekt weiterleitet.
In diesem Abschnitt finden Sie Unterstützung bei der Fehlerbehebung, wenn Ihre Fehlerdaten in Cloud Logging-Buckets geschrieben werden und Sie sich darauf verlassen, dass Error Reporting diese Log-Buckets automatisch analysiert.
Beispiel-Logeintrag generieren
Wenn Sie Ihre Projekteinstellungen bestätigen möchten, können Sie einen Logeintrag programmatisch generieren, der von Error Reporting erfasst wird. Verwenden Sie dazu den folgenden gcloud-Befehl:
gcloudloggingwrite--payload-type=jsontest-errors-log\
'{"serviceContext":{"service":"manual-testing"},"message":"Test Error\n at /test.js:42:42","context":{"httpRequest":{"url":"/test","method":"GET","responseStatusCode":500}}}'
Öffnen Sie dann Error Reporting und bestätigen Sie, dass der gerade erstellte Fehler angezeigt wird.
Format des Logeintrags bestätigen
Rufen Sie die Cloud Logging-Seite auf und suchen Sie nach einem Logeintrag, der von Ihrer Anwendung gesendete Ausnahmedaten enthält.
Vergewissern Sie sich, dass der Log-Eintrag dem
erwarteten Format entspricht.
Versuchen Sie, manuell einen Fehler an den Dienst zu senden.
Sie können einen Testfehler an Error Reporting mithilfe des folgenden gcloud-Befehls melden:
gcloudbetaerror-reportingeventsreport--serviceManual--service-versiontest1\--message"java.lang.TestError: msg at com.example.TestClass.test(TestClass.java:51) at com.example.AnotherClass(AnotherClass.java:25)"
Sie können einen cURL-Befehl verwenden, um Ihre REST API-Aufrufe zu testen. Ersetzen Sie
PROJECT_ID und API_KEY mit Ihren gültigen Werten, bevor Sie den folgenden
Befehl senden:
Achten Sie darauf, dass Ihre Anwendung Ausnahmedaten im richtigen Format an die API sendet und dass diese die erforderlichen Attribute enthalten.
Ein Stacktrace wird protokolliert, aber nicht von Error Reporting erkannt
Sie protokollieren einen Fehler mit dem Feld message eines jsonPayload und erwarten, dass Error Reporting den Fehler erfasst. Die Fehlerdaten werden jedoch nicht erfasst.
Versuchen Sie Folgendes, um diesen Fehler zu beheben:
Achten Sie darauf, dass jsonPayload kein Feld stack_trace oder exception enthält. Wenn diese Felder vorhanden sind, wird das Feld message nicht ausgewertet.
Achten Sie darauf, dass die Struktur des Stacktrace einem der unterstützten Formate für Programmiersprachen entspricht.
Die Stacktraces werden von Error Reporting nicht erfasst, wenn ein nicht unterstütztes Format verwendet wird.
[[["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-09-03 (UTC)."],[[["\u003cp\u003eError Reporting analyzes log entries if Assured Workloads and Customer-Managed Encryption Keys (CMEK) are disabled, and the log bucket is in the same project as the log entries or routed to a project that stores them.\u003c/p\u003e\n"],["\u003cp\u003eIf using CMEK-enabled log buckets, utilize Error Reporting client libraries or the API, and verify project settings by generating a sample log entry via the \u003ccode\u003egcloud\u003c/code\u003e command.\u003c/p\u003e\n"],["\u003cp\u003eConfirm log entries follow the expected format, as detailed in the documentation, by checking a log entry with exception data in Cloud Logging.\u003c/p\u003e\n"],["\u003cp\u003eWhen using the Error Reporting API, ensure it is enabled and send test errors using \u003ccode\u003egcloud\u003c/code\u003e commands or cURL, and verify that the exception data sent by the application is in the correct format with required attributes.\u003c/p\u003e\n"],["\u003cp\u003eIf a stack trace is not captured by Error Reporting, ensure that \u003ccode\u003ejsonPayload\u003c/code\u003e does not contain \u003ccode\u003estack_trace\u003c/code\u003e or \u003ccode\u003eexception\u003c/code\u003e fields, and that the stack trace format is one of the supported programming language formats.\u003c/p\u003e\n"]]],[],null,["If your application errors are not showing up in Error Reporting,\nthen use the following steps to troubleshoot.\n\nBefore you begin\n\n1. Verify that Error Reporting can analyze your log entries.\n\n Error Reporting is a global service built on\n Cloud 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\n To see a list of sinks you have configured, run the following command: \n\n gcloud logging sinks list\n\n The command returns an output similar to the following: \n\n NAME DESTINATION FILTER\n _Default logging.googleapis.com/projects/my-team-project/locations/global/buckets/_Default NOT LOG_ID(\"cloudaudit.googleapis.com/activity\") AND NOT LOG_ID(\"externalaudit.googleapis.com/activity\") AND NOT LOG_ID(\"cloudaudit.googleapis.com/system_event\") AND NOT LOG_ID(\"externalaudit.googleapis.com/system_event\") AND NOT LOG_ID(\"cloudaudit.googleapis.com/access_transparency\") AND NOT LOG_ID(\"externalaudit.googleapis.com/access_transparency\")\n _Required logging.googleapis.com/projects/my-team-project/locations/global/buckets/_Required LOG_ID(\"cloudaudit.googleapis.com/activity\") OR LOG_ID(\"externalaudit.googleapis.com/activity\") OR LOG_ID(\"cloudaudit.googleapis.com/system_event\") OR LOG_ID(\"externalaudit.googleapis.com/system_event\") OR LOG_ID(\"cloudaudit.googleapis.com/access_transparency\") OR LOG_ID(\"externalaudit.googleapis.com/access_transparency\")\n logs-from-samples logging.googleapis.com/projects/my-team-project/locations/global/buckets/sample-bucket (empty filter)\n regional_logs logging.googleapis.com/projects/my-team-project/locations/europe-west1/buckets/bucket_for_regional_logs (empty filter)\n test-logs logging.googleapis.com/projects/team-b-project/locations/global/buckets/test-bucket (empty filter)\n\n In this example, the source Google Cloud project of the log entries is\n `my-team-project`. As a result:\n - Error Reporting can analyze the log entries routed by the `_Default`, `_Required`, and `logs-from-samples` sinks because the log bucket is stored by the same project that routes the log entries.\n - Error Reporting can't analyze the log entries stored in the log bucket named `test-logs` because the sink in `my-team-project` routes the log entries to a log bucket in a different project.\n2. Ensure that you have the\n [Google Cloud CLI installed](/sdk/docs/install#installation_instructions).\n\n3. Ensure that you have the\n [`beta` component enabled for the gcloud CLI](/sdk/docs/components#alpha_and_beta_components).\n\nWhen using logs\n\nThis section provides troubleshooting support when your error data is written\nto Cloud Logging buckets, and you rely on Error Reporting\nto automatically analyze those log buckets.\n\nGenerate a sample log entry\n\nTo confirm your project settings, you can programmatically generate a log entry\nthat will be picked up by Error Reporting with the following `gcloud`\ncommand: \n\n gcloud logging write --payload-type=json test-errors-log \\\n '{\"serviceContext\":\n {\"service\": \"manual-testing\"},\n \"message\": \"Test Error\\n at /test.js:42:42\",\n \"context\": {\"httpRequest\":\n {\"url\": \"/test\",\"method\": \"GET\",\"responseStatusCode\": 500}}}'\n\nThen open [Error Reporting](https://console.cloud.google.com/errors) and confirm\nthat you see the newly created error.\n\nConfirm the log entry format\n\nNavigate to the [Cloud Logging page](https://console.cloud.google.com/logs) and locate\na log entry that contains exception data sent from your application.\n\nConfirm that the log entry uses the\n[expected format](/error-reporting/docs/formatting-error-messages).\n\nWhen using the Error Reporting API\n\n1.\n\n\n Enable the required API.\n\n\n [Enable the API](https://console.cloud.google.com/flows/enableapi?apiid=clouderrorreporting.googleapis.com)\n2. Send a test error\n\n Try sending an error to the service manually.\n\n You can report a test error to Error Reporting using the following\n `gcloud` command: \n\n gcloud beta error-reporting events report --service Manual --service-version test1 \\\n --message \"java.lang.TestError: msg\n at com.example.TestClass.test(TestClass.java:51)\n at com.example.AnotherClass(AnotherClass.java:25)\"\n\n You can use a cURL command to test your REST API calls. Replace\n `PROJECT_ID` and `API_KEY` with your valid values before sending the following\n command: \n\n curl -X POST -H \"Content-Type: application/json\" \\\n -d '{\"message\":\"java.lang.TestError: msg\\n\\tat com.example.TestClass.test(TestClass.java:51)\\n\\tat com.example.AnotherClass(AnotherClass.java:25)\",\"serviceContext\":{\"service\":\"manual-testing\"}}' \\\n https://clouderrorreporting.googleapis.com/v1beta1/projects/\u003cvar translate=\"no\"\u003ePROJECT_ID\u003c/var\u003e/events:report?key=\u003cvar translate=\"no\"\u003eAPI_KEY\u003c/var\u003e\n\n3. Confirm the sent payload\n\n Ensure that your application is sending exception data to the API in the\n [correct format](/error-reporting/docs/formatting-error-messages) and that it\n contains the required attributes.\n\nA stack trace is logged but not recognized by Error Reporting\n\nYou log an error by using the `message` field of a `jsonPayload`, and you expect\nError Reporting to capture the error. However, the error data\nisn't captured.\n\nTo resolve this failure, try the following:\n\n- Ensure that the `jsonPayload` doesn't include a `stack_trace` or `exception`\n field. When those fields are present, the `message` field isn't evaluated.\n\n- Ensure that the structure of the stack trace is in\n [one of the supported programming language formats](/error-reporting/reference/rest/v1beta1/projects.events/report#ReportedErrorEvent).\n The stack trace isn't captured by Error Reporting\n when an unsupported format is used.\n\nFor more information, see\n[Format errors in logs](/error-reporting/docs/formatting-error-messages)."]]
