DÍA 03: El Investigador de Registros

Introducción

¡Es el tercer día en LabEx Corporation y el desastre ha golpeado al Proyecto Phoenix! Llegas a la oficina y encuentras a Sarah Chen y al equipo de desarrollo en modo de crisis. La aplicación que ayudaste a organizar ayer ha encontrado errores críticos durante su primera fase de pruebas importante.

Las alertas de emergencia están inundando los sistemas de monitoreo, los usuarios reportan fallos en la aplicación y la canalización de despliegue se ha detenido por completo. Sarah se dirige a ti con una mirada de desesperación: el ingeniero DevOps senior está de baja por enfermedad y la fecha límite del proyecto se acerca rápidamente.

"Necesitamos a nuestro mejor investigador en esto", dice Sarah, entregándote el informe de incidentes. "Tu enfoque sistemático para organizar nuestros archivos fue exactamente lo que necesitábamos. Ahora necesitamos ese mismo pensamiento metódico para resolver este misterio".

Tu misión es profundizar en el servidor del Proyecto Phoenix, analizar los registros y archivos de configuración, y descubrir la causa raíz de estos fallos. Utilizarás herramientas avanzadas de línea de comandos de Linux para unir las pistas y restaurar la estabilidad de la aplicación en la que tu equipo ha trabajado tan duro. ¡El futuro del Proyecto Phoenix, y posiblemente tu carrera en TechNova, depende de tus habilidades detectivescas!

Revisión del contenido del archivo de registro de la aplicación

Tu primer paso como investigador es revisar el archivo de registro de la aplicación del Proyecto Phoenix. La aplicación escribe sus registros en ~/project/logs/app.log. Una avalancha de mensajes puede ser abrumadora, por lo que necesitas encontrar los mensajes de error críticos rápidamente para entender qué está fallando en el sistema que ayudaste a organizar ayer.

Tareas

• Filtra el archivo ~/project/logs/app.log para encontrar todas las líneas que contengan la palabra ERROR.
• Guarda las líneas filtradas en un nuevo archivo llamado ~/project/error_report.txt.

Requisitos

• Debes utilizar una herramienta de línea de comandos para buscar en el archivo.
• El archivo de entrada para tu búsqueda es ~/project/logs/app.log.
• La salida debe guardarse en un archivo llamado ~/project/error_report.txt en el directorio ~/project.
• El archivo de salida solo debe contener las líneas con la palabra ERROR.

Pistas

• El comando grep es perfecto para buscar patrones en archivos de texto.
• Para guardar la salida de un comando en un archivo, puedes usar el operador de redirección >. Esto creará el archivo si no existe o lo sobrescribirá si ya existe.

Ejemplos

Después de filtrar con éxito el archivo de registro, tu archivo ~/project/error_report.txt debería contener solo las líneas de error:

$ 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).

El archivo debe contener exactamente 2 líneas, ambas comenzando con marcas de tiempo y conteniendo la palabra "ERROR".

Investigación de los mensajes de arranque del sistema

Los errores de la aplicación podrían ser un síntoma de un problema más profundo a nivel de hardware o del kernel. Un buen lugar para buscar tales problemas es el búfer circular del kernel, que contiene mensajes del proceso de arranque del sistema y de las operaciones de los controladores.

Tareas

• Examina los mensajes del kernel del sistema en busca de líneas relacionadas con fail o error.
• Guarda estos hallazgos en un archivo llamado ~/project/boot_issues.txt.

Requisitos

• Debes utilizar el comando dmesg para ver los mensajes del kernel.
• Tu búsqueda de fail o error debe ignorar mayúsculas y minúsculas.
• Los resultados deben guardarse en un archivo llamado ~/project/boot_issues.txt.
• Nota: Es posible que necesites privilegios administrativos (sudo) para acceder a los mensajes del kernel.

Pistas

• El comando dmesg muestra los mensajes del kernel. Puedes "canalizar" (pipe) su salida a otro comando para filtrarla.
• El operador de tubería | envía la salida de un comando a la entrada de otro.
• La opción -i del comando grep hace que la búsqueda no distinga entre mayúsculas y minúsculas.
• Para buscar múltiples patrones a la vez (como fail O error), puedes usar grep -E 'pattern1|pattern2'.
• Nota: Si encuentras un error de "Operation not permitted", intenta ejecutar el comando con sudo para obtener los privilegios necesarios.

Ejemplos

Después de filtrar con éxito los mensajes del kernel, tu archivo ~/project/boot_issues.txt debería contener mensajes relevantes del 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

El archivo debe contener mensajes del kernel que incluyan palabras como "fail" o "error" (sin distinguir mayúsculas/minúsculas), mostrando posibles problemas de hardware o controladores durante el arranque del sistema.

Examen del archivo de configuración del servidor web

No se encontraron problemas críticos de hardware. El problema podría estar en la configuración del servidor web. Examinemos el archivo de configuración de Nginx para ver cómo está configurado. A veces, configuraciones incorrectas, como tener muy pocos procesos de trabajo (worker processes), pueden causar cuellos de botella en el rendimiento y provocar fallos en la aplicación bajo carga.

Tareas

• Busca en el archivo de configuración del servidor web en ~/project/config/nginx.conf.
• Encuentra la línea que contiene la directiva worker_processes.
• Añade (append) esta línea al archivo ~/project/error_report.txt que creaste en el primer paso.

Requisitos

