도커 교과서 19장 도커를 이용한 로그 생성 및 관리

19장 도커를 이용한 로그 생성 및 관리

19.1 표준 에러 스트림과 표준 출력 스트림

• 도커 이미지는 애플리케이션 바이너리 및 의존성, 그리고 컨테이너를 시작할 때 도커가 실행할 프로세스에 대한 정보 등을 담은 파일 시스템의 스냅샷이다.
• 컨테이너를 시작할 때 실행되는 프로세스는 포어그라운드로 동작한다.
• 실행된 프로세스에서 생성한 로그 엔트리는 표준 출력 및 표준 오류 스트림으로 출력된다.
• 도커는 각 컨테이너의 stdout 과 stderr 스트림을 주시하며 스트림을 통해 출력되는 내용을 수집한다.

포어그라운드(Foreground) 란? 터미널에서 직접 명령을 내리고, 실행 결과를 바로 확인할 수 있는 상태. 즉, 터미널과 프로세스가 긴밀하게 연결되어 있는 상태.

$ docker container logs --tail 1 timecheck

Environment: DEV; version: 3.0; time check: 12:02.51

$ docker container inspect --format='{{.LogPath}}' timecheck

/var/lib/docker/containers/cffcd1c2efffae434bc7179bbfd55ab1de44792bff6c7476c7ad0188af540bb0/cffcd1c2efffae434bc7179bbfd55ab1de44792bff6c7476c7ad0188af540bb0-json.log

• 터미널 세션과 분리된 컨테이너와 종료된 컨테이너의 로그를 수집할 수 있도록 로그를 JSON 파일로 저장한다.
• 해당 JSON 파일은 도커가 직접 컨테이너와 동일한 생애주길르 갖도록 관리한다.
• 기본적으로 컨테이너마다 JSON 로그 파일 하나가 생성되며, 한 디스크 용량이 찰 때까지 이 파일의 크기가 증가한다.
• 엔진 설정으로 전체 설정 혹은 컨테이너 단위의 설정도 가능하다.

19.2 다른 곳으로 출력된 로그를 stdout 스트림에 전달하기

표준 로그 모델을 적용하지 못하는 경우

• 표준 로그 모델을 적용하기 어려운 애플리케이션도 있다.
  • ex) 출력 스트림으로 아무 내용을 출력하지 않는 애플리케이션
• 또한, 별도의 로그 프레임워크를 경유해 다른 곳에 로그를 생하는 경우가 있다.
  • ex) 리눅스의 syslog, 윈도우의 이벤트 로그
• 이들 모두 컨테이너 시작 프로세스에서 출력되는 로그가 없으므로 도커가 로그를 수집하지 못한다.

로그 유틸리티

• 표준 로그모델을 적용하지 못하는 경우에는 로그 전달용 유틸리티를 사용해야 한다.
• 로그 전달용 유틸리티는 로그 파일의 내용을 읽어 표준 출력으로 내보내 주는 역할을 한다.
• 컨테이너 시작명령에서 별도의 로그 전달용 유틸리티를 실행해야 한다.

로그 유틸리티 단점

• 로그 전달용 유티리티는 포어그라운드로 동작한다.
• 해당 프로세스가 종료되면 애플리케이션과 함께 컨테이너까지 종료될 수 있다.
• 또한, 애플리케이션이 오류로 종료되어도 포어그라운드로 동작 중인 유틸리티가 계속 실행되므로 컨테이너는 그대로 실행된다.
• 따라서, 헬스 체크를 적용하지 않는 컨테이너의 이상 상태를 감지할 수 없다.
• 마지막으로, 유틸리티의 경우 디스크 사용 효율이 떨어진다.

FROM diamol/dotnet-runtime AS base
...
WORKDIR /app
COPY --from=builder /out/ .
COPY --from=utility /out/ .

FROM base AS linux
CMD dotnet TimeCheck.dll & dotnet Tail.dll /logs timecheck.log

• 마지막 CMD 인스트럭션을 확인하면, dotnet 애플리케이션을 백그라운드로 실행하고, Tail 을 실행한다.
• tail 은 로그 파일을 감시하다가, 새로운 내용이 추가되면 stdout 스트림으로 전달해 컨테이너 로그로 수집되도록 하는 역할을 한다.

19.3 컨테이너 로그 수집 및 포워딩하기

• 통합 로깅 시스템으로는 오픈소스인 fluentd가 많이 사용된다.
• fluentd 는 통합 로깅 계층으로, 다양한 곳에서 생산되는 로그를 모으고, 필터링과 가공을 거쳐 다시 여러 대상으로 수집된 로그를 포워딩 하는 역할을 한다.

$ docker container run -d -p 24224:24224 --name fluentd -v "$(pwd)/conf:/fluentd/etc" -e FLUENTD_CONF=stdout.conf diamol/fluentd

$ docker container run -d --log-driver=fluentd --name timecheck5 diamol/ch19-timecheck:5.0

$ docker container logs --tail 1 fluentd

