Docker 로깅과 모니터링 완벽 가이드

Docker 컨테이너 환경에서 로그를 효율적으로 수집하고 시스템 리소스를 모니터링하는 방법을 다룹니다. 로그 드라이버부터 Prometheus 연동까지 실무에서 바로 적용할 수 있는 내용을 담았습니다.

---

목차

1. Docker 로그 드라이버
2. JSON-file vs Syslog
3. docker stats로 리소스 확인
4. cAdvisor 활용
5. Prometheus 연동 기초
6. 로그 중앙화 전략

---

1. Docker 로그 드라이버

김개발 씨는 어느 날 운영 서버에서 장애가 발생했다는 연락을 받았습니다. 급하게 서버에 접속해 로그를 확인하려는데, 컨테이너가 이미 재시작되어 로그가 모두 사라진 후였습니다.

"도대체 로그는 어디로 간 거지?"

로그 드라이버는 Docker 컨테이너에서 발생하는 로그를 어디에, 어떻게 저장할지 결정하는 메커니즘입니다. 마치 우체부가 편지를 어느 주소로 배달할지 결정하는 것과 같습니다.

로그 드라이버를 제대로 설정하면 컨테이너가 사라져도 로그는 안전하게 보관됩니다.

다음 코드를 살펴봅시다.

# 현재 Docker의 기본 로그 드라이버 확인
docker info --format '{{.LoggingDriver}}'

# 컨테이너 실행 시 로그 드라이버 지정
docker run -d \
  --log-driver=json-file \
  --log-opt max-size=10m \
  --log-opt max-file=3 \
  --name my-app \
  nginx:latest

# 실행 중인 컨테이너의 로그 드라이버 확인
docker inspect --format '{{.HostConfig.LogConfig.Type}}' my-app

김개발 씨는 입사 6개월 차 주니어 DevOps 엔지니어입니다. 컨테이너 환경에서 애플리케이션을 운영하던 어느 날, 새벽에 장애 알림이 울렸습니다.

부랴부랴 서버에 접속해 로그를 확인하려 했지만, 컨테이너는 이미 자동으로 재시작된 후였습니다. 선배 개발자 박시니어 씨에게 도움을 요청했습니다.

"시니어님, 컨테이너가 재시작되면 로그가 다 사라지나요?" 박시니어 씨가 웃으며 대답했습니다. "로그 드라이버 설정을 안 했구나?" 그렇다면 로그 드라이버란 정확히 무엇일까요?

쉽게 비유하자면, 로그 드라이버는 마치 우체국의 배송 시스템과 같습니다. 우리가 편지를 보내면 일반 우편, 등기, 퀵서비스 중 어떤 방법으로 보낼지 선택하듯이, Docker도 로그를 어디로 보낼지 선택할 수 있습니다.

로컬 파일에 저장할 수도 있고, 원격 서버로 전송할 수도 있습니다. 로그 드라이버가 없던 시절에는 어땠을까요?

개발자들은 애플리케이션 내부에서 직접 로그 파일을 관리해야 했습니다. 컨테이너가 삭제되면 그 안의 모든 데이터도 함께 사라졌습니다.

더 큰 문제는 여러 컨테이너의 로그를 한 곳에서 보기가 매우 어려웠다는 것입니다. 마이크로서비스 환경에서 수십 개의 컨테이너를 운영한다면, 로그를 추적하는 것만으로도 하루가 다 지나갈 정도였습니다.

바로 이런 문제를 해결하기 위해 Docker는 플러그인 방식의 로그 드라이버를 도입했습니다. Docker는 json-file, syslog, journald, gelf, fluentd, awslogs, splunk 등 다양한 로그 드라이버를 지원합니다.

기본값은 json-file이며, 로그를 JSON 형식으로 호스트의 파일 시스템에 저장합니다. 상황에 따라 적합한 드라이버를 선택하면 됩니다.

위의 코드를 살펴보겠습니다. 먼저 docker info 명령으로 현재 시스템의 기본 로그 드라이버를 확인합니다.

대부분의 환경에서 json-file이 기본값입니다. 다음으로 docker run 명령에서 --log-driver 옵션을 사용해 드라이버를 지정합니다.

