DAY 03: 로그 조사관

소개

LabEx Corporation 에서의 셋째 날이 밝았습니다. 그런데 '프로젝트 피닉스'에 비상이 걸렸습니다! 사무실에 도착하니 사라 첸과 개발 팀이 위기 상황에 빠져 있습니다. 어제 여러분이 정리 작업을 도왔던 애플리케이션이 첫 번째 주요 테스트 단계에서 치명적인 오류를 일으킨 것입니다.

모니터링 시스템에는 긴급 경고가 쏟아지고 있고, 사용자들은 서비스 장애를 보고하고 있으며, 배포 파이프라인은 완전히 중단되었습니다. 사라는 절박한 표정으로 여러분을 바라봅니다. 선임 DevOps 엔지니어는 병가 중이고 프로젝트 마감 기한은 코앞으로 다가왔기 때문입니다.

"우리 팀 최고의 조사관이 이 사건을 맡아줘야 해요." 사라가 사건 보고서를 건네며 말합니다. "어제 파일을 체계적으로 정리하던 당신의 모습이 바로 지금 우리에게 필요한 능력이에요. 이제 그 논리적인 사고력을 발휘해 이 미스터리를 풀어주세요."

여러분의 임무는 프로젝트 피닉스 서버 깊숙이 들어가 로그와 설정 파일을 분석하고, 이러한 장애의 근본 원인을 찾아내는 것입니다. 고급 리눅스 명령줄 도구들을 사용하여 단서들을 조합하고, 팀원들이 공들여 만든 애플리케이션의 안정성을 되찾아야 합니다. 프로젝트 피닉스의 미래, 그리고 어쩌면 TechNova 에서의 여러분의 커리어가 여러분의 수사 능력에 달려 있습니다!

애플리케이션 로그 파일 내용 검토하기

조사관으로서의 첫 번째 단계는 프로젝트 피닉스의 애플리케이션 로그 파일을 확인하는 것입니다. 애플리케이션은 로그를 ~/project/logs/app.log에 기록합니다. 쏟아지는 메시지 양에 압도될 수 있으므로, 어제 정리한 시스템에 어떤 문제가 생겼는지 파악하기 위해 치명적인 오류 메시지를 신속하게 찾아내야 합니다.

과제

• ~/project/logs/app.log 파일을 필터링하여 ERROR라는 단어가 포함된 모든 줄을 찾으세요.
• 필터링된 내용을 ~/project/error_report.txt라는 새 파일로 저장하세요.

요구 사항

• 파일을 검색할 때 반드시 명령줄 도구를 사용해야 합니다.
• 검색할 입력 파일은 ~/project/logs/app.log입니다.
• 결과물은 ~/project 디렉토리 내의 ~/project/error_report.txt 파일에 저장되어야 합니다.
• 출력 파일에는 ERROR 단어가 포함된 줄만 있어야 합니다.

힌트

• grep 명령어는 텍스트 파일에서 특정 패턴을 검색하는 데 최적입니다.
• 명령의 실행 결과를 파일로 저장하려면 > 리다이렉션 연산자를 사용할 수 있습니다. 이 연산자는 파일이 없으면 새로 생성하고, 이미 존재하면 내용을 덮어씁니다.

예시

로그 파일 필터링에 성공하면, ~/project/error_report.txt 파일에는 다음과 같이 오류 관련 줄만 포함되어야 합니다.

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

파일은 정확히 2 줄이어야 하며, 각 줄은 타임스탬프로 시작하고 "ERROR"라는 단어를 포함해야 합니다.

시스템 부팅 메시지 조사하기

애플리케이션 오류는 더 깊은 하드웨어 문제나 커널 수준 이슈의 증상일 수 있습니다. 이러한 문제를 확인하기 좋은 곳은 시스템 부팅 과정과 드라이버 작동 메시지가 담긴 커널 링 버퍼 (kernel ring buffer) 입니다.

과제

• 시스템의 커널 메시지에서 fail 또는 error와 관련된 줄이 있는지 조사하세요.
• 조사 결과를 ~/project/boot_issues.txt 파일에 저장하세요.

요구 사항

• 커널 메시지를 확인하기 위해 dmesg 명령어를 사용해야 합니다.
• fail 또는 error 검색 시 대소문자를 구분하지 않아야 합니다.
• 결과는 ~/project/boot_issues.txt 파일에 저장되어야 합니다.
• 참고: 커널 메시지에 접근하려면 관리자 권한 (sudo) 이 필요할 수 있습니다.