• El archivo de entrada es ~/project/config/nginx.conf.
• Debes añadir el resultado a ~/project/error_report.txt, no sobrescribirlo.

Pistas

• Puedes usar grep nuevamente para esta tarea.
• Para añadir la salida a un archivo en lugar de sobrescribirlo, usa el operador >>.

Ejemplos

Después de añadir la línea worker_processes a tu informe de errores existente, el archivo ~/project/error_report.txt debería contener ahora tanto las líneas de error originales como la nueva línea de configuración:

$ 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;

El archivo debe contener un total de 3 líneas: 2 líneas de error originales más 1 línea nueva con "worker_processes 4;".

Comparación de archivos de configuración de Staging y Producción

Una fuente común de problemas en producción es la discrepancia entre los entornos de staging (preproducción) y producción. Una característica puede funcionar perfectamente en staging pero fallar en producción debido a una pequeña diferencia de configuración. Comparemos los archivos de configuración de la aplicación de ambos entornos para detectar cualquier diferencia.

Tareas

• Compara el archivo de configuración de staging ~/project/config/staging/app.conf con el archivo de configuración de producción ~/project/config/production/app.conf.
• Guarda las diferencias en un nuevo archivo llamado ~/project/config_diff.txt.

Requisitos

• Debes utilizar el comando diff.
• La salida que muestra las diferencias debe guardarse en ~/project/config_diff.txt.

Pistas

• El comando diff está diseñado específicamente para comparar dos archivos línea por línea.
• La sintaxis básica es diff archivo1 archivo2, donde muestra qué cambios deben hacerse en el archivo1 para que sea idéntico al archivo2.
• ¡El orden de los archivos importa! diff A B y diff B A mostrarán salidas diferentes.
• Puedes redirigir la salida de diff a un archivo tal como hiciste con grep.

Ejemplos

Después de comparar los archivos de configuración de staging y producción, tu archivo ~/project/config_diff.txt debería mostrar las diferencias entre ambos entornos:

$ 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

La salida de diff muestra qué cambios tendrían que hacerse en el archivo de configuración de staging para que coincida con el archivo de configuración de producción. Las líneas que comienzan con < muestran el contenido del archivo de staging, mientras que las líneas que comienzan con > muestran el contenido del archivo de producción. Esto revela que el entorno de producción utiliza URLs de base de datos, claves API, indicadores de características y valores de tiempo de espera diferentes en comparación con staging.

Verificación de la consistencia de directorios entre servidores

¡La diferencia de configuración es una pista importante! Parece que al servidor de producción también le podrían faltar algunos archivos críticos que existen en el servidor de staging. Esto podría deberse a un despliegue fallido. Simulemos esto comparando dos directorios que representan las estructuras de archivos de dos servidores diferentes.

Tareas

• Tienes dos directorios: /home/labex/project/server1_files (que representa el servidor de staging) y /home/labex/project/server2_files (que representa el servidor de producción).
• Compara estos dos directorios para averiguar qué archivos son únicos en server1_files.
• Guarda la salida completa de la comparación en un archivo llamado /home/labex/project/missing_files.txt.

Requisitos

• Debes utilizar el comando diff para comparar los dos directorios.
• La salida debe guardarse en /home/labex/project/missing_files.txt.

Pistas

• El comando diff también puede comparar directorios si proporcionas rutas de directorio en lugar de rutas de archivo.
• Usar la opción -r o --recursive con diff es una buena práctica para comparar directorios, ya que comparará todos los archivos dentro de ellos.
• El formato de salida de diff en directorios indicará explícitamente qué archivos están "Only in" (Solo en) un directorio específico.
• Al igual que con los archivos, el orden importa al comparar directorios. diff dir1 dir2 muestra lo que hay en dir1 pero no en dir2, mientras que diff dir2 dir1 muestra lo contrario.

Ejemplos

Después de comparar los dos directorios del servidor, tu archivo /home/labex/project/missing_files.txt debería mostrar qué archivos faltan en el servidor de producción:

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

Esta salida indica que asset2.js existe en el primer directorio (server1_files, que representa el servidor de staging) pero falta en el segundo directorio (server2_files, que representa el servidor de producción). Al comparar primero staging y luego producción, podemos identificar fácilmente los archivos que faltan en producción, lo que podría explicar algunos de los fallos de la aplicación.

Resumen

¡Un trabajo de detective excepcional! Has identificado con éxito las causas raíz de los fallos críticos del Proyecto Phoenix y has proporcionado a Sarah Chen y al equipo de desarrollo información procesable para resolver los problemas.

A través de tu investigación sistemática, has dominado comandos esenciales de resolución de problemas:

• grep: Para filtrar archivos de registro y extraer información crítica de errores.
• dmesg: Para investigar problemas de hardware y del kernel a nivel de sistema.
• diff: Para comparar archivos de configuración e identificar discrepancias entre entornos.
• Tuberías (pipelines) y redirección de comandos: Para procesar y documentar tus hallazgos de manera eficiente.

Tu enfoque metódico para el análisis de registros ha salvado al Proyecto Phoenix de un fallo potencialmente catastrófico. El equipo de desarrollo ahora tiene una dirección clara para corregir las discrepancias de configuración y los archivos de despliegue faltantes que descubriste.

Sarah Chen quedó tan impresionada con tus habilidades de investigación que te recomendará para un puesto de seguridad. ¡Mañana, te pondrás en la piel del Guardián de la Fortaleza para asegurar la infraestructura del Proyecto Phoenix y protegerla de futuras amenazas!