--log-opt 옵션으로 파일 크기와 개수 제한을 설정할 수 있습니다. 실제 현업에서는 어떻게 활용할까요?

소규모 프로젝트에서는 json-file 드라이버로 충분합니다. 하지만 대규모 서비스에서는 fluentd나 awslogs 같은 드라이버로 로그를 중앙 집중화합니다.

특히 AWS 환경에서는 awslogs 드라이버를 사용해 CloudWatch로 로그를 직접 전송하는 경우가 많습니다. 하지만 주의할 점도 있습니다.

초보 개발자들이 흔히 하는 실수 중 하나는 로그 파일 크기 제한을 설정하지 않는 것입니다. 이렇게 하면 디스크가 가득 차서 서버 전체가 멈출 수 있습니다.

반드시 max-size와 max-file 옵션을 설정하세요. 다시 김개발 씨의 이야기로 돌아가 봅시다.

박시니어 씨의 설명을 들은 김개발 씨는 바로 daemon.json 파일에 기본 로그 드라이버 설정을 추가했습니다. "이제 컨테이너가 재시작되어도 로그를 볼 수 있겠네요!"

실전 팁

💡 - daemon.json에서 기본 로그 드라이버를 설정하면 모든 컨테이너에 일괄 적용됩니다

• 로그 파일 용량 제한은 필수입니다. max-size=10m, max-file=3 정도가 적당합니다

---

2. JSON-file vs Syslog

김개발 씨가 로그 드라이버를 설정하려고 문서를 읽다가 고민에 빠졌습니다. "json-file이랑 syslog 중에 뭘 써야 하지?" 둘 다 로그를 저장하는 건 같은데, 어떤 차이가 있는 걸까요?

json-file은 Docker의 기본 로그 드라이버로, 로그를 JSON 형식의 파일로 호스트에 저장합니다. syslog는 유닉스 계열 시스템의 표준 로깅 시스템으로, 로그를 syslog 데몬에 전송합니다.

마치 개인 일기장에 기록하는 것과 공용 게시판에 게시하는 것의 차이와 같습니다.

다음 코드를 살펴봅시다.

# json-file 드라이버 사용 (기본값)
docker run -d \
  --log-driver=json-file \
  --log-opt max-size=50m \
  --log-opt max-file=5 \
  --log-opt labels=production \
  --name web-json nginx:latest

# syslog 드라이버 사용
docker run -d \
  --log-driver=syslog \
  --log-opt syslog-address=udp://192.168.1.100:514 \
  --log-opt syslog-facility=daemon \
  --log-opt tag="{{.Name}}" \
  --name web-syslog nginx:latest

# json-file 로그 직접 확인
cat /var/lib/docker/containers/<container-id>/<container-id>-json.log

김개발 씨는 로그 드라이버 종류를 조사하다가 가장 많이 언급되는 두 가지를 발견했습니다. json-file과 syslog였습니다.

문서를 읽어봐도 둘 다 로그를 저장한다는 점은 같은데, 어떤 상황에 무엇을 써야 하는지 감이 오지 않았습니다. 박시니어 씨에게 물어보자 이렇게 설명해 주었습니다.

"일단 가장 큰 차이는 로그가 저장되는 위치야." json-file 드라이버를 비유하자면 개인 일기장과 같습니다. 로그가 Docker 호스트의 로컬 파일 시스템에 JSON 형식으로 저장됩니다.

/var/lib/docker/containers 디렉토리 아래에 컨테이너별로 로그 파일이 생성됩니다. 가장 큰 장점은 docker logs 명령으로 바로 조회할 수 있다는 것입니다.

별도의 설정 없이도 즉시 사용할 수 있어 개발 환경이나 소규모 운영 환경에 적합합니다. 반면 syslog 드라이버는 공용 게시판에 가깝습니다.

로그가 시스템의 syslog 데몬으로 전송됩니다. 로컬 syslog뿐만 아니라 원격 syslog 서버로도 전송할 수 있습니다.

기존에 syslog 기반의 로깅 인프라가 구축된 환경에서는 Docker 로그를 기존 시스템과 쉽게 통합할 수 있습니다. 그렇다면 언제 무엇을 선택해야 할까요?

개발 환경이나 단일 서버에서 운영하는 경우에는 json-file이 적합합니다. docker logs 명령으로 실시간 로그를 바로 확인할 수 있고, 별도의 인프라가 필요 없습니다.

