[OS-008][중급] 로그로 장애 원인 좁히기 > IT 기술 공유

• 목록

[이번 수업]
로그는 프로그램과 운영체제의 사건 기록입니다. 장애가 나면 오류 문장보다 시각, 서비스, 심각도, 요청 식별자를 연결해야 합니다. 구조화 로그에서 오류의 앞뒤 흐름과 운영체제별 조회 방법을 익힙니다.

[선수지식]
OS-007의 프로세스와 자원 사용량, 파일 읽기와 기본 셸 명령을 알아야 합니다. 시간대도 복습하세요.

[학습목표]
1. 로그의 시간·출처·심각도·메시지를 구분할 수 있습니다.
2. 요청 식별자로 서로 관련된 사건을 묶을 수 있습니다.
3. 증거와 추측을 나눠 장애 원인 가설을 세울 수 있습니다.

[핵심개념]
구조화 로그는 time, level, service, event 같은 필드를 일정한 형식으로 기록합니다. 같은 작업에 request_id 같은 상관관계 식별자를 붙이면 여러 서비스의 기록을 이어 볼 수 있습니다. 시간에는 `+09:00`이나 `Z`처럼 시간대를 포함해야 다른 장비의 사건 순서를 비교하기 쉽습니다.

INFO는 정상 흐름, WARN은 주의, ERROR는 실패를 나타내지만 원인을 확정하지는 않습니다. `connection_timeout`은 데이터베이스 장애, 네트워크 지연, 연결 수 부족 등의 결과일 수 있습니다. 자원 사용량, 설정 변경, 배포 시각과 함께 검증해야 합니다.

분석 순서는 ① 증상과 최초 시각 기록 ② 시간대 통일 ③ 서비스와 요청 식별자로 범위 축소 ④ 오류 전후 확인 ⑤ 지표·설정·변경 이력으로 가설 검증입니다.

[따라하기]
아래를 log_trace.py로 저장하세요. 공백으로 나눈 다섯 필드를 읽어 첫 ERROR와 같은 요청만 출력합니다.

```python
raw = """2026-09-03T10:00:00+09:00 INFO api request_started r-100
2026-09-03T10:00:02+09:00 ERROR db connection_timeout r-100
2026-09-03T10:00:03+09:00 WARN api retry_scheduled r-100"""

records = [line.split() for line in raw.splitlines()]
error_id = next(row[4] for row in records if row[1] == "ERROR")
for time, level, service, event, request_id in records:
    if request_id == error_id:
        print(time, level, service, event)
```

Windows는 `py log_trace.py`, macOS와 Linux는 `python3 log_trace.py`로 실행합니다. 예상 결과는 다음과 같습니다.

```text
2026-09-03T10:00:00+09:00 INFO api request_started
2026-09-03T10:00:02+09:00 ERROR db connection_timeout
2026-09-03T10:00:03+09:00 WARN api retry_scheduled
```

실제 장비에서는 읽을 범위부터 줄입니다. systemd 기반 Linux는 `journalctl --since "10 minutes ago" -p warning --no-pager`로 최근 경고 이상을 봅니다. Windows PowerShell은 `Get-WinEvent -FilterHashtable @{LogName='System'; StartTime=(Get-Date).AddMinutes(-10)} -MaxEvents 20`을 사용합니다. macOS는 콘솔 앱에서 본인 Mac을 선택한 뒤 오류나 장애 유형을 검색합니다.

[흔한 실수]
첫째, 가장 눈에 띄는 ERROR를 근본 원인으로 단정합니다. 둘째, 서버마다 다른 시간대를 맞추지 않습니다. 셋째, 요청 식별자 없이 단어만 검색해 관계없는 사건을 섞습니다. 넷째, 로그 수준 변경이나 재시작을 기록하지 않아 증거를 혼동합니다.

[보안 주의]
본인 소유의 로컬·격리 환경 로그만 분석하세요. 비밀번호, 접근 토큰, 세션 값, 개인정보는 기록하지 말고 식별자는 마스킹합니다. 외부 입력의 줄바꿈과 제어 문자는 정규화해 가짜 로그 행을 막습니다. 원본은 읽기 전용으로 보존하고 복사본에서 조사하세요. 불필요한 관리자 권한과 공개 공유를 피하세요.

[직접 해볼 과제]
raw에 request_id가 r-200인 정상 기록 두 줄을 섞고 r-100 세 줄만 출력되는지 확인하세요. 이어 오류 시각 전후 5초와 같은 요청이라는 두 조건을 검사하도록 확장하세요. ‘DB 연결 수 부족’ 가설을 확인할 추가 지표도 하나 적으세요.

[확인문제]
1. 서로 다른 서비스의 로그를 한 요청으로 묶는 필드는 무엇인가요?
2. ERROR 한 줄만으로 근본 원인을 확정하면 안 되는 이유는 무엇인가요?
3. 여러 장비의 사건 순서를 비교할 때 시간대가 필요한 이유는 무엇인가요?

[다음 학습]
다음 NET-008에서는 프록시와 게이트웨이가 요청 경로에서 맡는 역할을 배웁니다.

[공식 참고 자료]
Syslog 메시지 형식 표준: https://www.rfc-editor.org/rfc/rfc5424
Linux journalctl 공식 설명서: https://www.freedesktop.org/software/systemd/man/latest/journalctl.html
Windows Get-WinEvent 공식 문서: https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.diagnostics/get-winevent?view=powershell-7.5
macOS 콘솔 공식 사용 설명서: https://support.apple.com/guide/console/cnsl1012/mac
안전한 애플리케이션 로깅 지침: https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html