Recent searches
Search options
Administered by:
@dunossauro@bolha.usGalera, surgiu uma dúvida aqui e não consigo encontrar embasamento teórico para responder.
Em uma requisição HTTP, a minha aplicação atuando como server, tenho que retornar um erro de cliente (classe 4xx) se eu for logar esse evento, qual o log level que eu devo usar?
É uma operação esperada, logo INFO. Mas também é um erro do cliente WARNING.
Em alguns sistemas, seguíamos a regra de todo erro do cliente gerar um warning.
Mas e aí, pra você, logamos com INFO ou WARNING? Se possível, justifique xD
[Queria decidir um padrão pro curso de FastAPI, mas gostaria de ouvir opiniões antes de bater o martelo]
@dunossauro do ponto de vista do cliente pode ser um warning, pq digamos que mudou a validação da api, daí pode quebrar teu app.
Mas do lado do backend me parece algo corriqueiro. A não ser que esse erro tenha uma relevância pro negócio (digamos que seja um endpoint específico que precisa ser acionado com certa frequência, e em certo momento as requisições começam a falhar). Pode indicar um problema pra ser analisado na stack, tipo um deploy quebrado no front
@guites Obrigado por responder. Eu tive que alterar um pouco o texto depois da sua resposta, por que não ficava claro se era o server ou o cliente xD
@dunossauro pra mim
info é 1xx, 2xx e talvez 3xx
3xx pra mim já é mais pra warning
4xx e 5xx é error já definitivo
@dunossauro eu logaria como warning
@dunossauro uma vez eu li sobre os níveis de severidade nos bugs do Debian (https://www.debian.org/Bugs/Developer#severities), e baseado nisso penso algo como:
- CRITICAL: Quebrou a aplicação, e não tem como responder outras requisições (indisponibilidade geral). Por exemplo, levou a finalização do processo
- ERROR: Algum problema que impede o processamento correto de uma requisição, mas pode não impactar as demais ou futuras requisições
- WARNING: Algum problema, mas que não implica em não conseguir responder corretamente à requisição. Por exemplo, uso de algo depreciado, primeira falha em algo que possui retry
- INFO: Qualquer log para acompanhar a execução do software
- DEBUG: Aquele log que normalmente é desnecessário e está desabilitado, mas pode ser habilitado para entender e acompanhar melhor uma execução
Ponto ruim é que acaba centralizando bastante as coisas no INFO.
@dunossauro Mas nesse caso, talvez logaria como info, se puder marcar no trace como falha, ou warning mesmo para saber que tem requisições incorretas chegando, principalmente se for uma API interna (que teoricamente é possível ter mais controle de quem chama). Agora se for uma API pública, é um "erro" que não tem muito o que a aplicação possa fazer, então tendo mais para o info.
@dunossauro talvez não exista um padrão bem definido para isso e vai depender mais do seu contexto de uso do sistema. Pensei um pouco sobre o assunto. Eu acho que logar como ERROR no lado do cliente (já que foi algo errado da parte dele) e um WARNING no lado do servidor. Se for INFO, esta informação pode ficar perdida e nunca teremos como ser notificados se houver uma quantidade muito grande desses WARNINGS. Assim posso acompanhar se houver um aumento relevante desses erros no lado do cliente e poder analisar o problema.
Um exemplo, eu posso começar a receber uma quantidade muito grande de 400 (Bad Request). Isso pode ser realmente um problema do cliente enviando informações erradas, mas também pode ser um problema no servidor que está considerando errado uma entrada que deveria ser correta (o cliente está certo!).
@dunossauro @dunossauro A resposta simples seria "não tem standard, vai de acordo com a documentação do projeto".
Mas acredito que posso resumir em:
- Erros 4xx "esperados" que fazem parte do fluxo de acesso e utilização seriam INFO, como 401 (Unauthorized), 403 (Forbidden) e 422 (Unprocessable Entity);
- Erros 4xx mais ambíguos, inesperados ou que façam sentido serem analisados com frequência seriam WARNING, como 400 (Bad Request), 405 (Method not allowed, afinal por que o cliente fez uma request com outro método???) e 429 (Too Many Requests).
Então, minha conclusão:
INFO:
- 401 Unauthorized
- 403 Forbidden
- 404 Not found - Não recorrente para o mesmo recurso / URI
- 422 Unprocessable Entity
WARNING:
- 400 Bad request
- 404 Not found - Recorrente para o mesmo recurso / URI
- 405 Method not allowed
- 408 Request Timeout
- 413 Content Too Large
- 414 URI too long
- 415 Unsupported Media Type
Obs: Eu geralmente utilizo 422 para validações de cliente como campos obrigatórios, formatação, etc. Erro 400, geralmente seria para outro motivo de sintaxe ou ausência de algum header específico, por aí vai... Por isso categorizei eles dessa forma.