El investigador de registros

Introducción

Es el tercer día en LabEx Corporation y el desastre ha golpeado al Proyecto Phoenix. Al llegar a la oficina, encuentra a Sarah Chen y al equipo de desarrollo en plena crisis. La aplicación que ayudó a organizar ayer ha encontrado errores críticos durante su primera fase importante de pruebas.

Las alertas de emergencia inundan los sistemas de monitorización, los usuarios informan de fallos en la aplicación y la canalización de despliegue se ha detenido por completo. Sarah lo mira desesperada: el ingeniero sénior de DevOps está enfermo y la fecha límite del proyecto se acerca rápidamente.

«Necesitamos a nuestro mejor investigador para esto», dice Sarah mientras le entrega el informe del incidente. «Su forma sistemática de organizar nuestros archivos era exactamente lo que necesitábamos. Ahora necesitamos ese mismo razonamiento metódico para resolver este misterio».

Su misión consiste en investigar a fondo el servidor del Proyecto Phoenix, analizar los registros y los archivos de configuración, y descubrir la causa raíz de estos fallos. Utilizará herramientas avanzadas de la línea de comandos de Linux para reunir las pistas y recuperar la estabilidad de la aplicación que su equipo se ha esforzado tanto por crear. ¡El futuro del Proyecto Phoenix —y posiblemente su carrera en TechNova— depende de sus dotes de detective!

Revisar el contenido del archivo de registro de la aplicación

El primer paso de su investigación 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 gran cantidad de mensajes puede resultar abrumadora, por lo que debe encontrar rápidamente los mensajes de error críticos para comprender qué ocurre en el sistema que ayudó a organizar ayer.

Tareas

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

Requisitos

• Debe utilizar una herramienta de la línea de comandos para buscar en el archivo.
• El archivo de entrada de la búsqueda es ~/project/logs/app.log.
• La salida debe guardarse en un archivo llamado ~/project/error_report.txt, dentro del directorio ~/project.
• El archivo de salida debe contener únicamente las líneas que incluyan la palabra ERROR.

Sugerencias

• El comando grep es ideal para buscar patrones en archivos de texto.
• Para guardar la salida de un comando en un archivo, puede utilizar el operador de redirección >. Este operador crea el archivo si no existe o lo sobrescribe si ya existe.

Ejemplos

Después de filtrar correctamente el archivo de registro, el archivo ~/project/error_report.txt debe contener únicamente 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 deben comenzar con marcas de tiempo y contener la palabra "ERROR".

Investigar los mensajes de arranque del sistema

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

Tareas

• Examine los mensajes del núcleo del sistema para encontrar líneas relacionadas con fail o error.
• Guarde estos resultados en un archivo llamado ~/project/boot_issues.txt.

Requisitos

• Debe utilizar el comando dmesg para consultar los mensajes del núcleo.
• La búsqueda de fail o error debe distinguir entre mayúsculas y minúsculas.
• Los resultados deben guardarse en un archivo llamado ~/project/boot_issues.txt.
• Nota: es posible que necesite privilegios administrativos (sudo) para acceder a los mensajes del núcleo.

Sugerencias

• El comando dmesg muestra los mensajes del núcleo. Puede enviar («canalizar») 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 varios patrones a la vez, como fail O error, puede utilizar grep -E 'pattern1|pattern2'.
• Nota: si encuentra un error "Operation not permitted", intente ejecutar el comando con sudo para obtener los privilegios necesarios.

Ejemplos

Después de filtrar correctamente los mensajes del núcleo, el archivo ~/project/boot_issues.txt debe 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 núcleo que incluyan palabras como "fail" o "error" sin distinguir entre mayúsculas y minúsculas. Estos mensajes muestran posibles problemas de hardware o de controladores durante el arranque del sistema.

Examinar el archivo de configuración del servidor web

No se han encontrado problemas críticos de hardware. El problema podría estar en la configuración del servidor web. Examine el archivo de configuración de Nginx para comprobar cómo está configurado. A veces, una configuración incorrecta, como tener muy pocos procesos de trabajo, puede provocar cuellos de botella de rendimiento y fallos de la aplicación bajo carga.

Tareas

