DIA 03: O Investigador de Logs

Introdução

É o terceiro dia na LabEx Corporation, e o desastre atingiu o Projeto Phoenix! Você chega ao escritório e encontra Sarah Chen e a equipe de desenvolvimento em modo de crise. A aplicação que você ajudou a organizar ontem encontrou erros críticos durante sua primeira grande fase de testes.

Alertas de emergência estão inundando os sistemas de monitoramento, usuários estão relatando falhas na aplicação e o pipeline de implantação foi interrompido. Sarah se volta para você com um olhar de desespero — o engenheiro DevOps sênior está de licença médica e o prazo do projeto está se esgotando rapidamente.

"Precisamos do nosso melhor investigador nisso", diz Sarah, entregando-lhe o relatório do incidente. "Sua abordagem sistemática para organizar nossos arquivos foi exatamente o que precisávamos. Agora precisamos desse mesmo raciocínio metódico para resolver este mistério."

Sua missão é mergulhar profundamente no servidor do Projeto Phoenix, analisar logs e arquivos de configuração e descobrir a causa raiz dessas falhas. Você usará ferramentas avançadas de linha de comando do Linux para juntar as pistas e restaurar a estabilidade da aplicação que sua equipe trabalhou tanto para construir. O futuro do Projeto Phoenix — e possivelmente sua carreira na TechNova — depende de suas habilidades de detetive!

Revisando o Conteúdo do Arquivo de Log da Aplicação

Seu primeiro passo como investigador é verificar o arquivo de log da aplicação do Projeto Phoenix. A aplicação grava seus logs em ~/project/logs/app.log. Uma enxurrada de mensagens pode ser esmagadora, então você precisa encontrar as mensagens de erro críticas rapidamente para entender o que está acontecendo de errado com o sistema que você ajudou a organizar ontem.

Tarefas

• Filtrar o arquivo ~/project/logs/app.log para encontrar todas as linhas que contenham a palavra ERROR.
• Salvar as linhas filtradas em um novo arquivo chamado ~/project/error_report.txt.

Requisitos

• Você deve usar uma ferramenta de linha de comando para pesquisar no arquivo.
• O arquivo de entrada para sua pesquisa é ~/project/logs/app.log.
• A saída deve ser salva em um arquivo chamado ~/project/error_report.txt no diretório ~/project.
• O arquivo de saída deve conter apenas as linhas com a palavra ERROR.

Dicas

• O comando grep é perfeito para procurar padrões em arquivos de texto.
• Para salvar a saída de um comando em um arquivo, você pode usar o operador de redirecionamento >. Isso criará o arquivo se ele não existir ou o sobrescreverá se já existir.

Exemplos

Após filtrar o arquivo de log com sucesso, seu arquivo ~/project/error_report.txt deve conter apenas as linhas de erro:

$ cat ~/project/error_report.txt
[2023-10-26 10:00:03] ERROR: Failed to process payment transaction #12345.
[2023-10-26 10:00:05] ERROR: NullPointerException at com.innovatech.Billing.process(Billing.java:101).

O arquivo deve conter exatamente 2 linhas, ambas começando com carimbos de data/hora e contendo a palavra "ERROR".

Investigando Mensagens de Boot do Sistema

Os erros da aplicação podem ser um sintoma de um problema mais profundo de hardware ou de nível de kernel. Um bom lugar para procurar tais problemas é o buffer de anéis do kernel (kernel ring buffer), que contém mensagens do processo de boot do sistema e operações de drivers.

Tarefas

• Examinar as mensagens de kernel do sistema em busca de quaisquer linhas relacionadas a fail ou error.
• Salvar essas descobertas em um arquivo chamado ~/project/boot_issues.txt.

Requisitos

• Você deve usar o comando dmesg para visualizar as mensagens do kernel.
• Sua busca por fail ou error deve ser insensível a maiúsculas e minúsculas (case-insensitive).
• Os resultados devem ser salvos em um arquivo chamado ~/project/boot_issues.txt.
• Nota: Você pode precisar de privilégios administrativos (sudo) para acessar as mensagens do kernel.

Dicas

