로그 분석 시스템으로는 ELK(ElasticSearch Logstash, Kibana)가 아마 가장유명 할 것이다. 로그 색인으로는 ElasticSearch, 대쉬보드 구성은 kibana로 구정된 것 같고, 결국 남는 선택지는 로그수집툴을 무얼로 할 것이냐 하는 거다. 나는 logstash 대신에, fluentd를 선택하기로 했다.
무슨 대단한 이유가 있어서 fluentd를 선택한 건아니다. 비교적 가볍고, 기능이 더 많더라는 지인의 이야기를 듣고 선택했다. 서비스 인프라를 컨테이너로 하고 있기 때문에 가볍다(그리고 배포하기 쉽다)는 특징은 나에게 꽤나 중요하다.
나는 아래와 같이 로그 분석 시스템을 구성하기로 했다.
고가용성, 고확장성의 Elastic Cloud를 구성하고 모든 서비스의 로그를 통합하는 방법도 있다. 하지만 컨테이너 기반으로 구성된 서비스 환경에서는 서비스 단위로 할당하는게 더 낫다고 생각했다. 이 경우에는 Elastic Cloud가 아닌 one ElasticSearch container + one Kibana로 구성한다. 그리고 docker-compose 와 함께 서비스단위로 묶어서(link를 이용) 배포해 버린다. 이렇게 구성하면, 서비스 개발자는 ElastkcSearch와 Kibana의 호스트위치를 신경쓰지 않고 오로지 link 이름만으로 간단히 접근 할 수 있게 된다. 자동화된 배포도 훨씬 쉬워질 것이다.
물론 고가용성과 고확장성을 포기해야 한다. 하지만 EFK로 남기는 로그는 HTTP 요청로그와 애플리케이션 에러로그이고, 로그의 일부를 유실한다고 해도 별 문제가 아니다. 얻는게 더 많은 구성이라 할 수 있다.
Fluentd는 오픈소스 기반의 로그 데이터 수집 프로그램으로, 로그를 필터링해서 다른 프로그램으로 보내는 일을 한다. 예를 들어 애플리케이션 로그 중, 에러로그를 필터링 한 다음 JSON 포맷으로 만들어서, elasticsearch로 보내서 색인하는 등의 작업을 할 수 있다.
아래 그림은 아파치 웹 서버 로그를 JSON으로변환하는 모습을 묘사하고 있다.
Fluentd는 가능한 데이터를 JSON 형식으로 구조화 하려고 한다. 또한 여러 소스(파일, HTTP, syslog 등)로 부터 만들어지는 로그를 하나의 단일 통로에서 처리하고 통합 할 수 있다. JSON을 이용하기 때문에 유연한 스키마를 유지하면서, 다른 애플리케이션이 처리하기 쉽도록 가공 할 수 있다.
Contents
1. EFK
2. 로그 분석 시스템 구성
3. Fluentd 소개
4. JSON기반의 이용한 통일된 로깅 환경
5. Fluentd 설치
6. ElasticSearch & Kibana 설치
7. Fluentd 설정 - JSON
1. EFK
2. 로그 분석 시스템 구성
3. Fluentd 소개
4. JSON기반의 이용한 통일된 로깅 환경
5. Fluentd 설치
6. ElasticSearch & Kibana 설치
7. Fluentd 설정 - JSON
Recent Posts
Archive Posts
Tags