Skip to main content
Back to path

Welcome to a Grasp lesson

Create a free account to keep studying and create your own study path.

Lesson 8

Debugging with Docker Logs

Recommended resources

Olá! Bem-vindo de volta.

Na lição anterior, você aprendeu a usar o docker stats para monitorar o desempenho dos seus contêineres em tempo real. Vimos que stats é excelente para responder "o que" está acontecendo em termos de consumo de recursos (CPU, memória). No entanto, quando um problema ocorre, stats raramente nos diz "por quê". Para entender a causa raiz, precisamos examinar a saída da própria aplicação.

Nesta lição, vamos exatamente fazer isso. Nosso objetivo é que você aprenda a acessar e seguir os logs de saída dos contêineres usando o comando docker logs. Para você, como desenvolvedor, dominar o docker logs é uma habilidade de depuração de primeira linha. É o equivalente a abrir um console de saída para uma aplicação que agora vive dentro de uma "caixa preta" chamada contêiner.

Como o Logging do Docker Funciona?

Para entender o docker logs, é crucial primeiro entender como o Docker foi projetado para capturar logs. O princípio é simples e elegante:

Por padrão, o Docker captura e redireciona os fluxos de saída padrão (stdout) e erro padrão (stderr) do processo principal que está rodando dentro do contêiner.

Docker Container Logging Mechanism
Esta imagem ilustra o mecanismo fundamental de logging do Docker: o processo da sua aplicação dentro do contêiner escreve para `stdout` e `stderr`, e o Docker captura esses fluxos para o seu sistema de logs.

Esses fluxos capturados são então passados para um logging driver. O driver padrão é o json-file, que armazena a saída em um arquivo JSON no host. O comando docker logs simplesmente lê desse arquivo para exibir os logs para você.

Mastering Docker Logs: A Comprehensive Tutorial

Para solidificar esse conceito, leia a seção 'Understanding how Docker logging works' no guia da Dash0. Ele explica de forma concisa como o Docker captura logs e onde eles são armazenados por padrão.

Leia a seção 'Understanding how Docker logging works' e a subseção 'Where Docker stores container logs'. Preste atenção na explicação sobre stdout/stderr e no caminho padrão do arquivo de log.

Isso significa que, para suas próprias aplicações .NET serem "bons cidadãos" em um ambiente containerizado, elas devem ser configuradas para registrar suas mensagens no console (Console.WriteLine ou usando uma biblioteca de logging como Serilog configurada para o console sink), em vez de em arquivos dentro do sistema de arquivos do contêiner.

O Comando docker logs em Ação

Vamos ver o comando em ação. Primeiro, certifique-se de que seu contêiner meu-servidor-web da lição anterior está rodando. Se não estiver, inicie-o:

docker start meu-servidor-web

Agora, vamos gerar alguns logs. Abra um navegador web e acesse http://localhost. Atualize a página algumas vezes. Cada acesso gera uma entrada de log no Nginx.

Para ver esses logs, use o comando docker logs seguido do nome ou ID do contêiner:

docker logs meu-servidor-web

Você verá as entradas de log de acesso correspondentes às suas visitas no navegador.

Para uma demonstração visual completa deste fluxo de trabalho, assista ao vídeo a seguir.

Docker Logging - "docker logs" Command | Log Drivers | Logging Strategies

Este vídeo do canal Better Stack demonstra claramente como iniciar um contêiner Nginx e usar o docker logs para inspecionar sua saída.

Assista do timestamp 0:47 até 6:36. O vídeo mostrará como executar o contêiner e, em seguida, como o docker logs exibe os logs de acesso gerados.

Aprofundando: Como o Nginx Expõe seus Logs?

Sua preferência por entender "como as coisas funcionam" nos leva a uma pergunta interessante. Sabemos que muitas aplicações, como o Nginx, são configuradas por padrão para escrever logs em arquivos (ex: /var/log/nginx/access.log). Se o Docker só captura stdout e stderr, como ele obtém os logs do Nginx?

A imagem oficial do Nginx usa um truque inteligente do Linux: links simbólicos.

Dentro do Dockerfile da imagem do Nginx, há um comando que cria links simbólicos dos arquivos de log padrão para os dispositivos de stdout e stderr. Essencialmente, ele diz ao sistema: "qualquer coisa escrita em /var/log/nginx/access.log deve, na verdade, ir para stdout".

O vídeo que você começou a assistir explica isso perfeitamente.

Docker Logging - "docker logs" Command | Log Drivers | Logging Strategies

Continue assistindo ao vídeo para ver uma explicação detalhada sobre os links simbólicos usados na imagem do Nginx.

Assista do timestamp 6:36 até 9:15. O apresentador usa o docker exec para entrar no contêiner e mostrar os links simbólicos, conectando a teoria à prática. Sinta-se à vontade para pausar e tentar o comando docker exec -it meu-servidor-web bash você mesmo para explorar!

Essa é uma técnica comum para adaptar aplicações legadas ou baseadas em arquivos ao ecossistema de contêineres.

Filtrando e Acompanhando Logs em Tempo Real

Na maioria das vezes, você não quer ver o histórico de logs inteiro. Você quer ver o que está acontecendo agora ou encontrar eventos de um período específico. O docker logs oferece várias flags poderosas para isso.

Acompanhando Logs ao Vivo (--follow ou -f)

Esta é talvez a opção mais usada para depuração. A flag -f "segue" a saída do log, exibindo novas linhas à medida que são escritas.

docker logs -f meu-servidor-web

