Organiza tus páginas con colecciones
Guarda y categoriza el contenido según tus preferencias.
Error Reporting agrega los errores que se producen en tus servicios de la nube en ejecución. Estos errores los informa la API de Error Reporting o se infieren como errores cuando Error Reporting inspecciona las entradas de registro en busca de patrones de texto comunes, como los seguimientos de pila. Error Reporting agrupa los errores que se considera tienen la misma causa raíz.
Error Reporting se habilita automáticamente.
Error Reporting hace un muestreo de hasta 1,000 errores por hora.
Cuando se llega a este límite, se estiman los recuentos mostrados. Si se reciben demasiados eventos, Error Reporting hace un muestreo de hasta 100 errores por hora y continúa con la extrapolación de los recuentos.
Cuándo Error Reporting analiza las entradas de registro
Error Reporting es un servicio global compilado en Cloud Logging y puede analizar entradas de registro cuando se cumplen todas las siguientes condiciones:
Las claves de encriptación administradas por el cliente (CMEK)
están inhabilitadas en todos los buckets de registros que almacenan la entrada de registro. Error Reporting no puede almacenar entradas de registro en buckets de registros que tienen habilitada la CMEK. Para obtener información sobre cómo determinar la configuración de CMEK de un bucket de registros, consulta Verifica la habilitación de la clave.
El bucket de registros satisface una de las siguientes condiciones:
El bucket de registros se almacena en el mismo proyecto en el que se originaron las entradas de registro.
Las entradas de registro se enrutaron a un proyecto y, luego, ese proyecto almacenó esas entradas de registro
en un bucket de registros que le pertenece.
Cómo se agrupan los errores
Cuando Error Reporting evalúa las entradas de registro, ignora las que cumplen con las siguientes condiciones:
En un entorno estándar de App Engine, se ignoran los errores que se registran con una severidad menor que ERROR.
Se ignoran los marcos de pila que no son propiedad del usuario (p. ej., aquellos que pertenecen a bibliotecas públicas).
Cualquier secuencia repetida de uno o más marcos de pila se reemplaza por un único caso de esa secuencia.
Se quitan los métodos y símbolos ingresados por el compilador.
A continuación, Error Reporting sigue estas reglas para agrupar los errores:
Las excepciones se agrupan si tienen el mismo tipo de excepción y pilas similares.
El seguimiento de pila se ignora para excepciones que comúnmente no se relacionan con la ubicación de origen en que sucedieron.
Los errores sin ninguna pila de excepciones se agrupan si fueron creados por la misma entrada de registro, calculado por la ubicación de origen de la cual se informó (reportLocation).
En específico, las siguientes reglas de agrupación se aplican en este orden:
Tipo de error
Agrupado por
Errores provocados por un problema general en el entorno.
Errores con seguimiento de pila. En el caso de excepciones anidadas, se considera la excepción más interna.
Por ejemplo:
runtime error: index out of range
package1.func1()
file1:20
package2.func2()
file2:33
Agrupado por tipo de excepción y los 5 marcos principales.
Errores sin seguimiento de pila, pero con un mensaje.
Por ejemplo:
runtime error: index out of range
func1()
Agrupado por mensaje y (si existe) nombre de función. Solo se consideran los primeros 3 tokens del mensaje. En el ejemplo de la izquierda, estos tokens son runtime, error y index.
Regionalidad de los datos
Si configuras Assured Workloads para los requisitos de residencia de datos o Impact Level 4 (IL4), entonces Google Cloud se inhabilita automáticamente
Error Reporting.
En Cloud Logging, puedes regionalizar tus registros enrutándolos a una ubicación específica. En la página Grupos de errores, Error Reporting organiza y muestra los grupos de errores según la región del bucket de registros que contiene las entradas de registro. Por ejemplo, un grupo de errores que aparece en us-central-1 solo contiene registros de errores que forman parte de un bucket de registros en us-central-1. Los grupos de errores globales solo contienen registros de errores que forman parte de un bucket de registros en la región global.
Para filtrar la región de los grupos de errores que se muestran en la página Error Groups, selecciona un valor en el menú Region. El valor predeterminado de este menú es global.
[[["Fácil de comprender","easyToUnderstand","thumb-up"],["Resolvió mi problema","solvedMyProblem","thumb-up"],["Otro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Información o código de muestra incorrectos","incorrectInformationOrSampleCode","thumb-down"],["Faltan la información o los ejemplos que necesito","missingTheInformationSamplesINeed","thumb-down"],["Problema de traducción","translationIssue","thumb-down"],["Otro","otherDown","thumb-down"]],["Última actualización: 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)"]]