• O comando dmesg exibe as mensagens do kernel. Você pode enviar sua saída para outro comando através de um "pipe" para filtragem.
• O operador pipe | envia a saída de um comando para a entrada de outro.
• A opção -i do comando grep torna a busca insensível a maiúsculas e minúsculas.
• Para pesquisar múltiplos padrões de uma vez (como fail OU error), você pode usar grep -E 'padrao1|padrao2'.
• Nota: Se você encontrar um erro de "Operation not permitted", tente executar o comando com sudo para obter os privilégios necessários.

Exemplos

Após filtrar as mensagens do kernel com sucesso, seu arquivo ~/project/boot_issues.txt deve conter mensagens relevantes do sistema:

$ cat ~/project/boot_issues.txt
[    0.330755] acpi PNP0A03:00: fail to add MMCONFIG information, can't access extended PCI configuration space under this bridge.
[    1.026520] RAS: Correctable Errors collector initialized.
[   28.260800] kernel: [   10.123456] my-driver: probe of 0000:00:1f.0 failed with error -2

O arquivo deve conter mensagens do kernel que incluam palavras como "fail" ou "error" (independentemente de maiúsculas), mostrando potenciais problemas de hardware ou drivers durante o boot do sistema.

Examinando o Arquivo de Configuração do Servidor Web

Nenhum problema crítico de hardware foi encontrado. O problema pode estar na configuração do servidor web. Vamos examinar o arquivo de configuração do Nginx para ver como ele está configurado. Às vezes, erros de configuração, como ter poucos processos de trabalho (worker processes), podem causar gargalos de desempenho e levar a falhas na aplicação sob carga.

Tarefas

• Pesquisar no arquivo de configuração do servidor web em ~/project/config/nginx.conf.
• Encontrar a linha que contém a diretiva worker_processes.
• Anexar (append) esta linha ao arquivo ~/project/error_report.txt que você criou no primeiro passo.

Requisitos

• O arquivo de entrada é ~/project/config/nginx.conf.
• Você deve anexar o resultado ao ~/project/error_report.txt, não sobrescrevê-lo.

Dicas

• Você pode usar o grep novamente para esta tarefa.
• Para anexar a saída a um arquivo em vez de sobrescrevê-lo, use o operador >>.

Exemplos

Após anexar a linha worker_processes ao seu relatório de erros existente, o arquivo ~/project/error_report.txt deve agora conter tanto as linhas de erro originais quanto a nova linha de configuração:

$ cat ~/project/error_report.txt
[2023-10-26 10:00:03] ERROR: Failed to process payment transaction #12345.
[2023-10-26 10:00:05] ERROR: NullPointerException at com.innovatech.Billing.process(Billing.java:101).
worker_processes 4;

O arquivo deve conter 3 linhas no total: 2 linhas de erro originais mais 1 nova linha com "worker_processes 4;".

Comparando Arquivos de Configuração de Staging e Produção

Uma fonte comum de problemas em produção é a discrepância entre os ambientes de staging (homologação) e produção. Um recurso pode funcionar perfeitamente em staging, mas falhar em produção devido a uma pequena diferença de configuração. Vamos comparar os arquivos de configuração da aplicação de ambos os ambientes para identificar quaisquer diferenças.

Tarefas

• Comparar o arquivo de configuração de staging ~/project/config/staging/app.conf com o arquivo de configuração de produção ~/project/config/production/app.conf.
• Salvar as diferenças em um novo arquivo chamado ~/project/config_diff.txt.

Requisitos

• Você deve usar o comando diff.
• A saída mostrando as diferenças deve ser salva em ~/project/config_diff.txt.

Dicas

• O comando diff foi projetado especificamente para comparar dois arquivos linha por linha.
• A sintaxe básica é diff arquivo1 arquivo2, onde ele mostra quais mudanças precisam ser feitas no arquivo1 para torná-lo idêntico ao arquivo2.
• A ordem dos arquivos importa! diff A B e diff B A mostrarão saídas diferentes.
• Você pode redirecionar a saída do diff para um arquivo assim como fez com o grep.

Exemplos

Após comparar os arquivos de configuração de staging e produção, seu arquivo ~/project/config_diff.txt deve mostrar as diferenças entre os dois ambientes:

