Quando alguma coisa dá errado num App Service e não tem Application Insights configurado, o primeiro instinto de muita gente é abrir o portal e clicar por vinte telas. Só que a forma mais rápida de ver o que está acontecendo agora é bem mais direta: Log Stream via Azure CLI, direto no terminal.
Neste guia rápido você vai ativar os logs de aplicação e do servidor web, acompanhar em tempo real com az webapp log tail e entender uma pegadinha que derruba o logging sozinho depois de 12 horas se você não migrar pra blob storage.
Sumário
- Os quatro tipos de log do App Service
- Passo 1 — Ativando o logging
- Passo 2 — Acompanhando em tempo real
- A pegadinha das 12 horas
- Logging persistente em Blob Storage
- Baixando o histórico completo
- Troubleshooting comum
- Conclusão
- Referências oficiais
Os quatro tipos de log do App Service
| Tipo | O que registra |
|---|---|
| Application Logging | Saída de log da própria aplicação (console.log, ILogger, etc.) |
| Web Server Logging | Requisições HTTP no formato W3C (IIS/nginx) |
| Detailed Error Messages | Páginas de erro completas do servidor pra códigos 400+ |
| Failed Request Tracing | Trace detalhado do pipeline de processamento de requisições que falharam |
Passo 1 — Ativando o logging
az webapp log config \
--name meuapp-prod \
--resource-group rg-appservice-lab \
--application-logging filesystem \
--level information \
--web-server-logging filesystem \
--detailed-error-messages true \
--failed-request-tracing true
O nível (--level) aceita error, warning, information ou verbose — em produção, information costuma ser o equilíbrio certo entre visibilidade e volume de log.
Passo 2 — Log Stream em tempo real pelo terminal
az webapp log tail \
--name meuapp-prod \
--resource-group rg-appservice-lab
Isso conecta direto no stream de log do Kudu e mostra cada linha assim que é escrita — o mesmo conteúdo que aparece em Log Stream no portal, só que sem sair do terminal. Pra filtrar em tempo real (por exemplo, só erros), o jeito mais simples é encadear com grep:
az webapp log tail --name meuapp-prod --resource-group rg-appservice-lab \
| grep -i "error\|exception"
A pegadinha das 12 horas
filesystem se desliga automaticamente depois de 12 horas. É uma proteção da própria plataforma pra evitar que o disco local da instância encha com log — mas pega muita gente de surpresa quando o log “some” no meio de uma investigação mais longa.
Pra debug pontual, reativar é rápido (mesmo comando do Passo 1). Mas se você precisa de log de aplicação persistente, o filesystem não é a resposta — o passo seguinte é redirecionar pro Blob Storage.
Logging persistente em Blob Storage
O Application Logging em modo azureblobstorage não tem o limite de 12 horas, mas pede uma URL SAS de um container já existente, configurada via app settings:
# Gera uma SAS de 30 dias pro container de logs
sasUrl=$(az storage container generate-sas \
--name applogs \
--account-name stmeuapplogs \
--permissions rwdl \
--expiry $(date -u -d "+30 days" '+%Y-%m-%dT%H:%MZ') \
--https-only \
-o tsv)
az webapp log config \
--name meuapp-prod \
--resource-group rg-appservice-lab \
--application-logging azureblobstorage \
--level information
az webapp config appsettings set \
--name meuapp-prod \
--resource-group rg-appservice-lab \
--settings DIAGNOSTICS_AZUREBLOBCONTAINERSASURL="https://stmeuapplogs.blob.core.windows.net/applogs?$sasUrl" \
DIAGNOSTICS_AZUREBLOBRETENTIONINDAYS=30
DIAGNOSTICS_AZUREBLOBRETENTIONINDAYS controla por quanto tempo o log fica retido antes de ser limpo automaticamente — evita que o container cresça pra sempre sem controle.
Baixando o histórico completo
Pra levar o log pra fora do Azure (analisar localmente, anexar num ticket de suporte), dá pra baixar tudo compactado num único comando:
Diferente do Log Stream em tempo real, esse download inclui todo o histórico ainda retido no disco da instância — útil quando o incidente já passou e você precisa reconstruir a linha do tempo depois.
az webapp log download \
--name meuapp-prod \
--resource-group rg-appservice-lab \
--log-file webapp_logs.zip
Troubleshooting comum
| Sintoma | Causa | Solução |
|---|---|---|
| Log some depois de algumas horas | Filesystem logging desligou sozinho (limite de 12h) | Reativar pra debug pontual, ou migrar pra Blob Storage se precisa de persistência |
az webapp log tail não mostra nada | Application Logging desabilitado | Confirmar que o Passo 1 foi aplicado com --application-logging filesystem |
| Erro de SAS inválida ao configurar Blob Storage | SAS expirada ou sem permissão de escrita | Gerar nova SAS com rwdl e validade suficiente |
| Volume de log excessivo, custo de storage subindo | Nível verbose em produção sem necessidade | Voltar pra information ou warning fora de janelas de debug |
Conclusão
Pra debug rápido, o az webapp log tail já resolve boa parte dos casos — nada de abrir portal, é um comando e o problema aparece na tela em tempo real. Mas pra qualquer coisa que precise sobreviver mais de 12 horas, vale configurar Blob Storage desde já: é bem mais barato descobrir isso antes do incidente do que durante ele.
Referências oficiais
- Habilitar diagnóstico de logs no App Service (Microsoft Learn)
- az webapp log — referência da CLI (Microsoft Learn)
Interessado em saber mais sobre artigos relacionados ao Microsoft Azure CLIQUE AQUI
🚀 Vamos nos conectar?
Não perca nenhuma oportunidade! Cadastre-se nas minhas redes e no canal do YouTube para receber conteúdos de TI, Cloud, Azure, Kubernetes e DevOps em primeira mão.
Dica: No Facebook, todos os artigos do blog são publicados automaticamente. Vale a pena curtir!
💬 Dúvidas ou Problemas?
Com o intuito de ajudar a comunidade, caso você tenha dúvidas ou encontre problemas na execução dos comandos deste artigo, deixe um comentário abaixo. Responderei o mais breve possível!
Muito obrigado pela visita e até o próximo post!
Jefferson Castilho Especialista em Cloud & DevOps.Este guia técnico é exclusivo do Blog do Castilho. Explore mais conteúdos sobre Cloud e DevOps.