• fluentd 는 수집한 로그에 자체 메타데이터를 추가해서 저장한다.
• 메타데이터에는 컨테이너 ID 와 이름 등이 포함된다.
• fluentd 는 수집된 로그의 컨텐스트를 파악하기 위해 이러한 메타데이터가 필요하다.
• 수집된 로그는 중앙 데이터 스토어( elastic search ) 로 전송되고, 시각화를 제공하는 Kibana 와 함께 사용하는 것이 일반적이다.

EFK 스택을 사용할 때 장점

• Kibana
  • 모든 컨테이너의 로그 중에서 특정 키워드를 포함하는 로그를 검색하거나 시간 등을 기준으로 로그를 필터링 할 수 있다.
• Elastic Search
  • 수평 확장이 매우 용이하므로 운영 환경에서 생성되는 대량의 로그를 처리하는데 적합하다.
• Fluentd
  • 모든 컨테이너를 모아 한번에 볼 수 있기 때문에 로그를 편하게 확인할 수 있다.

Fluentd 로그에 태그 추가

services:
	accesslog:
		iamge: diamol/ch18-access-log
		logging:
			dirver: "fluentd"
			options:
				tag: "gallery.access-log.{{.ImageName}}"
		
	iotd:
		image: diamol/ch18-image-of-the-day
		logging:
			dirver: "fluentd"
			options:
				tag: "gallery.iotd.{{.ImageName}}"
				
	image-gallery:
		image: diamol/ch18-image-gallery
		logging:
			dirver: "fluentd"
			options:
				tag: "gallery.image-gallery.{{.ImageName}}"

• Fluentd 로그에 태그를 추가하기 위해서는 로깅 드라이버에 설정을 추가해야 한단.
• 고정된 이름을 사용하거나, 별도의 식별자를 외부에서 주입할 수 있다.
• 위와 같이 컴포넌트 이름과 이미지 이름을 연결한 태그의 경우 애플리케이션과 컴포넌트를 한눈에 알 수 있는 좋은 태그 예시이다.

이처럼, 중앙 집중식 로그 모델에 검색 가능한 데이터 스토어와 데이터 시각화 UI는 운영환경에서 필수적이다.

기본 로깅 드라이버는 도커 엔진 설정으로 지정하지만, 애플리케이션 매니페스트에서 로깅 시스템을 명시적을 지정하는게 좋다.

로깅 시스템에 대한 경험이 많지 않다면 Fluentd 를 사용한 EFK 스택을 추천한다.

클러스터 환경 확장이 어렵지 않으며, 적용이 간단하고, 메타데이터나 필터 기능을 통해 유형별 분리 및 저장이 가능하기 때문이다.

19.4 로그 출력 및 로그 컬렉션 관리하기

• 로그는 대량의 불필요한 데이터 저장과 문제 진단에 필요한 정보 확보 사이에서 필요한 정보들만 확인할 수 있어야 된다.
• 컨테이너에서 상세한 로그를 생산하면서 로그를 저장할 때는 필터링을 적용하여 균형을 잡을 수 있다.
• 로그 필터링은 fluentd 설정 파일에서 정의할 수 있다.

<match gallery.access-log.**>
	@type copy
	<store>
		@type stdout
	</store>
</match>

<match gallery.**>
	@type copy
	<store>
		@type elasticsearch
		...
	</store>
</match

• match 블럭을 이용하여 필터 파라미터와 태그가 일치하는 로그를 어떻게 처리할지 정의할 수 있다.
• 위의 설정은 access-log 는 컨테이너의 로그에서 확인하고, 나머지는 elasticsearch 에서 확인할 수 있도록 하는 설정이다.
• 이를 통해 각 컴포넌트마다 로그 저장소를 분리해서 저장하거나, 중요한 로그를 따로 추출하는 행위가 가능하다.
• 그러나, 로그는 유실될 수 있음을 항상 생각해야 한다.
• 설정 내용을 바꾸기 위해 fluentd 만 재배포하는 과정에서 컨테이너가 생성한 로그가 수집되지 못할 경우가 발생하기 떄문에 주의해야 한다.

19.5 컨테이너의 로깅 모델

• 도커의 로깅 모델은 매우 유연성이 뛰어나다.
• 이는 애플리케이션 로그를 컨테이너 로그로 보낼때만 적용된다.
• 만약, 애플리케이션이 따로 로그를 출력하지 않느나면 별도의 로깅 유틸리티를 통해 stdout 으로 출력해줘야 한다.
• EFK 스택을 사용할 경우 컨테이너 로그를 중앙 집중식 데이터베이스로 관리할 수 있다.
• 단일 머신에서도 무리 없이 동작하며, 운영 환경에 맞춰 수평 확장에도 용이하다.
• 어떤 조직은 fluentd 같은 도구를 사용하지 않고 스택을 구성하는것을 선호하기도 한다.
• 하지만, 이는 로그 유연성을 잃게되고, 애플리케이션이 소스 코드 및 특정 로깅 기술에 크게 의존하게 되므로 추천하지 않는다.