Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
Error Reporting regroupe les erreurs générées dans vos services cloud en cours d'exécution. Ces erreurs sont signalées par l'API Error Reporting ou sont considérées comme des erreurs lorsqu'Error Reporting inspecte les entrées de journal pour détecter les schémas de texte courants tels que les traces de pile. Error Reporting regroupe les erreurs pouvant découler de la même cause.
Error Reporting est automatiquement activé.
Error Reporting relève jusqu'à 1 000 erreurs par heure.
Lorsque cette limite est atteinte, les comptes affichés sont estimés. Si trop d'événements sont reçus, Error Reporting relève jusqu'à 100 erreurs par heure et continue à extrapoler les comptes.
Quand Error Reporting analyse les entrées de journaux
Error Reporting est un service global basé sur Cloud Logging. Il peut analyser les entrées de journaux lorsque toutes les conditions suivantes sont remplies :
Les clés de chiffrement gérées par le client (CMEK) sont désactivées sur tous les buckets de journaux qui stockent l'entrée de journal. Error Reporting ne peut pas stocker les entrées de journaux dans des buckets de journaux pour lesquels CMEK est activé. Pour savoir comment déterminer la configuration CMEK d'un bucket de journaux, consultez Vérifier l'activation des clés.
Le bucket de journaux remplit l'une des conditions suivantes :
Le bucket de journaux est stocké dans le même projet que celui d'où proviennent les entrées de journal.
Les entrées de journal ont été acheminées vers un projet, puis ce projet les a stockées dans un bucket de journaux dont il est propriétaire.
Regroupement des erreurs
Lorsque Error Reporting évalue les entrées de journal, il ignore celles qui remplissent les conditions suivantes :
Dans l'environnement standard App Engine, les erreurs ayant un niveau de gravité inférieur à ERROR sont ignorées.
Les blocs de pile qui n'appartiennent pas à l'utilisateur sont ignorés (ceux qui appartiennent à des bibliothèques publiques, par exemple).
Les séquences répétées d'un ou plusieurs blocs de pile sont remplacées par une seule occurrence de ces séquences.
Les méthodes et les symboles ajoutés par un compilateur sont supprimés.
Ensuite, Error Reporting suit les règles suivantes pour regrouper les erreurs :
Les exceptions sont regroupées si elles partagent le même type d'exception et présentent des piles similaires.
La trace de la pile est ignorée pour les exceptions qui ne sont généralement pas liées à l'emplacement source où elles se produisent.
Les erreurs sans pile d'exception sont regroupées si elles ont été créées par la même entrée de journal, d'après l'emplacement source depuis lequel elles ont été signalées (reportLocation).
Plus précisément, les règles de regroupement suivantes sont appliquées dans l'ordre indiqué ci-dessous :
Type d'erreur
Critère de regroupement
Erreurs causées par un problème général dans l'environnement.
Par exemple, des problèmes spécifiques à App Engine :
Erreurs avec une trace de la pile. Dans le cas d'exceptions imbriquées, l'exception la plus profonde est prise en compte.
Exemple :
runtime error: index out of range
package1.func1()
file1:20
package2.func2()
file2:33
Regroupement par type d'exception et avec les cinq cadres les plus apparents.
Erreurs sans trace de la pile, mais avec un message.
Exemple :
runtime error: index out of range
func1()
Regroupement par message et par nom de fonction, le cas échéant. Seuls les trois premiers jetons littéraux du message sont pris en compte. Dans l'exemple de gauche, il s'agit de runtime, error et index.
Régionalité des données
Si vous configurez Assured Workloads pour les exigences de résidence des données ou IL4 (niveau d'impact 4), Google Cloud désactive automatiquement Error Reporting.
Dans Cloud Logging, vous pouvez régionaliser vos journaux en les acheminant vers un emplacement spécifique. Sur la page Groupes d'erreurs, Error Reporting organise et affiche les groupes d'erreurs en fonction de la région du bucket de journaux contenant les entrées de journal. Par exemple, un groupe d'erreurs listé sous us-central-1 ne contient que les journaux d'erreurs qui font partie d'un bucket de journaux dans us-central-1. Les groupes d'erreurs mondiaux ne contiennent que les journaux d'erreurs qui font partie d'un bucket de journaux dans la région global.
Pour filtrer la région des groupes d'erreurs affichés sur la page Groupes d'erreurs, sélectionnez une valeur dans le menu Région. La valeur par défaut de ce menu est global.
Sauf indication contraire, le contenu de cette page est régi par une licence Creative Commons Attribution 4.0, et les échantillons de code sont régis par une licence Apache 2.0. Pour en savoir plus, consultez les Règles du site Google Developers. Java est une marque déposée d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/09/03 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Difficile à comprendre","hardToUnderstand","thumb-down"],["Informations ou exemple de code incorrects","incorrectInformationOrSampleCode","thumb-down"],["Il n'y a pas l'information/les exemples dont j'ai besoin","missingTheInformationSamplesINeed","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 2025/09/03 (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)"]]
