11월 9일 얼쑤의 운영 구성을 정리하면서, 나중에 문제가 생기면 각 프로그램의 기록을 어디에서 읽을 수 있는지 확인했습니다. Docker에는 로그 여섯 종류를 보내도록 설정돼 있었습니다. 그런데 점검일의 저장 폴더에서 찾을 수 있는 건 네 종류뿐이었습니다. 빠진 두 종류는 프로그램이 실행 중이었는데도 사후에 기록을 읽을 곳이 없었습니다.
로그가 지나가는 세 곳을 확인했습니다
컨테이너에서 실행되는 프로그램은 일을 하다가 필요한 내용을 출력합니다. Docker의 로그 드라이버는 그 출력을 어디로 보낼지 정합니다. 얼쑤에서 확인한 여섯 프로그램은 모두 syslog 방식으로 로그를 보냅니다. 같은 서버에서 기록을 받는 rsyslog는 태그(출처 이름표)를 보고 어떤 기록을 파일로 남길지 결정합니다.
Docker 전송 설정 6종 → rsyslog 허용 4종 → 점검일 날짜별 파일 4종
| 확인한 곳 | 확인 방법과 결과 |
|---|---|
| 보내는 쪽 | 실행 중인 컨테이너의 로그 드라이버와 태그를 조회했습니다. 여섯 종류 모두 같은 수신기로 보내도록 설정돼 있었습니다. |
| 받는 쪽 | 수신 설정에는 네 태그만 파일에 쓰도록 적혀 있었습니다. 빠진 두 태그는 뒤의 처리 규칙으로 넘어가지 않도록 되어 있었습니다. |
| 저장된 곳 | 점검일에 내용이 들어 있는 날짜별 파일은 네 종류였습니다. 파일이 있는지와 비어 있지 않은지를 확인했습니다. |
세 곳의 이름표를 맞춰 보니 파일이 없던 두 종류가 수신 규칙에서 빠진 두 종류와 같았습니다. 전송 설정은 목적지를 보여 주고, 수신 규칙은 무엇을 보관하는지 보여 줍니다. 그날 비어 있지 않은 파일이 있다는 관측은 해당 종류의 기록이 실제로 남았다는 근거입니다. 이번에는 설정과 파일 정보만 조회했기 때문에 개별 메시지가 모두 도착했는지는 확인할 수 없습니다.
docker logs는 어디를 읽을까요?
Docker는 json-file이나 local처럼 같은 서버에 저장하는 드라이버의 기록을 docker logs로 읽을 수 있습니다. 다른 프로그램으로 보내는 드라이버는 Docker가 읽기용 복사본을 따로 보관할 수 있습니다. 드라이버 자체가 읽기를 지원하지 않고 이 복사본도 꺼져 있으면 docker logs로 읽을 수 없습니다. Docker 공식 문서 · 원격 드라이버와 로컬 캐시
점검 당시 여섯 컨테이너는 Docker의 읽기용 복사본을 꺼 둔 상태였습니다. 파일이 없던 컨테이너 한 곳에서 출력 줄 수를 0으로 지정해 읽기 지원 여부를 확인하니, 드라이버가 읽기를 지원하지 않는다는 응답이 왔습니다. 팀의 사용 안내에 docker logs가 적혀 있더라도, 실행 중인 컨테이너가 어떤 드라이버를 쓰는지부터 확인해야 하는 이유입니다.
docker inspect --format '{{.HostConfig.LogConfig.Type}}' CONTAINER_NAME
CONTAINER_NAME에 컨테이너 이름을 넣으면 해당 컨테이너의 로그 방식이 나옵니다. 이 명령은 기록의 내용이나 저장 성공 여부까지 확인하지는 않습니다. syslog가 나온다면 수신 규칙과 최종 파일을 차례로 봅니다. Docker 공식 문서 · 컨테이너별 로그 드라이버 확인
녹음을 냈는데 채점 결과가 없다면
가상의 사례입니다. 사용자가 녹음을 제출했는데 결과 화면에 점수가 없다고 가정해 봅시다. 어떤 일이 있었는지는 세 곳의 기록을 이어 읽어야 알 수 있습니다.
- Nginx에서는 제출 시각에 요청이 서버 입구까지 왔는지 확인합니다. 시각과 요청 경로를 대조해 찾을 범위를 좁힙니다.
- 백엔드와 채점 AI에서는 같은 연습 회차와 녹음 시도 번호를 찾아 처리 결과를 봅니다. AI가 HTTP 200으로 답했어도 답 내용에는 ‘무음’이나 ‘녹음이 너무 짧음’ 같은 채점 실패가 들어 있을 수 있습니다.
- 제품 데이터베이스에서는 그 시도의 상태와 점수가 실제로 저장됐는지 확인합니다. AI가 성공으로 처리했는데 점수가 없다면, 같은 시도의 백엔드 기록에서 저장 오류가 있었는지 봅니다.
장애가 난 뒤에야 이 세 기록을 찾으면, 어느 단계까지 기록이 남는지 파악하는 데 시간을 쓰게 됩니다. 새 컨테이너를 추가할 때는 보내는 태그, 받는 규칙, 운영자가 읽을 위치를 한 번에 대조해 둘 수 있습니다. 수신 규칙을 바꾼 뒤에는 테스트 기록 한 줄이 날짜별 파일에 나타나는지, 그 파일에 접근 권한과 보관 기간이 적용되는지까지 확인하면 됩니다. 후속 작업에서는 빠진 두 태그를 수신 규칙과 보관 기한을 적용하는 목록에 추가했습니다. 적용 뒤에는 두 종류의 새 기록과 기존 웹 기록이 같은 저장 경로에 남는 것을 확인했습니다. 이 확인으로 기록을 찾아볼 수 있는 경로가 생겼습니다.

댓글
댓글과 반응은 GitHub 계정으로 로그인해 남길 수 있어요.