O Error Reporting agrega erros produzidos nos seus serviços em execução na nuvem. Esses erros são informados pelo API Error Reporting ou inferidos quando o Error Reporting inspecionar as entradas de registro padrões de texto, como stack traces, 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 muitos eventos forem recebidos, o Error Reporting vai gerar amostras de até 100 erros por hora e continuar a extrapolar as contagens.
Quando o Error Reporting analisa entradas de registro
O Error Reporting é um serviço global baseado em o Cloud Logging e pode analisar entradas de registro quando todas as condições a seguir forem verdadeiras:
- As cargas de trabalho garantidas estão desativadas. Para mais informações, consulte Visão geral do Assured Workloads.
- Chaves de criptografia gerenciadas pelo cliente (CMEK) está desativado em todos os buckets que armazenam a entrada de registro. Para saber como determinar a configuração da CMEK para um bucket de registro, consulte Verificar a ativação da chave.
- O bucket de registro atende a uma das seguintes condições:
- O bucket de registros é armazenado no mesmo projeto em que as entradas de registro foram originadas.
- As entradas de registro foram encaminhadas para um projeto, que armazenou essas entradas de registro em um bucket de registros próprio.
Como os erros são agrupados
Quando o Error Reporting avalia entradas de registro, ele ignora 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 por
a mesma entrada de registro, aproximada pelo local de origem informado
de (
reportLocation
).
As seguintes regras de agrupamento são aplicadas, especificamente, nesta ordem:
Tipo de erro | Agrupados por |
---|---|
Erros causados por um problema geral no ambiente.
Por exemplo, problemas específicos do App Engine: com.google.apphosting.runtime.HardDeadlineExceededError com.google.appengine.api.datastore.DatastoreTimeoutException Problemas do Java: java.util.concurrent.CancellationException |
Agrupados por tipo de exceção. |
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 Impact Level 4 (IL4), o Google Cloud desativa automaticamente a geração de relatórios de erros.
No Cloud Logging, é possível regionalizar os registros com o roteamento a 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. Como o Error Reporting é um serviço global, os grupos de erros podem ser acessados de qualquer região. Esse comportamento não é configurável.