요약 : 기존 VM의 모놀리틱 애플리케이션의 경우 로그, 메트릭, 상태 등의 수집을 위해 여러 에이전트를 지원하므로 Logstash가 유리할 수 있고, Docker 및 K8s에서 호스팅되는 마이크로서비스의 경우 Fluentd가 기본 제공 로깅 드라이버와 원활한 통합을 고려할 때 훌륭한 선택이다!
회사에서 어떤 방식을 채택하고 있는지 확인해보니.. 3가지 방식이나 사용하고 있었다.
Fluentd : systemd/kubernates master component 로그 수집 ( DevOps 팀에서 사용 )
Logstash : app 별 logstash deploy ( 데이터 팀에서 사용 )
app 내부에서 애플리케이션 로그 전송 ( java app 에서 사용 )
app 내부에서 직접 카프카를 이용해 애플리케이션 로그를 전송하는데 이슈 레이징도 최근에 있었다.
초기화 과정에서 종종 문제발생, 디버깅도 잘 안됨
카프카 연결이 안되면 어플리케이션 스타트 자체가 안됨 ( critical )
application 에서 직접 카프카 커넥션 관리, 네트워크 트래픽 발생 application performance 에 직접적인 영향(추측)
초기화 단계에서 에러 난 경우, 비정상적인 크래시 났을때 로그 확보 불가 (그냥 stdout 으로 찍었다면 최소한 filesystem 버퍼에 있는건 flush되고 종료될 것 같습니다.)
카프카등에서 문제 생겼을때 로그 유실
끄적끄적
Logstash 는 자바 VM에서 실행되기 때문에 비교적 많은 양의 메모리를 사용한다.
Fluentd는 CNCF에서 관리하고, 따라서 자연스럽게 쿠버네티스용 오픈 소스 기반 로그 수집기로 Fluentd가 선택 됐다.
플루언티드의 로그 레코드 이벤트 구성 요소
time 필드 : 로그 레코드의 작성 일시
tag 필드 : 로그 레코드의 유형 식별, 플루언티드 라우팅 엔진에서 로그 레코드 처리 방법을 결정할 때 사용
record 필드 : JSON 객체 형태로 저장된 실제 로그 정보를 담는다.
플루언티드가 로그 레코드를 수집 및 처리하고 일래스틱서치 등의 다양한 대상에 전송하는 방법은 구성 파일에서 정의한다.
: 플루언티드가 어디에서 로그 레코드를 수집하는지 설명하고자 source 요소를 사용
: 로그 레코드를 처리하고자 filter 요소 사용, 로그 메시지 일부를 로그 레코드의 별도 필드로 추출하고, 로그 레코드 정보를 별도 필드로 추출하면 이를 일래스틱 서치에서 검색할 수 있다.
: output 요소로 두 가지 작업을 수행한다.
- 처리한 로그 레코드를 일래스틱서치 등의 대상으로 보낸다.
- 라우팅으로 로그 레코드 처리 방법을 결정한다. 라우팅 룰을 사용해 추가 처리를 위한 태그를 재작성하고 플루언티드 라우팅 엔진으로 로그 레코드를 다시 보낼 수 있다. 요소 안의 요소로 라우팅 룰을 표현한다.
2rohyun
commented
2 years ago 
LOG-INFO
MinJunKweon
istio + EFK
Why is EFK better than ELK ?
느낀점