Présentation d'Error Reporting

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 lorsque Error Reporting inspecte les entrées de journal à la recherche de modèles de texte courants tels que les traces de pile. Error Reporting regroupe les erreurs pouvant découler de la même cause.

Error Reporting s'active automatiquement.

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.

Lorsque Error Reporting analyse les entrées de journal

Error Reporting est un service global basé sur Cloud Logging. Il peut analyser les entrées de journaux lorsque toutes les conditions ci-dessous sont remplies:

  • Les charges de travail Assured Workloads sont désactivées. Pour en savoir plus, consultez la page Présentation d'Assured Workloads.
  • 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. Pour savoir comment déterminer la configuration CMEK d'un bucket de journaux, consultez la section 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 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 qui lui appartient.
Si vous stockez vos entrées de journal dans des buckets de journaux avec CMEK activé, vous pouvez toujours utiliser le Error Reporting. Toutefois, vous devez utiliser les bibliothèques clientes Error Reporting ou l'API Error Reporting. Pour en savoir plus, consultez la présentation de l'API Error Reporting et les bibliothèques clientes Error Reporting.

Regroupement des erreurs

Lorsque Error Reporting évalue les entrées de journal, il ignore les entrées de journal qui répondent aux 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 :

com.google.apphosting.runtime.HardDeadlineExceededError
 
com.google.appengine.api.datastore.DatastoreTimeoutException

Problèmes Java :

java.util.concurrent.CancellationException
 Regroupement par type d'exception.
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 de niveau d'impact 4 (IL4), Google Cloud désactive automatiquement le Error Reporting.

Dans Cloud Logging, vous pouvez regionaliser 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 globaux 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.

Menu "Région" sur la page "Groupes d'erreurs".

Étape suivante