EFK(ELK) 구축 해보기!! (서버 로그 수집) - 1. 로그와 로그 수집 아키텍처

로그

우선 로그란,

컴퓨터가 운행 도중에 남기는 유의미한 기록을 말한다.

 

로그에는

1) Timestamp

2) 로그 레벨

3) 로그 내용

4) 발생 위치

등이 일반적으로 들어간다.

 

로그는 파일을 남기지만

수집이 따로 필요한 이유는

1. 시스템에 장애가 나면 로그파일에 다시 접근할 수 없을 수 있다.

2. 관리해야하는 프로그램이나 인스턴스 수가 많아지면 개별적으로 확인하기 어렵다.

3. 필터링이나 검색 등을 이용해서 로그를 더욱 활용하여 시스템 신뢰도를 높일 수 있다.

 

로그 수집 아키텍처

환경에 따라서 다양하게 로그를 수집할 수 있다.

 

1. 파일을 이용한 수집

App이 만든 Log File을 별도의 Log Collector가 수집하고 전송한다.

 

장점으로는

1. 디자인 패턴에서 중요한 '관심사의 분리'가 이루어져 서로의 역할에 집중할 수 있으며 유연성이 높아진다.

2. 리소스를 분리하여 Log collector로 인해 App에 리소스 부족과 같은 부하를 주지 않는다.

 

단점으로는

1. 각각 별도로 생성하고 관리해야한다.

 

2. Network를 이용한 Push

App에서 TCP, HTTP 등의 프로토콜로 전송하는 방법이다.

 

장점으로는

1. 로그 전송의 실패여부를 App에서 판단할 수 있다.

 

단점으로는

1. 로그 전송으로 인해 App 동작에 문제가 생길 수 있다.

2. 디버깅이 어려워진다.

 

3. Network를 이용한 Polling

Log Collector가 외부에서 직접 App의 채널로 주기적으로 Polling으로 scrap 하는 방식이다.

 

이 구조의 특징은

주기적으로 가져오기에 Log보다는 Metric(통계 정보, 상태정보에 대한 snapshot) 수집에 더 적합하다.

 

장점으로는

1. 이 아키텍처도 관심사의 분리가 이뤄진다.

2. App 개발자가 수집에 대한 관리를 할 필요가 없다.

3. App이 바뀌더라도 Log Collector를 내릴 필요가 없기에, 분산 환경이나 컨테이너 환경, 자동화된 인프라 환경에서 사용하기 좋고 확장성도 높다.

 

단점으로는

1. 특정 순간의 정확한 정보를 보기에 적합하지 않다.

 

 

 

출처 : https://yoonsung.notion.site/P04-C09-EFK-bef9eba396b54544ad033d1c02769e7e#15920f932b864f598b1b0238d4319755