로그 읽기: 사건·시간·주체 연결

01개념과 구성 요소

• 로그프로그램·커널·장비가 특정 사건과 상태를 기록한 자료다. 화면의 한 줄이 전체 행위와 동일하지는 않다.
• 연결 필드시각·호스트·프로그램·프로세스·주체·대상·결과·요청 식별자가 사건 관계를 만든다.
• 저장 경로생성 프로그램, journal·파일, 수집기, 중앙 저장소를 나누어 읽는다.

02서비스 재시작 원인을 로그로 좁히는 순서

1. 현상과 시간 정하기어느 서비스가 언제부터 영향을 받았는지 범위를 정하고 시간대·시계 차이를 확인한다.
2. 서비스 기록 조회unit 로그에서 종료 코드·재시작·실패 원인을 읽고 관련 PID·시각을 연결한다.
3. 하위 원인 추적같은 시점의 커널·저장 장치·인증·감사 기록을 대조하여 I/O timeout 같은 선행 조건을 찾는다.
4. 인과와 동시성 구분장치 지연→앱 정체→종료→재시작의 연결 근거를 확인한다. 가까운 시각의 두 줄만으로 원인을 확정하지 않는다.
5. 원본·누락 점검원본과 수집 지연·중복·회전 상태를 확인하여 보이지 않는 기록이 실제 미발생인지 수집 누락인지 구분한다.

03로그 생성과 저장 경로는 별개

• 생성과 저장애플리케이션·인증·커널·서비스 관리자·네트워크 장비는 서로 다른 사건을 기록한다. 같은 사건이 systemd journal과 rsyslog 파일에 동시에 나타날 수 있어 파일 수와 사건 수가 같지 않다.
• 실제 경로실제 service 설정·journal·파일 라우팅을 따라 로그 생성과 저장 위치를 연결한다.
• 배포판별 파일RHEL 계열의 /var/log/messages, Debian 계열의 /var/log/syslog는 전통적인 일반 로그 경로다. journald-only 환경에는 이 파일이 없을 수 있다.
• 파일 부재파일이 없다는 사실만으로 로그 기능이 없다고 단정하지 않고 journal 저장과 전달 구성을 함께 본다.

04텍스트 한 줄의 구조

• 텍스트 필드전통적 syslog 형태는 시각·호스트·프로그램[PID]·메시지로 읽을 수 있다. 형식에 따라 연도·timezone이 없거나 메시지 안에 추가 구조가 있다.
• PIDPID는 프로세스 실행을 구분하는 단서지만 재부팅·시간 경과 뒤 재사용될 수 있으므로 host·boot·시각 문맥이 필요하다.
• 구조화 정보앱의 자유 문자열과 journal의 구조화 필드를 구분하면 grep error보다 정확하게 범위를 좁힐 수 있다. 어떤 프로그램은 오류를 WARNING에 기록하고 정상 시험 메시지에 error라는 단어를 넣을 수 있다.
• 단어와 문맥문자열 한 단어는 의미 판정의 시작일 뿐이다.

Oct 12 10:00:00 lab-host systemd[1]: training.service: Main process exited, code=exited, status=1/FAILURE

시각: Oct 12 10:00:00
호스트: lab-host
기록 주체: systemd, PID 1
대상 서비스: training.service
결과: 프로세스가 종료 코드 1로 종료

원리를 설명하는 가상 학습 예시입니다.

05journal의 구조화된 조회

• Journal 필드journal은 메시지 외에 unit·priority·boot·프로세스 등 문맥 필드를 보관할 수 있다. -u로 서비스를 고르고 -k로 커널 메시지를 보며 시간 범위를 정하면 관련 기록을 좁힐 수 있다.
• 조회 조건같은 시간에 여러 서비스가 재시작되는 원인을 찾을 때는 단일 unit만 보면 상위 원인을 놓칠 수 있다.
• 영속성journald의 영속성은 Storage 설정과 /var/log/journal 같은 저장 위치에 영향을 받는다. 재부팅 전 자료가 필요한데 휘발성 저장만 사용하면 사건 경로가 끊길 수 있다.
• 파일 검증 한계journal 파일 검증은 구조·무결성 점검의 한 도구이며 모든 침해나 로그 누락을 자동 판별하는 기능으로 확대하지 않는다.

journalctl -u training.service --since "1 hour ago"
journalctl -k --since "1 hour ago"
journalctl -p warning..alert --since "1 hour ago"
journalctl --disk-usage

