예시 답변 1
약 70초
syslog + journalctl로 장애 원인 추적 — 로그 레벨·타임스탬프 순서 따라가기
학교 실습 서버가 갑자기 응답이 없어지는 상황을 팀원과 함께 분석한 적이 있습니다. 처음엔 어디서 봐야 할지 몰라서 로그 파일을 tail로 그냥 보다가 양이 너무 많아서 오히려 혼란스러웠습니다. 그때 journalctl에서 타임스탬프를 기준으로 범위를 좁히고, 에러 레벨만 필터링하는 방식을 써봤습니다. 결국 디스크 용량 초과로 특정 서비스가 쓰기 실패를 반복하다가 멈춘 것이었는데, 처음에 CPU와 메모리만 봤다가 디스크를 한참 뒤에 확인한 게 실패였습니다. 이후로 로그 분석 전에 CPU·메모리·디스크·네트워크 네 가지 리소스를 빠르게 확인하는 순서를 먼저 밟게 됐습니다. 개인 서버에서 혼자 할 때는 이 순서 하나가 시간을 크게 줄여줬습니다.
이 결의 특징
실습 서버에서 journalctl로 로그를 읽다가 서비스 재시작 전 오류 메시지가 패턴을 이루며 반복된 것을 발견하고 단발성 오류와 반복 패턴 오류를 구분해 후자를 우선 처리하는 방식을 익힌 흔적이 있습니다. 로그에서 패턴을 읽는 감각이 관찰자 눈에 남는 결이 자주 보입니다.
이 결이 통하는 자리
반복 패턴 오류 우선 처리 기준이 journalctl 실습에서 나온 것으로 연결될 때 통합니다. 단발성과 패턴성 오류를 구분하는 시각이 로그 분석 감각과 연결된 자리에서 면접관의 꼬리질문이 줄어드는 결이 보입니다.