힌트

• dmesg 명령어는 커널 메시지를 표시합니다. 이 출력을 다른 명령어로 전달 (pipe) 하여 필터링할 수 있습니다.
• 파이프 연산자 |는 한 명령어의 출력을 다른 명령어의 입력으로 보냅니다.
• grep 명령어의 -i 옵션을 사용하면 대소문자 구분 없이 검색할 수 있습니다.
• 여러 패턴을 동시에 검색하려면 (예: fail 또는 error), grep -E 'pattern1|pattern2' 형식을 사용할 수 있습니다.
• 참고: "Operation not permitted" 오류가 발생하면 sudo를 붙여 필요한 권한을 획득한 후 실행해 보세요.

예시

커널 메시지 필터링에 성공하면, ~/project/boot_issues.txt 파일에 관련 시스템 메시지들이 포함됩니다.

$ 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

파일에는 시스템 부팅 중 발생했을 수 있는 하드웨어 또는 드라이버 문제를 나타내는 "fail"이나 "error"(대소문자 무관) 단어가 포함된 커널 메시지들이 담겨야 합니다.

웹 서버 설정 파일 검사하기

치명적인 하드웨어 문제는 발견되지 않았습니다. 그렇다면 웹 서버 설정에 문제가 있을 수 있습니다. Nginx 설정 파일을 살펴보고 어떻게 구성되어 있는지 확인해 봅시다. 때로는 worker_processes 수가 너무 적게 설정되어 성능 병목 현상이 발생하고, 부하가 걸릴 때 애플리케이션 장애로 이어지기도 합니다.

과제

• ~/project/config/nginx.conf 경로에 있는 웹 서버 설정 파일을 검색하세요.
• worker_processes 지시어가 포함된 줄을 찾으세요.
• 이 줄을 첫 번째 단계에서 만든 ~/project/error_report.txt 파일에 추가 (Append) 하세요.

요구 사항

• 입력 파일은 ~/project/config/nginx.conf입니다.
• 결과를 ~/project/error_report.txt에 저장할 때, 기존 내용을 덮어쓰지 말고 반드시 추가해야 합니다.

힌트

• 이 작업에도 grep을 다시 사용할 수 있습니다.
• 기존 내용을 지우지 않고 파일 끝에 출력을 추가하려면 >> 연산자를 사용하세요.

예시

기존 오류 보고서에 worker_processes 줄을 추가하면, ~/project/error_report.txt 파일에는 원래의 오류 메시지들과 새로운 설정 정보가 함께 들어있어야 합니다.

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

파일은 총 3 줄이어야 합니다: 기존 오류 메시지 2 줄과 "worker_processes 4;"가 포함된 새 줄 1 줄입니다.

스테이징 및 운영 환경 설정 파일 비교하기

운영 환경에서 발생하는 문제의 흔한 원인 중 하나는 스테이징 (Staging) 환경과 운영 (Production) 환경 간의 설정 차이입니다. 스테이징에서는 완벽하게 작동하던 기능이 운영 환경의 사소한 설정 차이 때문에 실패할 수 있습니다. 두 환경의 애플리케이션 설정 파일을 비교하여 차이점을 찾아봅시다.

과제

• 스테이징 설정 파일 ~/project/config/staging/app.conf와 운영 설정 파일 ~/project/config/production/app.conf를 비교하세요.
• 차이점을 ~/project/config_diff.txt라는 새 파일에 저장하세요.

요구 사항

• diff 명령어를 사용해야 합니다.
• 차이점을 보여주는 출력 결과가 ~/project/config_diff.txt에 저장되어야 합니다.

힌트

• diff 명령어는 두 파일을 줄 단위로 비교하기 위해 설계되었습니다.
• 기본 문법은 diff file1 file2이며, file1 을 file2 와 동일하게 만들기 위해 어떤 변경이 필요한지 보여줍니다.
• 파일의 순서가 중요합니다! diff A B와 diff B A는 서로 다른 결과를 출력합니다.
• grep에서 했던 것처럼 diff의 결과도 파일로 리다이렉션할 수 있습니다.

예시

