Log Stream e App Service Logs: Diagnóstico em Tempo Real

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

TipoO que registra
Application LoggingSaída de log da própria aplicação (console.log, ILogger, etc.)
Web Server LoggingRequisições HTTP no formato W3C (IIS/nginx)
Detailed Error MessagesPáginas de erro completas do servidor pra códigos 400+
Failed Request TracingTrace 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

Atenção: a Application Logging no modo 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

SintomaCausaSolução
Log some depois de algumas horasFilesystem 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 nadaApplication Logging desabilitadoConfirmar que o Passo 1 foi aplicado com --application-logging filesystem
Erro de SAS inválida ao configurar Blob StorageSAS expirada ou sem permissão de escritaGerar nova SAS com rwdl e validade suficiente
Volume de log excessivo, custo de storage subindoNível verbose em produção sem necessidadeVoltar 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

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.

 

Deixe uma resposta

Descubra mais sobre Blog do Castilho - Tecnologia | FinOps | DevOps | Cloud

Assine agora mesmo para continuar lendo e ter acesso ao arquivo completo.

Continuar lendo