로그 조사관

소개

LabEx Corporation 에서 근무한 지 3 일째 되는 날, Project Phoenix 에 큰 문제가 발생했습니다! 사무실에 도착하니 Sarah Chen 과 개발팀이 긴급 대응에 들어가 있었습니다. 어제 정리했던 애플리케이션이 첫 번째 대규모 테스트 단계에서 심각한 오류를 일으킨 것입니다.

모니터링 시스템에는 긴급 알림이 쏟아지고, 사용자는 애플리케이션 장애를 신고하고 있으며, 배포 파이프라인은 완전히 멈춰 있습니다. Sarah 가 난처한 표정으로 당신을 바라봅니다. 선임 DevOps 엔지니어는 병가 중이고 프로젝트 마감일은 빠르게 다가오고 있습니다.

Sarah 는 사고 보고서를 건네며 말합니다. "이번 일에는 최고의 조사관이 필요합니다. 파일을 정리할 때 보여 준 체계적인 접근 방식이 정말 큰 도움이 됐어요. 이제 그 꼼꼼한 사고방식으로 이 문제를 해결해야 합니다."

당신의 임무는 Project Phoenix 서버를 자세히 조사하고, 로그와 구성 파일을 분석해 장애의 근본 원인을 찾아내는 것입니다. 고급 Linux 명령줄 도구를 사용해 단서를 하나씩 맞추고, 팀이 힘들게 구축한 애플리케이션의 안정성을 되찾습니다. Project Phoenix 의 미래와 어쩌면 TechNova 에서의 당신의 경력까지, 모두 당신의 탐정 능력에 달려 있습니다!

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

조사관으로서 가장 먼저 할 일은 Project Phoenix 의 애플리케이션 로그 파일을 확인하는 것입니다. 애플리케이션 로그는 ~/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라는 단어를 포함해야 합니다.

시스템 부팅 메시지 조사

애플리케이션 오류는 더 근본적인 하드웨어 또는 커널 수준 문제의 증상일 수 있습니다. 이러한 문제를 확인하기 좋은 위치는 커널 링 버퍼입니다. 커널 링 버퍼에는 시스템 부팅 과정과 드라이버 작업에서 발생한 메시지가 들어 있습니다.

작업

• 시스템 커널 메시지에서 fail 또는 error와 관련된 줄을 확인합니다.
• 조사 결과를 ~/project/boot_issues.txt 파일에 저장합니다.

요구 사항

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

힌트

• dmesg 명령은 커널 메시지를 표시합니다. 출력 결과를 다른 명령으로 파이프해 필터링할 수 있습니다.
• 파이프 연산자 |는 한 명령의 출력을 다른 명령의 입력으로 전달합니다.
• 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 구성 파일을 확인해 현재 설정을 살펴봅니다. 작업자 프로세스 수가 너무 적은 것처럼 구성이 잘못되면 성능 병목이 발생하고 부하가 걸릴 때 애플리케이션 장애로 이어질 수 있습니다.

작업

• ~/project/config/nginx.conf에 있는 웹 서버 구성 파일을 검색합니다.
• worker_processes 지시어가 포함된 줄을 찾습니다.
• 첫 번째 단계에서 만든 ~/project/error_report.txt 파일에 이 줄을 추가합니다.

요구 사항

• 입력 파일은 ~/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 개입니다.

스테이징 및 프로덕션 구성 파일 비교

프로덕션 문제의 일반적인 원인은 스테이징 환경과 프로덕션 환경의 차이입니다. 작은 구성 차이 때문에 스테이징에서는 정상적으로 작동하는 기능이 프로덕션에서는 실패할 수 있습니다. 두 환경의 애플리케이션 구성 파일을 비교해 차이점을 찾아봅니다.

작업

• 스테이징 구성 파일 ~/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 키, 기능 플래그, 타임아웃 값을 사용한다는 사실을 확인할 수 있습니다.

서버 간 디렉터리 일관성 확인

구성 차이는 중요한 단서입니다! 프로덕션 서버에 스테이징 서버에는 있는 중요한 파일이 일부 없을 수도 있습니다. 배포 실패 때문에 발생했을 가능성이 있습니다. 서로 다른 두 서버의 파일 구조를 나타내는 디렉터리를 비교해 이 상황을 재현해 봅니다.

작업

• 두 디렉터리가 있습니다. /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로 디렉터리도 비교할 수 있습니다.
• 디렉터리 안의 모든 파일을 비교하려면 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

이 출력은 첫 번째 디렉터리인 server1_files(스테이징 서버) 에 asset2.js가 있지만 두 번째 디렉터리인 server2_files(프로덕션 서버) 에는 없다는 뜻입니다. 스테이징을 먼저, 프로덕션을 두 번째로 비교하면 프로덕션에 없는 파일을 쉽게 확인할 수 있으며, 이러한 파일이 애플리케이션 장애의 원인일 수 있습니다.

요약

훌륭한 조사였습니다! Project Phoenix 의 심각한 장애 원인을 성공적으로 찾아내고, Sarah Chen 과 개발팀이 문제를 해결하는 데 사용할 수 있는 구체적인 정보를 제공했습니다.

체계적으로 조사하면서 다음과 같은 문제 해결 명령을 익혔습니다.

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

체계적인 로그 분석으로 Project Phoenix 를 잠재적으로 치명적인 장애에서 구했습니다. 이제 개발팀은 발견된 구성 불일치와 누락된 배포 파일을 수정할 방향을 명확히 알게 되었습니다.

Sarah Chen 은 당신의 조사 능력에 깊은 인상을 받아 보안 직무를 추천하기로 했습니다. 내일은 Fortress Guardian 이 되어 Project Phoenix 의 인프라를 보호하고 앞으로 발생할 위협에 대비합니다!