Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
O Error Reporting agrega erros produzidos nos serviços em execução na nuvem. Esses erros são informados pela API Error Reporting ou são inferidos como erros quando o Error Reporting inspeciona entradas de registro em busca de padrões de texto comuns, como rastreamentos de pilha. O Error Reporting agrupa os erros que têm a mesma causa raiz.
O Error Reporting é ativado automaticamente.
O Error Reporting processa até 1.000 erros por hora.
Quando esse limite é atingido, as contagens exibidas são estimadas. Se houver muitos eventos, o Error Reporting vai processar até 100 erros por hora e continuar extrapolando as contagens.
Quando o Error Reporting analisa entradas de registro
O Error Reporting é um serviço global criado no
Cloud Logging e pode analisar entradas de registro quando todas as condições a seguir são verdadeiras:
As chaves de criptografia gerenciadas pelo cliente (CMEK)
estão desativadas em todos os buckets de registros que armazenam a entrada de registro. O Error Reporting não pode armazenar entradas de registro em buckets com a CMEK ativada. Para saber como determinar a configuração da CMEK de um bucket de registros, consulte Verificar a ativação da chave.
O bucket de registros atende a uma das seguintes condições:
O bucket de registros é armazenado no mesmo projeto em que as entradas de registro foram criadas.
As entradas de registro foram encaminhadas para um projeto, que as armazenou em um bucket de registros de propriedade dele.
Como os erros são agrupados
Quando o Error Reporting avalia entradas de registro, ele ignora aquelas com as seguintes condições:
No ambiente padrão do App Engine, os erros registrados com gravidade menor que ERROR são ignorados.
Os frames de pilha que não pertencem ao usuário são ignorados (aqueles que pertencem às bibliotecas públicas, por exemplo).
Todas as sequências repetidas de um ou mais frames de pilha são substituídas por uma ocorrência única daquela sequência.
Métodos introduzidos por compilador e símbolos são removidos.
Em seguida, o Error Reporting segue estas regras para agrupar erros:
As exceções são agrupadas se tiverem o mesmo tipo e pilhas semelhantes.
O rastreamento de pilha é ignorado para exceções que geralmente não estão relacionadas ao local de origem onde elas ocorrem.
Os erros sem uma pilha de exceção são agrupados se tiverem sido criados pela mesma entrada de registro, aproximada pelo local de origem onde foi relatado (reportLocation).
As seguintes regras de agrupamento são aplicadas, especificamente, nesta ordem:
Erros com um rastreamento de pilha. No caso de exceções aninhadas, é considerada aquela mais interna.
Por exemplo:
runtime error: index out of range
package1.func1()
file1:20
package2.func2()
file2:33
Agrupados por tipo de exceção e pelos cinco frames principais.
Erros sem um stack trace, mas com uma mensagem.
Exemplo:
runtime error: index out of range
func1()
Agrupados por mensagem e, se presente, pelo nome da função. Apenas os três primeiros tokens principais da mensagem são considerados. No exemplo à esquerda, eles são runtime, error e index.
Regionalidade dos dados
Se você configurar o Assured Workloads
para requisitos de residência de dados ou Nível de impacto 4 (IL4), o Google Cloud desativa automaticamente
o Error Reporting.
No Cloud Logging, é possível regionalizar seus registros roteando-os para um local específico. Na página Grupos de erros, o Error Reporting organiza e mostra grupos de erros com base na região do bucket de registros que contém as entradas de registro. Por exemplo, um grupo de erros listado em us-central-1 contém apenas registros de erros que fazem parte de um bucket de registros em us-central-1. Os grupos de erros globais contêm apenas registros de erros que fazem parte de um bucket de registros na região global.
Para filtrar a região dos grupos de erros mostrados na página Grupos de erros,
selecione um valor no menu Região. O valor padrão desse menu é
global.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Informações incorretas ou exemplo de código","incorrectInformationOrSampleCode","thumb-down"],["Não contém as informações/amostras de que eu preciso","missingTheInformationSamplesINeed","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 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)"]]