로그 파일을 직접 파싱하기도 쉽습니다. 반면 여러 서버에 분산된 컨테이너의 로그를 한 곳에서 모아야 하거나, 기존 syslog 인프라가 있는 경우에는 syslog가 유리합니다.

특히 보안 감사를 위해 로그를 중앙 서버에 보관해야 하는 금융권 같은 환경에서 많이 사용합니다. 위의 코드를 살펴보면, json-file은 max-size로 파일 크기를, max-file로 파일 개수를 제한합니다.

syslog는 syslog-address로 원격 서버 주소를 지정하고, tag 옵션으로 로그에 컨테이너 이름을 포함시킵니다. 주의할 점이 있습니다.

syslog 드라이버를 사용하면 docker logs 명령이 작동하지 않습니다. 로그가 syslog로 전송되기 때문입니다.

이 점을 모르고 syslog를 설정한 후 docker logs가 안 된다고 당황하는 경우가 많습니다. 김개발 씨는 현재 단일 서버에서 개발 중이므로 json-file을 선택했습니다.

나중에 서비스가 커지면 syslog나 다른 중앙 집중형 드라이버로 전환하기로 했습니다.

실전 팁

💡 - 개발 환경에서는 json-file, 대규모 운영 환경에서는 syslog나 fluentd를 고려하세요

• syslog 사용 시 docker logs 명령이 작동하지 않는다는 점을 기억하세요

---

3. docker stats로 리소스 확인

어느 날 김개발 씨가 운영하는 서버가 갑자기 느려졌습니다. CPU 사용률이 100%를 찍고 있었는데, 어떤 컨테이너가 문제인지 알 수가 없었습니다.

"컨테이너별로 리소스 사용량을 볼 수 있는 방법이 없을까?"

docker stats는 실행 중인 컨테이너의 리소스 사용량을 실시간으로 보여주는 명령어입니다. 마치 자동차 계기판처럼 CPU, 메모리, 네트워크, 디스크 I/O를 한눈에 파악할 수 있습니다.

별도의 설치 없이 Docker만 있으면 바로 사용할 수 있어 가장 기본적인 모니터링 도구입니다.

다음 코드를 살펴봅시다.

# 모든 컨테이너 실시간 리소스 모니터링
docker stats

# 특정 컨테이너만 모니터링
docker stats my-app nginx-proxy redis

# 한 번만 출력 (스크립트에서 활용)
docker stats --no-stream

# 원하는 형식으로 출력
docker stats --format "table {{.Name}}\t{{.CPUPerc}}\t{{.MemUsage}}"

# JSON 형식으로 출력 (자동화 스크립트용)
docker stats --no-stream --format \
  '{"name":"{{.Name}}","cpu":"{{.CPUPerc}}","memory":"{{.MemPerc}}"}'

김개발 씨는 어느 날 갑자기 서버가 느려지는 현상을 겪었습니다. 서버에 SSH로 접속해서 top 명령을 실행해 봤더니 CPU 사용률이 90%가 넘었습니다.

하지만 어떤 프로세스가 문제인지 보니 대부분 containerd나 docker 관련 프로세스였습니다. "컨테이너가 여러 개 돌아가고 있는데, 어떤 컨테이너가 리소스를 많이 쓰는 건지 어떻게 알 수 있죠?" 박시니어 씨가 간단한 명령어 하나를 알려주었습니다.

docker stats 명령은 Docker에 내장된 모니터링 도구입니다. 마치 자동차 계기판처럼, 실행 중인 모든 컨테이너의 상태를 한눈에 보여줍니다.

별도의 프로그램을 설치할 필요 없이 docker stats만 입력하면 됩니다. CPU 사용률, 메모리 사용량, 네트워크 송수신량, 디스크 I/O까지 모두 확인할 수 있습니다.

터미널에 docker stats를 입력하면 실시간으로 갱신되는 표가 나타납니다. CONTAINER ID, NAME, CPU %, MEM USAGE / LIMIT, MEM %, NET I/O, BLOCK I/O, PIDS 등의 컬럼이 보입니다.