• Busque en el archivo de configuración del servidor web ubicado en ~/project/config/nginx.conf.
• Encuentre la línea que contiene la directiva worker_processes.
• Añada esta línea al final del archivo ~/project/error_report.txt que creó en el primer paso.

Requisitos

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

Sugerencias

• Puede volver a utilizar grep para esta tarea.
• Para añadir la salida al final de un archivo en lugar de sobrescribirlo, utilice el operador >>.

Ejemplos

Después de añadir la línea worker_processes al informe de errores existente, el archivo ~/project/error_report.txt debe contener las líneas de error originales y 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: las 2 líneas de error originales y 1 línea nueva con "worker_processes 4;".

Comparar los archivos de configuración de staging y producción

Una fuente habitual de problemas en producción es la discrepancia entre los entornos de staging y producción. Una función puede funcionar perfectamente en staging, pero fallar en producción debido a una pequeña diferencia de configuración. Compare los archivos de configuración de la aplicación de ambos entornos para detectar cualquier diferencia.

Tareas

• Compare 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.
• Guarde las diferencias en un archivo nuevo llamado ~/project/config_diff.txt.

Requisitos

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

Sugerencias

• El comando diff está diseñado específicamente para comparar dos archivos línea por línea.
• La sintaxis básica es diff file1 file2; muestra qué cambios deben realizarse en file1 para que sea idéntico a file2.
• El orden de los archivos es importante. diff A B y diff B A muestran salidas diferentes.
• Puede redirigir la salida de diff a un archivo igual que hizo con grep.

Ejemplos

Después de comparar los archivos de configuración de staging y producción, el archivo ~/project/config_diff.txt debe 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 realizarse 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 distintas URL de base de datos, claves de API, indicadores de funciones y valores de tiempo de espera en comparación con staging.

Verificar la coherencia de los directorios entre servidores

La diferencia de configuración es una pista importante. Parece que al servidor de producción también podrían faltarle algunos archivos críticos que sí existen en el servidor de staging. Esto podría deberse a un despliegue fallido. Simule esta situación comparando dos directorios que representan las estructuras de archivos de dos servidores diferentes.

Tareas

• Tiene 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.
• Compare estos dos directorios para averiguar qué archivos son exclusivos de server1_files.
• Guarde toda la salida de la comparación en un archivo llamado /home/labex/project/missing_files.txt.

Requisitos

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

Sugerencias

• diff también puede comparar directorios si proporciona rutas de directorios en lugar de rutas de archivos.
• Utilizar la opción -r o --recursive con diff es una buena práctica para comparar directorios, ya que comparará todos los archivos que contienen.
• El formato de salida de diff para directorios indica explícitamente qué archivos aparecen como "Only in" un directorio concreto.
• Al igual que con los archivos, el orden importa al comparar directorios. diff dir1 dir2 muestra lo que existe en dir1 pero no en dir2, mientras que diff dir2 dir1 muestra lo contrario.

Ejemplos

Después de comparar los dos directorios de los servidores, el archivo /home/labex/project/missing_files.txt debe 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 después producción, puede identificar fácilmente los archivos que faltan en producción, lo que podría explicar algunos fallos de la aplicación.

Resumen

¡Excelente trabajo de investigación! Ha identificado correctamente las causas raíz de los fallos críticos del Proyecto Phoenix y ha proporcionado a Sarah Chen y al equipo de desarrollo información útil para resolver los problemas.

A través de esta investigación sistemática, ha dominado comandos esenciales para la resolución de problemas:

• grep: para filtrar archivos de registro y extraer información crítica sobre errores.
• dmesg: para investigar problemas de hardware y del núcleo a nivel del sistema.
• diff: para comparar archivos de configuración e identificar discrepancias entre entornos.
• Canalizaciones y redirecciones de comandos: para procesar y documentar sus hallazgos de forma eficiente.

Su enfoque metódico para analizar los registros ha salvado al Proyecto Phoenix de un fallo potencialmente catastrófico. Ahora el equipo de desarrollo tiene una dirección clara para corregir las diferencias de configuración y los archivos de despliegue que faltaban.

Sarah Chen quedó tan impresionada con sus habilidades de investigación que le recomendará para un puesto de seguridad. Mañana asumirá el papel del Guardián de la Fortaleza para proteger la infraestructura del Proyecto Phoenix y defenderla de futuras amenazas.