로그 파일 보관부터 중앙 수집까지: 실무형 ELK 흐름

로그 파일 보관부터 중앙 수집까지: 실무형 ELK 흐름

서비스를 운영하다 보면 로그를 “출력”하는 것보다 “관리”하는 일이 더 중요해진다.
개발 단계에서는 콘솔에서 에러를 확인하는 것만으로도 충분할 수 있지만, 운영 환경에서는 과거 로그를 다시 조회하고, 여러 서버의 로그를 한 번에 분석할 수 있어야 한다.

이번에는 로그를 파일로 보관하는 방법부터 ELK 기반 중앙 수집, 그리고 Kibana 시각화까지 하나의 흐름으로 정리했다.

---

1) 콘솔 로그만으로는 운영이 어렵다

콘솔 로그는 실시간 확인에는 유용하지만 휘발성이 강하다.
서버를 재시작하거나 세션이 종료되면 이전 로그를 추적하기 어렵다.

운영에서 필요한 것은 다음이다.

• 과거 장애 시점 로그 재조회
• 시간대별 이슈 비교
• 여러 인스턴스 로그 통합 분석

그래서 로그는 반드시 파일로 남기고, 보존 정책까지 함께 설계해야 한다.

---

 

 

2) Logback과 Appender: 로그의 목적지를 정한다

Logback에서 Appender는 로그를 어디로 보낼지 결정한다.

• ConsoleAppender: 콘솔 출력
• FileAppender: 파일 저장
• RollingFileAppender: 파일 롤링(날짜/시간 단위 분리)

실무에서는 대체로 RollingFileAppender를 사용한다.
하나의 파일에 로그를 계속 쌓으면 파일이 비대해지고, 조회/보관/전송이 모두 비효율적이기 때문이다.

---

 

 

3) 로그 보관 정책의 핵심: 롤링 + 보존기간 + 압축

로그 파일 운영에서 핵심은 세 가지다.

• 롤링: 파일을 주기적으로 분리
• 보존기간(maxHistory): 오래된 로그 자동 삭제
• 압축(.gz): 저장 용량 절감

로그는 트래픽이 늘수록 저장 비용이 급격히 증가한다.
따라서 “얼마나 남길지”와 “어떻게 줄일지”를 함께 정해야 운영 리스크를 줄일 수 있다.

---

 

 

4) 서버가 여러 대일 때 필요한 구조: ELK

단일 서버에서는 파일 검색으로도 어느 정도 대응이 가능하다.
하지만 서버가 여러 대가 되면 각 서버 로그를 개별 확인해야 해서 대응 속도가 크게 떨어진다.

이때 필요한 구조가 ELK다.

• Elasticsearch: 로그 저장/검색 엔진
• Logstash: 수집/가공/전송 파이프라인
• Kibana: 검색/시각화 UI

핵심은 “흩어진 로그를 중앙으로 모아, 같은 기준으로 검색 가능하게 만드는 것”이다.

---

 

 

5) Logstash 파이프라인 이해: input -> filter -> output

Logstash는 보통 아래 흐름으로 동작한다.

1. input: 로그 파일 읽기
2. filter: 필요한 필드 파싱/정규화
3. output: Elasticsearch로 전송

초기에는 filter를 최소로 두고 빠르게 수집 파이프라인을 먼저 완성하는 전략이 좋다.
그다음 필요한 분석 축(레벨, 서비스명, traceId 등)에 맞춰 filter를 점진적으로 고도화하면 된다.

---

 

 

6) 왜 Elasticsearch를 쓰는가

로그는 대량 텍스트 데이터다.
관계형 DB로도 저장은 가능하지만, 대규모 텍스트 검색과 집계에선 검색 엔진이 더 적합하다.

Elasticsearch의 장점은 다음과 같다.

• 대용량 텍스트 빠른 검색
• 시간 기반 인덱스 운영 용이
• Kibana와의 자연스러운 연동

즉, 로그 시스템에서는 “정합성 중심 DB”보다 “검색 중심 엔진”이 목적에 맞다.

---

 

 

7) Kibana로 운영 관점 만들기

Elasticsearch에 로그가 적재되면 Kibana에서 Data View를 생성해 탐색을 시작할 수 있다.

실무에서 자주 사용하는 화면은 두 가지다.

• Discover: 시간/키워드 기반 상세 검색
• Dashboard: 에러 추이, 레벨 분포, 이벤트 빈도 시각화

결국 Kibana의 역할은 “로그를 읽는 도구”가 아니라 “운영 판단을 빠르게 만드는 도구”에 가깝다.

---

 

 

8) 정리: 로그 체계는 단계적으로 만든다

운영 로그 체계는 아래 순서로 잡는 게 안정적이다.

1. Logback으로 파일 로그 표준화
2. Rolling + maxHistory + 압축 정책 적용
3. Logstash로 수집 자동화
4. Elasticsearch 인덱스 저장
5. Kibana Discover/대시보드 운영

이 흐름이 갖춰지면 장애 대응이 감각이 아니라 데이터 기반으로 바뀐다.
그리고 운영에서 가장 큰 차이를 만드는 건 “로그를 남겼다”가 아니라 “로그를 바로 찾을 수 있다”는 점이다.