이 중에서 CPU %와 MEM %를 주로 확인하면 됩니다. 특정 컨테이너가 비정상적으로 높은 수치를 보인다면 그 컨테이너를 집중적으로 살펴봐야 합니다.

위의 코드 예제를 살펴보겠습니다. docker stats만 입력하면 모든 컨테이너를 모니터링합니다.

특정 컨테이너만 보고 싶다면 이름을 지정하면 됩니다. --no-stream 옵션을 사용하면 한 번만 출력하고 종료되므로 스크립트에서 활용하기 좋습니다.

--format 옵션으로 원하는 정보만 깔끔하게 출력할 수도 있습니다. 실무에서는 어떻게 활용할까요?

장애 상황에서 빠르게 원인을 파악할 때 가장 먼저 docker stats를 실행합니다. 메모리 누수가 있는 컨테이너는 시간이 지날수록 MEM USAGE가 계속 증가합니다.

CPU를 과도하게 사용하는 컨테이너도 쉽게 찾을 수 있습니다. 또한 --no-stream과 --format을 조합해서 모니터링 스크립트를 만들기도 합니다.

주의할 점도 있습니다. docker stats는 실시간 데이터만 보여줍니다.

과거 데이터는 저장되지 않습니다. 따라서 "어제 몇 시에 CPU가 급증했다"는 것은 docker stats만으로는 알 수 없습니다.

이런 히스토리가 필요하다면 Prometheus 같은 별도의 모니터링 시스템이 필요합니다. 김개발 씨는 docker stats를 실행해서 redis 컨테이너가 CPU를 80%나 사용하고 있는 것을 발견했습니다.

확인해 보니 캐시 만료 처리 로직에 문제가 있었습니다. "이렇게 간단하게 찾을 수 있었네요!"

실전 팁

💡 - 장애 상황에서는 docker stats부터 실행해 리소스 과다 사용 컨테이너를 찾으세요

• --format 옵션으로 알림 스크립트를 만들어 임계치 초과 시 알림을 받을 수 있습니다

---

4. cAdvisor 활용

김개발 씨는 docker stats로 당장의 문제는 해결했지만, 시간대별 리소스 사용 추이를 보고 싶어졌습니다. "오전에는 괜찮았는데 오후만 되면 느려져요"라는 피드백이 있었기 때문입니다.

과거 데이터를 보려면 어떻게 해야 할까요?

cAdvisor(Container Advisor)는 구글에서 만든 컨테이너 모니터링 도구입니다. docker stats와 달리 웹 UI를 제공하고, 과거 데이터를 일정 기간 저장합니다.

마치 블랙박스가 운행 기록을 저장하듯이, 컨테이너의 리소스 사용 이력을 그래프로 보여줍니다.

다음 코드를 살펴봅시다.

# cAdvisor 컨테이너 실행
docker run -d \
  --name cadvisor \
  --privileged \
  --volume /:/rootfs:ro \
  --volume /var/run:/var/run:ro \
  --volume /sys:/sys:ro \
  --volume /var/lib/docker/:/var/lib/docker:ro \
  --publish 8080:8080 \
  gcr.io/cadvisor/cadvisor:latest

# 실행 확인
curl http://localhost:8080/api/v1.3/containers/

# Prometheus 형식 메트릭 확인
curl http://localhost:8080/metrics | head -50

김개발 씨는 docker stats로 현재 상태는 볼 수 있지만, 과거 기록을 볼 수 없어 불편했습니다. 사용자들이 "오후 2시쯤 느려졌다"고 하면, 그 시간대의 데이터를 확인할 방법이 없었습니다.

박시니어 씨가 cAdvisor를 추천해 주었습니다. cAdvisor는 구글에서 만든 오픈소스 컨테이너 모니터링 도구입니다.

마치 자동차의 블랙박스처럼, 컨테이너의 리소스 사용 기록을 저장하고 보여줍니다. 웹 브라우저에서 그래프로 시각화된 데이터를 볼 수 있어 훨씬 직관적입니다.

기본적으로 최근 1분간의 데이터를 초 단위로 저장합니다. cAdvisor를 실행하는 방법은 매우 간단합니다.

위의 코드처럼 docker run 명령 한 줄이면 됩니다. 다만 몇 가지 볼륨 마운트가 필요합니다.

