로그는 커널, 서비스, 애플리케이션 및 보안 구성 요소가 내보낸 이벤트를 기록합니다. 문제 해결과 감사에 유용하지만, 수집이 정상적으로 작동하고 타임스탬프를 올바르게 이해하며 관련 소스가 포함되어 있을 때만 의미가 있습니다.
로깅 · 레슨 1
시스템 로깅
리눅스 로그 소스, 수집기, 저장소 및 조회 도구가 서로 어떻게 연결되는지 알아봅니다.
로그 메시지의 흐름
로깅 경로는 몇 가지 서로 다른 부분으로 구성됩니다.
- 소스가 이벤트를 내보냅니다.
- 수집기가 이벤트를 받아 부가 정보를 추가합니다.
- 라우팅 및 보존 규칙이 저장 또는 전달 대상을 선택합니다.
- 조회 도구가 저장된 레코드를 검색합니다.
systemd 호스트에서는 일반적으로 systemd-journald가 서비스의 표준 출력, 커널 메시지, 저널 네이티브 메시지 또는 syslog 메시지를 수집합니다. rsyslog 같은 syslog 데몬도 메시지를 받아 전통적인 텍스트 파일에 쓰거나 다른 곳으로 전달할 수 있습니다. 애플리케이션이 자체 파일이나 외부 텔레메트리를 직접 관리하기도 합니다.
수신한 메시지를 어디에 저장하거나 전달할지 결정하는 구성 요소는 무엇입니까?
사용 가능한 로그 찾기
모든 호스트에 같은 파일이 있다고 가정하지 마십시오. 활성 로깅 서비스와 로컬 설정을 조사합니다.
$ systemctl --type=service --state=running | grep -E 'journal|syslog'
$ ls -la /var/log
$ journalctl --disk-usage
/var/log/syslog는 호환되는 라우팅을 사용하는 Debian 계열 시스템에서 흔하고, /var/log/messages는 다른 배포판에서 흔합니다. 저널만 사용하는 호스트에는 어느 파일도 없을 수 있습니다. 애플리케이션 문서와 유닛 설정에서 추가 대상을 확인할 수 있습니다.
/var/log/syslog 파일이 없다는 사실이 반드시 뜻하는 것은 무엇입니까?
저널 조회하기
전체 저널을 한꺼번에 출력하지 말고 범위가 제한된 쿼리부터 시작합니다.
$ journalctl -b -p warning
$ journalctl -u ssh.service --since '1 hour ago'
-b는 현재 부팅을 선택하고, -p는 우선순위로 필터링하며, -u는 유닛으로 필터링합니다. 유닛 이름과 보존된 부팅 기록은 호스트마다 다릅니다. journalctl --list-boots로 사용 가능한 부팅을 확인하고, 문제를 재현하면서 journalctl -f로 새 레코드를 추적합니다.
journalctl 쿼리를 현재 부팅으로 제한하는 옵션은 무엇입니까?
맥락 속에서 레코드 읽기
전통적인 syslog 형식의 한 줄은 다음과 같습니다.
Jan 27 07:41:32 icebox anacron[4650]: Job `cron.weekly' started
이 레코드는 타임스탬프, 호스트, 프로그램과 PID, 메시지를 담고 있습니다. 메시지 텍스트는 애플리케이션 출력이므로 구조화된 사실로 보장된다고 간주하지 마십시오. 시간대, 시계 동기화, 부팅 ID, PID 재사용 및 이벤트 직전과 직후 레코드를 확인합니다. 저널 필드는 렌더링된 텍스트만으로 얻는 것보다 강한 식별자를 제공할 수 있습니다.
로그에는 사용자 이름, 주소, 경로, 토큰 또는 기타 민감한 데이터가 포함될 수 있습니다. 최소 권한으로 접근하고, 외부로 내보내는 자료는 비식별화하며, 조사 중에는 원본과 타임스탬프를 보존하십시오.
로그 일부를 외부에 공유하기 전에 무엇을 해야 합니까?
레슨 완료
시스템 로깅 완료
이제 보편적인 저장 경로 하나를 가정하지 않고 리눅스 로그를 찾고 조회할 수 있습니다.
이벤트 소스, 수집기, 라우팅, 저장소 및 조회 도구를 구분합니다.
호스트의 활성 로깅 설정을 확인합니다.
유닛, 부팅, 시간 또는 우선순위로 범위를 제한한 저널 쿼리를 사용합니다.
맥락 속에서 레코드의 상관관계를 찾고 민감한 로그 데이터를 보호합니다.