Agora, atualize a página http://localhost no seu navegador novamente. Você verá as novas entradas de log aparecerem instantaneamente no seu terminal. Para parar de seguir, pressione Ctrl+C.

Docker Logs Command Output with Follow Flag
Este é um exemplo da saída do `docker logs --follow`, mostrando os logs de inicialização de um servidor Nginx e aguardando por novas entradas.

Limitando a Saída (--tail) e Filtrando por Tempo (--since, --until)

Para refinar ainda mais sua busca, você pode usar estas flags:

  • --tail N: Mostra as últimas N linhas de log. É muito eficaz combinar com -f para obter um pouco de contexto histórico antes de começar a seguir os logs ao vivo: docker logs -f --tail 100 meu-servidor-web.
  • --since '10m': Mostra logs gerados nos últimos 10 minutos.
  • --until '2m': Mostra logs gerados até 2 minutos atrás.

Você pode combinar --since e --until para isolar uma janela de tempo específica, o que é inestimável para investigar incidentes.

Mastering Docker Logs: A Comprehensive Tutorial

Este artigo serve como uma excelente referência rápida para todas essas flags. Leia as seções sobre filtragem e acompanhamento para revisar e consolidar seu entendimento.

Leia as seções 'Viewing container logs...', 'Filtering logs by time...', e 'Following and tailing Docker container logs'. Elas fornecem exemplos claros para cada flag.

Buscando nos Logs com grep

O docker logs não tem uma função de busca nativa, mas você pode facilmente usar ferramentas de linha de comando padrão como o grep para filtrar a saída.

# Encontra todas as requisições GET
docker logs meu-servidor-web | grep "GET"
Teste seu entendimento!

Imagine que seu servidor web apresentou um erro cerca de 10 minutos atrás. Você sabe que as mensagens de erro no Nginx contêm a palavra "error". Escreva um único comando para buscar por logs que contenham a palavra "error" (ignorando maiúsculas/minúsculas) nos últimos 15 minutos do contêiner meu-servidor-web.

Show answer 
docker logs --since 15m meu-servidor-web | grep -i "error"

Análise:

  1. docker logs --since 15m meu-servidor-web: Recupera todas as linhas de log dos últimos 15 minutos.
  2. |: O "pipe" redireciona a saída do primeiro comando para a entrada do próximo.
  3. grep -i "error": Filtra a entrada recebida, mostrando apenas as linhas que contêm a string "error". A flag -i torna a busca insensível a maiúsculas e minúsculas.

Uma Nota para Desenvolvedores .NET

Como desenvolvedor .NET, você pode encontrar uma situação confusa: você adiciona Console.WriteLine("Hello from my app!"); em sua aplicação, a executa em um contêiner usando o Visual Studio, mas docker logs não mostra nada. Por quê?

Isso acontece por causa da forma como o Visual Studio integra o debugging com Docker.

  • Ao depurar com F5 no Visual Studio: VS frequentemente altera o ENTRYPOINT do contêiner para um comando que o mantém vivo (como tail -f /dev/null) e então usa docker exec para iniciar seu aplicativo com o depurador anexado. A saída do seu aplicativo (stdout/stderr) é roteada de volta para a janela "Saída do Contêiner" do Visual Studio, não para o stdout do contêiner.
  • Ao rodar um contêiner de "release": Quando você constrói uma imagem para Release e a executa com docker run, seu aplicativo (dotnet MyApp.dll) é o ENTRYPOINT. Nesse caso, Console.WriteLine vai para o stdout do contêiner e é capturado pelo docker logs como esperado.

Output from .NET Core console app by docker logs

Esta é uma dúvida muito comum, e uma thread no Stack Overflow a explica em detalhes técnicos, o que certamente irá satisfazer sua curiosidade sobre o funcionamento interno.

Leia as duas primeiras respostas na página. A primeira é uma observação concisa sobre o modo de depuração. A segunda resposta, mais longa, faz uma excelente análise usando docker inspect e pstree para mostrar exatamente o que está acontecendo dentro do contêiner durante uma sessão de depuração do VS. Isso é um ótimo exemplo de como usar as ferramentas que você está aprendendo para investigar o comportamento do sistema.

Entender essa distinção é fundamental para não se frustrar ao tentar depurar seus contêineres .NET.

Conclusão

Nesta lição, você mergulhou em uma das ferramentas de depuração mais essenciais do Docker. Agora você não apenas sabe como recuperar logs, mas também entende o mecanismo subjacente que permite que isso funcione.

Principais pontos a reter:

  • docker logs exibe a saída dos fluxos stdout e stderr do processo principal de um contêiner.
  • Aplicações devem ser configuradas para logar no console para serem compatíveis com o mecanismo de logging do Docker.
  • A flag -f (--follow) é sua ferramenta principal para depuração ao vivo.
  • As flags --tail, --since e --until, combinadas com ferramentas como grep, permitem filtrar e encontrar informações específicas rapidamente.
  • O ambiente de depuração do Visual Studio tem um comportamento especial que redireciona a saída do log, um detalhe crucial para desenvolvedores .NET.

Até agora, focamos em gerenciar e observar contêineres individuais. No entanto, a maioria das aplicações, incluindo suas APIs .NET, não vive isolada. Elas precisam se comunicar com bancos de dados, caches e outros serviços.

Na próxima lição, iniciaremos um novo módulo sobre Networking e Armazenamento Persistente. Começaremos explorando como os contêineres se comunicam entre si e com o mundo exterior, aprendendo sobre os drivers de rede do Docker e como expor portas usando a flag -p.