/sys, /var/lib/docker 등을 마운트하는 이유는 cAdvisor가 Docker 데몬과 시스템 정보에 접근해야 하기 때문입니다. --privileged 옵션도 같은 이유로 필요합니다.

실행 후 웹 브라우저에서 http://서버IP:8080에 접속하면 대시보드가 나타납니다. 메인 화면에서 호스트 시스템의 전체 리소스 사용량을 볼 수 있습니다.

하단의 Subcontainers 섹션에서 개별 컨테이너를 클릭하면 해당 컨테이너의 상세 정보가 나옵니다. CPU, 메모리, 네트워크, 파일시스템 사용량이 시간대별 그래프로 표시됩니다.

cAdvisor의 또 다른 강점은 Prometheus와의 연동입니다. /metrics 엔드포인트를 통해 Prometheus가 수집할 수 있는 형식으로 메트릭을 제공합니다.

이 기능 덕분에 cAdvisor는 Prometheus 기반 모니터링 시스템의 데이터 수집기로 널리 사용됩니다. 실무에서는 어떻게 활용할까요?

개발 환경이나 소규모 서비스에서는 cAdvisor만으로도 충분한 모니터링이 가능합니다. 웹 UI가 있어 비개발자도 쉽게 현황을 파악할 수 있습니다.

대규모 환경에서는 cAdvisor를 각 서버에 설치하고, Prometheus로 데이터를 수집한 후 Grafana로 시각화하는 조합을 많이 사용합니다. 주의할 점도 있습니다.

cAdvisor 자체도 리소스를 사용합니다. 특히 컨테이너가 많은 환경에서는 메모리 사용량이 상당할 수 있습니다.

또한 기본 설정으로는 최근 1분간의 데이터만 저장하므로, 장기간 데이터가 필요하다면 Prometheus 같은 시계열 데이터베이스와 연동해야 합니다. 김개발 씨는 cAdvisor를 설치한 후 웹 UI에서 오후 시간대의 그래프를 확인했습니다.

특정 컨테이너의 메모리 사용량이 시간이 지날수록 계속 증가하는 패턴을 발견했습니다. 메모리 누수였습니다.

실전 팁

💡 - cAdvisor는 가볍지만 컨테이너 수가 많으면 메모리 사용량이 증가합니다

• 장기간 데이터 보관이 필요하면 Prometheus와 연동하세요

---

5. Prometheus 연동 기초

cAdvisor로 모니터링을 하던 김개발 씨는 새로운 요구사항을 받았습니다. "지난 일주일간의 리소스 추이를 보고서로 만들어 주세요." cAdvisor는 1분치 데이터만 저장하는데, 일주일치 데이터는 어디서 가져와야 할까요?

Prometheus는 시계열 데이터베이스 기반의 모니터링 시스템입니다. cAdvisor나 다른 exporter들이 제공하는 메트릭을 주기적으로 수집해서 장기간 저장합니다.

마치 건강검진 기록을 병원 데이터베이스에 저장해 두고 나중에 조회하는 것과 같습니다.

다음 코드를 살펴봅시다.

# prometheus.yml 설정 파일
global:
  scrape_interval: 15s

scrape_configs:
  - job_name: 'prometheus'
    static_configs:
      - targets: ['localhost:9090']

  - job_name: 'cadvisor'
    static_configs:
      - targets: ['cadvisor:8080']

  - job_name: 'docker'
    static_configs:
      - targets: ['host.docker.internal:9323']

# Prometheus 컨테이너 실행
docker run -d \
  --name prometheus \
  --publish 9090:9090 \
  --volume ./prometheus.yml:/etc/prometheus/prometheus.yml \
  prom/prometheus:latest

김개발 씨는 cAdvisor 덕분에 실시간 모니터링은 잘 되고 있었습니다. 그런데 팀장님이 "지난 일주일간 서버 리소스 사용 추이를 보고서로 만들어 달라"고 요청했습니다.

cAdvisor를 열어봤지만 최근 1분간의 데이터만 있었습니다. 박시니어 씨가 말했습니다.

"장기간 데이터가 필요하면 Prometheus를 써야 해. cAdvisor는 데이터 수집기고, Prometheus가 그 데이터를 저장하는 역할이야." Prometheus는 SoundCloud에서 만들어 지금은 CNCF(Cloud Native Computing Foundation)에서 관리하는 오픈소스 모니터링 시스템입니다.