현재 시스템의 로그를 읽는 예입니다. 실제 unit은 환경에 맞게 지정합니다.

06I/O 오류에서 재시작 반복까지

• I/O와 재시작저장 장치 timeout은 애플리케이션 I/O 정체, watchdog 또는 서비스 종료, 재시작 반복으로 이어질 수 있다. 마지막 systemd restart 메시지만 보면 서비스 자체 결함으로 오해할 수 있지만 앞선 커널 I/O 기록이 공통 원인일 수 있다.
• 시스템 지표OOM·read-only remount·disk full도 여러 서비스의 동시 실패를 만들 수 있다. 종료 코드·signal·restart counter와 커널 시각을 연결하면 “무엇이 종료되었는가”와 “왜 영향을 받았는가”를 나눌 수 있다.
• 인과 검증원인과 결과가 시간상 가깝다는 사실만으로 인과가 확정되는 것은 아니므로 관련 자원 상태도 대조한다.

07인증 로그와 감사 로그

• 인증 기록인증 실패는 계정·접속지·인증 방식·대상 서비스와 함께 해석한다. 한 사람의 로그인 동작이 여러 PAM·SSH 기록을 만들 수 있어 실패 줄 수를 시도 횟수로 곧바로 환산하지 않는다.
• 로그인 이후인증 성공 기록도 그 뒤의 모든 파일 접근이 허가되었다는 뜻은 아니다.
• 감사 식별자감사 자료는 행위·객체·주체·성공 여부를 더 자세히 다룰 수 있다. 현재 uid와 원래 로그인 사용자 auid가 다르면 권한 전환의 문맥을 설명할 수 있다.
• Serial 연결여러 감사 레코드가 같은 serial로 하나의 이벤트를 구성할 수 있으므로 줄 단위 경보가 사건을 분해·중복하지 않도록 한다.

08시간 동기화·수집 지연·순서

• 발생 시각로그 시각은 사건 생성 장치의 시계에 의존한다. NTP step·timezone 설정·연도 추정 문제가 있으면 실제 순서가 뒤바뀔 수 있다.
• 수집 지연수집 시각과 발생 시각을 함께 저장하면 전송 지연과 시계 차이를 조사할 근거가 생긴다.
• 정렬 한계같은 파일의 줄 순서도 여러 프로세스 버퍼링과 비동기 출력 때문에 모든 실제 실행 순서를 완벽하게 보장하지 않는다. request ID·transaction ID·process 관계가 시간보다 강한 연결 키가 될 수 있다.
• 시간대 정규화여러 소스를 타임라인으로 합칠 때는 추정 오차를 남긴다.

12원본 보존·중복·로그 주입

• 원본 보존정규화된 필드와 원본 메시지를 연결하면 파서 오류를 다시 검토할 수 있다. 단, 비밀번호·세션 토큰 등 불필요한 비밀을 처음부터 로깅하지 않는 것이 후처리 마스킹보다 중요하다.
• 로그 주입사용자가 입력한 줄바꿈·제어 문자가 새 로그처럼 보이게 하면 기록의 구조가 훼손될 수 있다.
• UI 출력 경계SIEM 화면에서도 메시지를 HTML로 해석하지 않고 안전하게 표시해야 로그 안의 문자열이 코드가 되지 않는다. 로컬과 원격 보관은 서로 다른 실패에 대비하지만 같은 사건의 중복 수집을 판별할 식별·출처 정보가 필요하다.
• 회전·중복회전·보존 정책이 달라 원본만 먼저 삭제되면 검색 결과에서 증거로 돌아갈 수 없게 된다.

13단계별로 누락 위치 찾기

• 전달 경로메시지가 애플리케이션에서 생성되었는지, journal이나 파일에 남았는지, 수집기가 읽었는지, 중앙에서 파싱되었는지, 시간 필터 안에 있는지를 차례로 연결한다. 중앙 검색 결과가 없다는 사실만으로 생성 장치가 기록하지 않았다고 결론 내리지 않는다.
• 단계별 건수source별 마지막 이벤트 시각, 파싱 실패, 읽기 권한, 파일 회전, 큐, 저장 오류는 모두 로그 경로의 상태다. 관제는 로그 안의 이상만 찾는 일이 아니라 로그가 없어진 이유를 관찰하는 일도 포함한다.