Relatório de Erros permite que você veja erros e avisos do sistema Luau em tempo real, tanto para servidor quanto para cliente. Monitore seu relatório de erros antes e depois de atualizar sua experiência para identificar possíveis problemas antecipadamente.
Veja seu relatório de erros
Para visualizar o relatório de erros da sua experiência:
- Navegue até sua página de Criações no Painel do Criador e selecione sua experiência.
- Em Monitoramento, selecione Relatório de Erros.
Você pode visualizar análises para experiências individuais ou de grupo. Para visualizar as de grupo, você precisa ter permissões de grupo para análises.
Monitore erros e avisos
Você pode aplicar os seguintes filtros e alternadores ao seu relatório de erros:
- Intervalo de datas — Filtre para as últimas 1 hora, último 1 dia, últimos 7 dias ou últimos 30 dias.
- Local — Filtre por local.
- Mostrar versão — Adiciona anotações de versão do local ao gráfico de erros e avisos.
- Gravidade — Filtre para mostrar erros, avisos ou ambos.
- Plataforma — Filtre para mostrar erros de cliente de dispositivos específicos.
- SO — Filtre para mostrar erros de cliente de sistemas operacionais específicos.
- Novos erros desde — Filtre para mostrar apenas novos erros e avisos desde uma determinada versão.
Abaixo dos filtros e alternadores, um gráfico exibe o número de erros e avisos para servidor, cliente e total. Use esse gráfico para verificar aumentos em erros e avisos ao longo do tempo. Se você notar um grande aumento em erros e avisos, use a tabela de relatórios de erros para solucionar problemas.
Solucione erros e avisos
A tabela de Erros e avisos tem as seguintes colunas:
| Coluna | Descrição |
|---|---|
| Contagem | Número de erros ou avisos. |
| Gravidade | Rótulo de erro ou aviso. |
| Tipo | Rótulo de servidor ou cliente. |
| Mensagem | Mensagem de erro ou aviso. |
| Primeiro visto em | Timestamp do primeiro registro da mensagem. |
| Versão do primeiro visto | Disponível apenas quando um local é escolhido. Mostra a primeira versão onde a mensagem foi registrada. |
Veja o rastreamento de pilha para um erro ou aviso
Se você ver um menu suspenso em um erro ou aviso, clique para expandi-lo e ver seu correspondente rastreio de pilha. Um rastreio de pilha é uma lista das chamadas que sua experiência estava realizando quando a exceção foi lançada. Isso pode ajudá-lo a descobrir o que está dando errado.
Regras personalizadas
Regras personalizadas permitem que você defina padrões de regex ou de string exata para ignorar ou agrupar automaticamente erros e avisos. Isso ajuda a gerenciar a relação sinal-ruído dos seus relatórios de erros. Você pode criar até 100 regras por experiência. As regras são avaliadas de cima para baixo na ordem de prioridade. Assim que um erro corresponde a uma regra, o processamento adicional é interrompido.
Ações das regras
Cada regra tem uma das duas ações:
| Ação | Comportamento |
|---|---|
| Ignorar | Oculta erros correspondentes do gráfico e da tabela. Use para ruídos permanentes como erros de som de motor inevitáveis ou declarações de impressão legadas. |
| Agrupar | Consolida todos os erros correspondentes sob um nome de grupo personalizado (por exemplo, "Problemas de Rede", "Spam de Áudio"). O nome do grupo aparece como uma única linha na tabela. |
Criar uma regra
Existem duas maneiras de criar uma regra:
Do lado da tabela de erros (inline):
- Clique no menu de contexto (três pontos) em qualquer linha de erro.
- Selecione Ignorar.
Da aba de regras:
- Navegue até a aba Regras na página de Relatórios de Erros.
- Clique em Criar Regra.
- Insira um padrão (string exata ou regex).
- Selecione uma ação: Ignorar ou Agrupar → [Nome do Grupo].
- Salve a regra.
Campos de criação de regras
| Campo | Descrição |
|---|---|
| Padrão | A string exata ou expressão regular para corresponder às mensagens de erro. |
| Ação | Escolha Ignorar (ocultar o erro) ou Agrupar → insira um nome de grupo personalizado. |
As regras são avaliadas de cima para baixo com base na ordem de prioridade na aba Regras. Assim que um erro corresponde a uma regra, a ação dessa regra é executada e nenhuma regra adicional é avaliada para esse erro. Isso evita conflitos, como um erro sendo agrupado por uma regra e depois ignorado por uma regra subsequente.
As regras impactam apenas erros registrados após serem salvas. Uma anotação aparece no seu gráfico quando as regras são modificadas.
Noções básicas sobre expressões regulares
Uma expressão regular (regex) é um padrão que corresponde a texto:
| Sintaxe | Significado | Exemplo |
|---|---|---|
| . | Qualquer caractere único | H.t corresponde a "Hat", "Hit", "Hot" |
| * | Zero ou mais do caractere anterior | go*d corresponde a "gd", "god", "good" |
| + | Um ou mais do caractere anterior | go+d corresponde a "god", "good", mas não "gd" |
| .* | Qualquer sequência de caracteres (wildcard) | Failed.*load corresponde a "Failed to load" e "Failed xyz load" |
| \d | Qualquer dígito (0-9) | v\d+ corresponde a "v1", "v123", "v4488" |
| \w | Qualquer caractere de palavra (letras, dígitos, underline) | \w+ corresponde a "Player123", "my_var" |
| ^ | Início da string | ^HTTP corresponde a erros que começam com "HTTP" |
| \/ | Uma barra invertida escapada | rbxassetid:\/\/ corresponde a "rbxassetid://" |
| \[ e \] | Colchetes quadrados escapados (correspondência literal) | \[Knit\] corresponde a "[Knit]" |
| (a|b) | Corresponder a "a" ou "b" | (Error|Warning):.* corresponde a "Error: ..." e "Warning: ..." |
Dicas rápidas:
- Comece com uma correspondência exata (a string de erro completa) se você quiser capturar apenas um erro específico.
- Use uma regex quando quiser capturar uma família de erros semelhantes (por exemplo, todas as falhas de carregamento de som, independentemente do ID de ativo).
- Teste seu padrão contra algumas strings de erro reais antes de salvar para ter certeza de que captura o que você espera.
O sistema impõe duas regras aos seus padrões de regex:
- Você não pode colocar um repetidor (+ ou *) dentro de um grupo repetido. Por exemplo, (a+)* ou (\w+)+ são rejeitados.
- Deve começar com texto ancorado: Padrões não podem começar com um wildcard como .* ou .+. Seu padrão deve começar com um caractere concreto ou âncora (como ^ ou uma string literal).
Exemplos de regras para organizar seus relatórios de erros
Em vez de ver dezenas de linhas de erro separadas, consolide erros relacionados sob um nome de grupo:
| Caso de uso | Erros de exemplo | Padrão | Ação |
|---|---|---|---|
| Todos os erros de rede | HttpError: ConnectFail, HttpError: Timedout | HttpError:.* | Agrupar → "Problemas de Rede" |
| Avisos de DataStore | DataStore request was added to queue, DataStoreService: ... | DataStore | Agrupar → "Avisos de DataStore" |
| Erros de GUI de jogador | Players.Player1.PlayerGui.Shop:12: attempt to index nil | Players\.\w+\.PlayerGui | Agrupar → "Erros de PlayerGui" |
| Framework de UI personalizado | [UIManager] Button render failed, [UIManager] Layout overflow | \[UIManager\].* | Agrupar → "Sistema de UI" |
Limites de rastreamento de erros
O sistema rastreia até 500 erros únicos e 500 avisos únicos por contagem e os 100 novos erros principais por versão. Essas contagens são redefinidas a cada 6 horas. Para maximizar o rastreamento útil de erros dentro desses limites:
- Remova identificadores únicos das mensagens de erro, como IDs de usuários, coordenadas ou timestamps. Erros como Player 12345 failed to load e Player 67890 failed to load contam como duas entradas separadas. Se você registrá-los como Player failed to load, eles serão consolidados em uma entrada com uma contagem mais alta.
- Use regras personalizadas para agrupar erros relacionados que diferem apenas por valores dinâmicos.
Resolva erros e avisos
Ao investigar erros na página de Relatórios de Erros, use as seguintes abordagens:
- Revise rastreamentos de pilha — Expanda as linhas de erro para ver o caminho de chamada e identificar o script exato e o número da linha onde o erro ocorreu.
- Verifique atualizações recentes — Monitore novos erros desde sua atualização mais recente.
- Use ferramentas integradas:
- Console do Desenvolvedor (F9 na experiência): Veja erros ao vivo em tempo real e teste correções.
- Profiler de Script: Identifique erros relacionados a desempenho causados por operações dispendiosas.
- Janela de Saída no Studio — Capture erros durante o desenvolvimento antes de publicar.
- Use quebras de saída — Verifique se o erro é específico para uma plataforma (Desktop, Móvel, Console) ou SO (Windows, macOS, iOS, Android).
- Reúna feedback da comunidade — Se você tiver um Discord da comunidade ou um post no DevForum, verifique se os jogadores estão relatando o problema e quais dispositivos ou regiões estão afetados.