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 parou completamente. Sarah se vira para você com um olhar de desespero — o engenheiro DevOps sênior está doente e o prazo do projeto está se aproximando rapidamente.

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

Sua missão é mergulhar fundo 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 avassaladora, então você precisa encontrar as mensagens de erro críticas rapidamente para entender o que está acontecendo com o sistema que você ajudou a organizar ontem.

Tarefas

• Filtre o arquivo ~/project/logs/app.log para encontrar todas as linhas que contenham a palavra ERROR.
• Salve 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 pesquisar 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 ele já existir.

Exemplos

Após filtrar com sucesso o arquivo de log, 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 Inicialização 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 anel do kernel, que contém mensagens do processo de inicialização do sistema e operações de driver.

Tarefas

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

Requisitos

• Você deve usar o comando dmesg para visualizar as mensagens do kernel.
• Sua pesquisa por fail ou error deve ignorar 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 "encaminhar" (pipe) sua saída para outro comando para filtragem.
• O operador de pipe | envia a saída de um comando para a entrada de outro.
• A opção -i do comando grep torna a pesquisa insensível a maiúsculas/minúsculas.
• Para pesquisar vários padrões de uma vez (como fail OU error), você pode usar grep -E 'pattern1|pattern2'.
• 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 com sucesso as mensagens do kernel, 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" (ignorando maiúsculas/minúsculas), mostrando possíveis problemas de hardware ou driver durante a inicialização 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, configurações incorretas, como ter poucos processos de trabalho (worker processes), podem causar gargalos de desempenho e levar a falhas na aplicação sob carga.

Tarefas

• Pesquise no arquivo de configuração do servidor web em ~/project/config/nginx.conf.
• Encontre a linha que contém a diretiva worker_processes.
• Anexe 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 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

• Compare 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.
• Salve 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 alterações 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 exatamente 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 precisariam ser feitas no arquivo de configuração de staging para que ele corresponda ao arquivo de configuração de produção. As linhas que começam com < mostram o conteúdo do arquivo de staging, enquanto as linhas que começam 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, sinalizadores de recursos e valores de tempo limite diferentes em comparação com o 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 perdendo alguns arquivos críticos que existem no servidor de staging. Isso pode ser devido a uma implantação com falha. 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 de server1_files.
• Salve 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ório em vez de caminhos de arquivo.
• Usar a opção -r ou --recursive com o diff é uma boa prática para 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 nos arquivos, a ordem importa ao comparar diretórios. diff dir1 dir2 mostra o que está em dir1, mas não em dir2, enquanto diff dir2 dir1 mostra o oposto.

Exemplos

Após comparar os dois diretórios do servidor, 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 o staging primeiro e a produção depois, podemos identificar facilmente os 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 raiz 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 com eficiência.

Sua abordagem metódica à análise de logs salvou o Projeto Phoenix de uma falha potencialmente catastrófica. A equipe de desenvolvimento agora tem uma direção clara sobre como 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 e protegê-la de futuras ameaças!