원격 저장소에 로그가 남아 있는데 docker logs에서 오래된 기록이 보이지 않으면 dual logging의 로컬 캐시 범위를 확인하세요. 원격 보존 기간과 로컬 조회 캐시는 서로 다른 저장 경로입니다.
적용 환경: Docker Engine 컨테이너; 애플리케이션 출력과 실제 컨테이너 로깅 설정을 확인할 권한 필요. 자료 확인일: 2026-10-26. 문서 기반 안내이며 실제 운영 시험 결과가 아닙니다.
1. 원인: 원격 저장과 로컬 조회는 다름
Docker Engine은 로그 읽기를 지원하지 않는 드라이버를 사용할 때 dual logging을 자동으로 활성화합니다. local 드라이버를 캐시로 사용해 최근 로그를 읽게 하지만 이 캐시가 원격 저장소 전체를 조회하는 창은 아닙니다.
기본 캐시는 컨테이너당 압축 전 20MB 파일 최대 5개로 회전합니다. 일정 일수를 보존한다는 의미가 아니므로 출력량이 많으면 조회 가능한 시간 범위가 짧아집니다. 실제 설정이 기본값과 같은지 먼저 확인하세요.
2. 해결: 두 경로를 나란히 기록
CONTAINER를 실제 컨테이너 이름으로 바꾸고 조회 권한이 있는 호스트에서 실행합니다. inspect 전체에는 민감 정보가 포함될 수 있어 필요한 로깅 항목만 확인합니다.
docker inspect --format '{{json .HostConfig.LogConfig}}' CONTAINER
docker logs --tail 100 --timestamps CONTAINER
| 경로 | 확인할 내용 |
| 원격 저장소 | 보존 정책·수집 시각·조회 필터 |
| 로컬 캐시 | 활성 여부·파일 크기·개수 |
| 현재 컨테이너 | 실제 드라이버와 적용 옵션 |
| 대표 이벤트 | 양쪽에서 같은 시각과 내용인지 |
local·json-file·journald처럼 읽기를 지원하는 드라이버에서는 dual logging 도입 전후의 읽기 기능 차이가 없습니다. 모든 드라이버에 별도 캐시가 추가된다고 가정하지 마세요.
3. 확인: 같은 시험 이벤트를 양쪽에서 조회
민감 정보 없는 승인된 시험 환경에서 식별 가능한 요청을 한 번 실행합니다. 컨테이너·요청 시각·시간대를 적고 로컬 조회와 원격 검색 결과를 비교합니다. 원격으로 보냈다는 앱 로그만으로 실제 수집 성공을 확정하지 않습니다.
로컬 조회에서 과거 기록이 없어도 원격에 남아 있는지 별도로 확인해야 합니다. 반대로 캐시에서 보이는 것만으로 원격 수집과 장기 보존이 정상이라고 판정할 수 없습니다. 장애 조사에 필요한 기간은 원격 저장 정책과 실제 수집 상태로 검증하세요.
4. 주의와 FAQ
캐시를 늘리면 장기 보존이 해결되나요? 호스트 저장 공간과 컨테이너 수에 미치는 영향도 검토해야 합니다. 로컬 캐시는 별도 백업이나 원격 보존 증명이 아닙니다.
원격에 안 보이면 캐시가 대신 보장하나요? 공식 문서에는 로그 드라이버 쓰기 실패 시 캐시 쓰기도 실패할 수 있다는 제한이 있습니다. 캐시를 독립적인 무손실 안전망으로 가정하지 마세요.
설정 변경은 기존값을 보존하고 시험 컨테이너에서 먼저 검증합니다. 운영 로그 파일 삭제나 즉시 컨테이너 재생성을 이 점검의 첫 단계로 실행하지 않습니다.
공식 출처와 관련 글
Docker 로그 확인과 용량 관리: compose logs부터 로그 로테이션까지
서비스에 오류가 생겼을 때 로그를 열면 너무 많은 내용이 쏟아지고, 정작 필요한 시간의 기록은 찾기 어려울 수 있습니다. 반대로 로그가 계속 쌓여 서버 디스크를 차지하는 문제도 있습니다.
papa-titipo.com

'소프트웨어개발' 카테고리의 다른 글
| git add를 취소하고 파일은 남기려면: restore --staged 확인 순서 (0) | 2026.10.27 |
|---|---|
| CloudWatch Logs 보존 기간을 줄이기 전: 삭제 시점과 복구 한계 확인 (0) | 2026.10.27 |
| S3 파일은 없는데 용량이 남을 때: 미완료 멀티파트 업로드 점검 (0) | 2026.10.27 |