비유하자면, cAdvisor가 매일 건강 수치를 측정하는 체중계라면, Prometheus는 그 기록을 저장하는 건강 다이어리입니다. 나중에 "3개월 전 몸무게가 얼마였지?"라고 물어보면 바로 답할 수 있습니다.

Prometheus도 마찬가지로 수집한 메트릭을 시계열 데이터베이스에 저장합니다. Prometheus의 동작 방식은 Pull 모델입니다.

대부분의 모니터링 시스템은 에이전트가 서버로 데이터를 보내는 Push 방식입니다. 반면 Prometheus는 모니터링 대상이 메트릭을 노출하면, Prometheus가 주기적으로 가져오는 Pull 방식입니다.

cAdvisor가 /metrics 엔드포인트로 메트릭을 노출하면, Prometheus가 15초마다 그 데이터를 가져옵니다. 위의 설정 파일을 살펴보겠습니다.

global 섹션의 scrape_interval은 데이터를 수집하는 주기입니다. 15초로 설정하면 15초마다 데이터를 가져옵니다.

scrape_configs 섹션에서 모니터링 대상을 정의합니다. job_name은 구분을 위한 이름이고, targets에 수집 대상의 주소를 지정합니다.

Prometheus 웹 UI에서 PromQL이라는 쿼리 언어로 데이터를 조회할 수 있습니다. 예를 들어 container_memory_usage_bytes를 입력하면 모든 컨테이너의 메모리 사용량이 나옵니다.

rate(container_cpu_usage_seconds_total[5m])처럼 함수를 사용하면 5분간 CPU 사용률 변화를 계산할 수 있습니다. 실무에서 Prometheus는 어떻게 활용될까요?

대부분의 회사에서는 Prometheus + Grafana 조합으로 모니터링 시스템을 구축합니다. Prometheus가 데이터를 수집하고 저장하면, Grafana가 예쁜 대시보드로 시각화합니다.

알림 기능도 있어서 CPU 사용률이 90%를 넘으면 슬랙으로 알림을 보내는 식으로 설정할 수 있습니다. 주의할 점도 있습니다.

Prometheus는 기본적으로 15일간의 데이터를 저장합니다. 더 오래 보관하려면 설정을 변경하거나 장기 저장소를 별도로 구성해야 합니다.

또한 수집 대상이 많아지면 Prometheus 자체의 리소스 사용량도 증가합니다. 김개발 씨는 Prometheus를 설정하고 일주일을 기다린 후, PromQL로 데이터를 추출해 보고서를 만들 수 있었습니다.

"과거 데이터가 있으니까 패턴을 분석할 수 있네요!"

실전 팁

💡 - Prometheus는 Pull 방식이므로 모니터링 대상이 메트릭을 노출해야 합니다

• Grafana와 연동하면 시각적인 대시보드를 쉽게 만들 수 있습니다

---

6. 로그 중앙화 전략

김개발 씨의 회사는 서비스가 성장하면서 서버가 10대로 늘어났습니다. 각 서버에서 docker logs로 로그를 확인하던 방식이 더 이상 통하지 않았습니다.

"어떤 서버에서 에러가 났는지 찾으려면 10대를 다 뒤져봐야 하나요?"

로그 중앙화는 분산된 여러 서버의 로그를 한 곳에 모아서 관리하는 전략입니다. 마치 전국 각지의 편지를 하나의 우체국 물류센터로 모은 다음 분류하고 검색하는 것과 같습니다.

ELK 스택(Elasticsearch, Logstash, Kibana)이나 EFK 스택(Elasticsearch, Fluentd, Kibana)이 대표적인 솔루션입니다.

다음 코드를 살펴봅시다.

# Fluentd 설정 예시 (fluent.conf)
<source>
  @type forward
  port 24224
  bind 0.0.0.0
</source>

<match docker.**>
  @type elasticsearch
  host elasticsearch
  port 9200
  logstash_format true
  logstash_prefix docker
</match>

# Docker 컨테이너에서 Fluentd로 로그 전송
docker run -d \
  --log-driver=fluentd \
  --log-opt fluentd-address=localhost:24224 \
  --log-opt tag="docker.{{.Name}}" \
  --name my-app \
  nginx:latest