스테이징과 운영 설정 파일을 비교한 후, ~/project/config_diff.txt 파일에는 두 환경 간의 차이점이 다음과 같이 나타나야 합니다.

$ 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

diff 출력은 스테이징 설정 파일을 운영 설정 파일과 일치시키기 위해 어떤 수정이 필요한지 보여줍니다. <로 시작하는 줄은 스테이징 파일의 내용을, >로 시작하는 줄은 운영 파일의 내용을 나타냅니다. 이를 통해 운영 환경이 스테이징과 비교했을 때 다른 데이터베이스 URL, API 키, 기능 플래그 (feature flag), 타임아웃 값을 사용하고 있음을 알 수 있습니다.

서버 간 디렉토리 일관성 확인하기

설정 차이라는 강력한 단서를 찾았습니다! 운영 서버에는 스테이징 서버에 존재하는 일부 중요한 파일이 누락되었을 가능성도 있어 보입니다. 이는 배포 실패로 인해 발생할 수 있는 문제입니다. 두 서버의 파일 구조를 나타내는 두 디렉토리를 비교하여 이를 시뮬레이션해 봅시다.

과제

• 두 개의 디렉토리가 있습니다: /home/labex/project/server1_files (스테이징 서버) 와 /home/labex/project/server2_files (운영 서버).
• 이 두 디렉토리를 비교하여 server1_files에만 존재하는 파일이 무엇인지 찾아내세요.
• 전체 비교 결과를 /home/labex/project/missing_files.txt라는 파일에 저장하세요.

요구 사항

• 두 디렉토리를 비교하기 위해 diff 명령어를 사용해야 합니다.
• 결과는 /home/labex/project/missing_files.txt에 저장되어야 합니다.

힌트

• diff 명령어에 파일 경로 대신 디렉토리 경로를 제공하면 디렉토리를 비교할 수 있습니다.
• 디렉토리를 비교할 때는 내부의 모든 파일을 비교하도록 -r 또는 --recursive 옵션을 사용하는 것이 좋습니다.
• 디렉토리에 대한 diff 출력 형식은 특정 디렉토리에만 있는 파일을 "Only in"이라고 명시적으로 표시합니다.
• 파일 비교와 마찬가지로 순서가 중요합니다. diff dir1 dir2는 dir1 에는 있지만 dir2 에는 없는 것을 보여주고, diff dir2 dir1은 그 반대를 보여줍니다.

예시

두 서버 디렉토리를 비교한 후, /home/labex/project/missing_files.txt 파일에는 운영 서버에서 누락된 파일이 표시되어야 합니다.

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

이 출력은 asset2.js가 첫 번째 디렉토리 (server1_files, 스테이징 서버) 에는 존재하지만 두 번째 디렉토리 (server2_files, 운영 서버) 에는 없음을 나타냅니다. 스테이징을 먼저, 운영을 나중에 비교함으로써 운영 환경에서 누락된 파일을 쉽게 식별할 수 있으며, 이것이 애플리케이션 장애의 원인일 수 있습니다.

요약

훌륭한 조사였습니다! 프로젝트 피닉스의 치명적인 장애 원인을 성공적으로 찾아냈고, 사라 첸과 개발 팀이 문제를 해결할 수 있는 결정적인 정보를 제공했습니다.

체계적인 조사를 통해 다음과 같은 필수 문제 해결 명령어들을 익혔습니다.

• grep: 로그 파일을 필터링하고 중요한 오류 정보를 추출합니다.
• dmesg: 시스템 수준의 하드웨어 및 커널 문제를 조사합니다.
• diff: 설정 파일을 비교하고 환경 간의 불일치를 식별합니다.
• 명령 파이프라인 및 리다이렉션: 조사 결과를 효율적으로 처리하고 문서화합니다.

여러분의 체계적인 로그 분석 덕분에 프로젝트 피닉스는 파국을 면할 수 있었습니다. 이제 개발 팀은 여러분이 발견한 설정 불일치와 누락된 배포 파일들을 수정할 수 있는 명확한 방향을 갖게 되었습니다.

사라 첸은 여러분의 수사 능력에 깊은 인상을 받았으며, 여러분을 보안 담당자로 추천하려 합니다. 내일은 '요새의 수호자'가 되어 프로젝트 피닉스의 인프라를 보호하고 미래의 위협으로부터 시스템을 지키는 역할을 맡게 될 것입니다!