$ cat ~/project/config_diff.txt
1,5c1,5
< ## Staging Configuration
< database.url=jdbc:mysql://staging-db:3306/nexus
< api.key=staging_key_abc123
< feature.flag.new_dashboard=true
< timeout.ms=3000
---
> ## Production Configuration
> database.url=jdbc:mysql://prod-db:3306/nexus
> api.key=prod_key_xyz789
> feature.flag.new_dashboard=false
> timeout.ms=5000

A saída do diff mostra quais alterações seriam necessárias no arquivo de configuração de staging para que ele correspondesse ao arquivo de produção. Linhas começando com < mostram o conteúdo do arquivo de staging, enquanto linhas começando com > mostram o conteúdo do arquivo de produção. Isso revela que o ambiente de produção usa URLs de banco de dados, chaves de API, flags de recursos e valores de timeout diferentes em comparação ao staging.

Verificando a Consistência de Diretórios Entre Servidores

A diferença de configuração é uma pista forte! Parece que o servidor de produção também pode estar sentindo falta de alguns arquivos críticos que existem no servidor de staging. Isso pode ser devido a uma falha na implantação. Vamos simular isso comparando dois diretórios que representam as estruturas de arquivos de dois servidores diferentes.

Tarefas

• Você tem dois diretórios: /home/labex/project/server1_files (representando o servidor de staging) e /home/labex/project/server2_files (representando o servidor de produção).
• Compare esses dois diretórios para descobrir quais arquivos são exclusivos do server1_files.
• Salvar a saída completa da comparação em um arquivo chamado /home/labex/project/missing_files.txt.

Requisitos

• Você deve usar o comando diff para comparar os dois diretórios.
• A saída deve ser salva em /home/labex/project/missing_files.txt.

Dicas

• O comando diff também pode comparar diretórios se você fornecer caminhos de diretórios em vez de caminhos de arquivos.
• Usar a opção -r ou --recursive com o diff é uma boa prática ao comparar diretórios, pois ele comparará todos os arquivos dentro deles.
• O formato de saída do diff em diretórios declarará explicitamente quais arquivos estão "Only in" (Apenas em) um diretório específico.
• Assim como com arquivos, a ordem importa ao comparar diretórios. diff dir1 dir2 mostra o que está no dir1 mas não no dir2, enquanto diff dir2 dir1 mostra o oposto.

Exemplos

Após comparar os dois diretórios dos servidores, seu arquivo /home/labex/project/missing_files.txt deve mostrar quais arquivos estão faltando no servidor de produção:

$ cat /home/labex/project/missing_files.txt
Only in /home/labex/project/server1_files: asset2.js

Esta saída indica que asset2.js existe no primeiro diretório (server1_files, representando o servidor de staging), mas está faltando no segundo diretório (server2_files, representando o servidor de produção). Ao comparar staging primeiro e produção depois, podemos identificar facilmente arquivos que estão faltando na produção, o que poderia explicar algumas das falhas da aplicação.

Resumo

Trabalho de detetive excepcional! Você identificou com sucesso as causas raízes das falhas críticas do Projeto Phoenix e forneceu a Sarah Chen e à equipe de desenvolvimento informações acionáveis para resolver os problemas.

Através de sua investigação sistemática, você dominou comandos essenciais de solução de problemas:

• grep: Para filtrar arquivos de log e extrair informações críticas de erro.
• dmesg: Para investigar problemas de hardware e kernel em nível de sistema.
• diff: Para comparar arquivos de configuração e identificar discrepâncias entre ambientes.
• Pipelines de comando e redirecionamento: Para processar e documentar suas descobertas de forma eficiente.

Sua abordagem metódica na análise de logs salvou o Projeto Phoenix de uma falha potencialmente catastrófica. A equipe de desenvolvimento agora tem uma direção clara para corrigir as incompatibilidades de configuração e os arquivos de implantação ausentes que você descobriu.

Sarah Chen ficou tão impressionada com suas habilidades de investigação que está recomendando você para uma função de segurança. Amanhã, você assumirá o papel de Guardião da Fortaleza para proteger a infraestrutura do Projeto Phoenix contra futuras ameaças!