# docker-compose로 EFK 스택 구성 예시
# docker-compose.yml
version: '3'
services:
  elasticsearch:
    image: elasticsearch:7.17.0
    environment:
      - discovery.type=single-node
  kibana:
    image: kibana:7.17.0
    ports:
      - "5601:5601"
  fluentd:
    image: fluent/fluentd:v1.14
    ports:
      - "24224:24224"

김개발 씨의 회사는 1년 사이에 빠르게 성장했습니다. 처음에는 서버 1대였지만 지금은 10대가 되었습니다.

각 서버에서 여러 컨테이너가 돌아가고 있었습니다. 에러가 발생하면 어떤 서버에서 문제가 생겼는지 찾기 위해 10대의 서버를 하나씩 접속해야 했습니다.

"이건 도저히 안 되겠어요. 로그를 한 곳에서 볼 수 있는 방법이 없을까요?" 박시니어 씨가 화이트보드에 그림을 그리며 설명했습니다.

로그 중앙화는 분산된 로그를 한 곳으로 모으는 것입니다. 마치 전국 각지의 택배를 물류센터 한 곳에 모은 다음, 그곳에서 분류하고 배송하는 것과 같습니다.

로그도 마찬가지입니다. 각 서버의 로그를 중앙 서버로 모은 다음, 그곳에서 검색하고 분석합니다.

에러가 발생하면 중앙 시스템에서 검색 한 번으로 어떤 서버에서 문제가 생겼는지 바로 찾을 수 있습니다. 로그 중앙화의 대표적인 솔루션은 ELK 스택입니다.

Elasticsearch, Logstash, Kibana의 첫 글자를 딴 것입니다. Elasticsearch는 로그를 저장하고 검색하는 데이터베이스입니다.

Logstash는 여러 곳에서 로그를 수집해서 Elasticsearch로 보내는 역할을 합니다. Kibana는 웹 기반 UI로 로그를 검색하고 대시보드를 만듭니다.

Docker 환경에서는 EFK 스택을 더 많이 사용합니다. Logstash 대신 Fluentd를 사용하는 것입니다.

Fluentd는 CNCF 프로젝트로, 컨테이너 환경에 최적화되어 있습니다. Docker에는 fluentd 로그 드라이버가 내장되어 있어서 연동이 매우 쉽습니다.

메모리 사용량도 Logstash보다 적습니다. 위의 코드를 살펴보겠습니다.

fluent.conf에서 forward 타입의 source는 Fluentd가 24224 포트에서 로그를 받겠다는 의미입니다. match 섹션에서 받은 로그를 Elasticsearch로 전송합니다.

Docker 컨테이너는 --log-driver=fluentd 옵션으로 로그를 Fluentd로 보냅니다. 실무에서 로그 중앙화를 구축할 때 고려할 점이 있습니다.

첫째, 로그 양을 예측해야 합니다. 하루에 몇 GB의 로그가 발생하는지에 따라 Elasticsearch 클러스터 크기가 달라집니다.

둘째, 보관 기간을 정해야 합니다. 무한정 저장할 수는 없으므로 30일, 90일 등 정책을 세워야 합니다.

셋째, 민감 정보 처리입니다. 로그에 개인정보가 포함되지 않도록 마스킹 처리가 필요할 수 있습니다.

주의할 점도 있습니다. EFK 스택 자체가 상당한 리소스를 사용합니다.

특히 Elasticsearch는 메모리를 많이 필요로 합니다. 소규모 환경에서는 과한 투자가 될 수 있습니다.

이런 경우 Grafana Loki 같은 경량 솔루션을 고려해 볼 수 있습니다. 김개발 씨는 EFK 스택을 구축한 후, Kibana에서 "error" 키워드로 검색하자 10대 서버의 모든 에러 로그가 한눈에 보였습니다.

"어떤 서버에서 에러가 났는지 1초 만에 알 수 있네요!"

실전 팁

💡 - Docker 환경에서는 Logstash보다 Fluentd가 더 가볍고 연동이 쉽습니다

• 로그 양에 따라 Elasticsearch 클러스터를 적절히 구성하고, 인덱스 라이프사이클 정책을 설정하세요

---

이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!