로그란? & 로그 수집 아키텍처

Log 

유의미한 내용을 남기는 기록

내용

• 로그를 남긴 시간
• 로그 레벨
  • TRACE : 어플리케이션에서 어떤 상황이 일어나는지 상세한 내용을 보고 싶을 때 ex) 라이브러리의 내부 동작
  • DEBUG
  • INFO
  • WARN
  • ERROR
  • FATAL : 시스템 이용이 불가능한경우 ex) Memory Crash, Disk Full
• 로그 내용
• 로그가 발생한 위치
  • 로그가 WARN, ERROR라면 Line 까지 남기면 좋다.

 

 

로그가 파일에 남아있다면 찾아보면될텐데 왜 수집을 해야할까?

 

1. 시스템에 장애가 나면 로그 파일에 다시 접근하지 못할 수 있다.
2. 사용하는 프로그램이 많아지거나 인스턴스의 수가 많다면 일일히 들어가서 확인하기 어렵다
3. 필터링, 그룹, 검색을 이용하여 더 신뢰있는 시스템을 만들 수 있다.

---

 

로그 수집 아키텍처

 

https://platform9.com/learn/v1.0/tutorials/efk-with-fluentd

1) 파일을 이용한 수집

APP --> Log File --> Log Collector --> 로그 수집 저장소

 

장점

어플리케이션과 로그 수집기과 관심사의 분리(SoC)가 된다.
컨테이너 환경에서 리소스를 분리하면 수집기 때문에 어플리케이션에 부하를 주지 않는다.

 

단점

어플리케이션, 로그 수집기를 별도로 관리해야한다.

2) 네트워크를 이용한 수집

APP --> Log File
        --> 로그 수집 저장소 push (TCP, HTTP)

장점

로그 전송 여부 확인을 어플리케이션에서 판단 가능

단점

어플리케이션 로직과 로그 전송을 같은 process 에서 수행하므로 서로 영향을 줄 수 있다.
로그 전송때문에 어플리케이션의 부하가 있을 수 있다.

3) 네트워크를 이용한 polling

수집기에서 주기적으로 polling으로 scrap 하는 방식

어플리케이션에서 scrap 가능한 채널(network port, path)를 열어둔다.
Log보다는 통계정보, 상태정보에 대한 snapshot (metric) 수집에 더 적합하다.

APP --> LogFile
        <-- poling --- Log Collector --> 로그 수집 저장소

장점

어플리케이션과 metric에 수집에 대한 관심사 분리(SoC)
어플리케이션에서 개발자가 수집에 대한 관리를 할 필요가 없다.

단점

polling 주기나 scrap 시점에 따라 값이 바뀌므로 특정 순간의 정확한 정보를 보는데 적합하지 않다.