Chapter 19. EFK 스택을 사용한 로깅 중앙화

[minkukjo]

istio + EFK

• 이스티오 프록시 로그를 분리하는 것이 인상적이었다.

Why is EFK better than ELK ?

• 왜 ELK가 아니라 EFK인가가 궁금해져서 좀 찾아봤다.
• 비교글
  
• 가장 핵심은 컨테이너 환경 ( 더 척박한 자원 )에서 fluentd의 가벼움에 손을 들어준 것으로 보인다.

느낀점

• 카카오에서 하고 있는 로그 중앙화 처리 방식과 책에서 소개한 방식이 거의 똑같았다. ( 과거의 카카오 선조들이 이걸로 공부한건가? )

[2rohyun]

느낀점

---

• 키바나는 항상 많이 써왔는데, ElasticSearch, Fluentd 등은 직접 사용하는 부분이 아니여서 잘 몰랐는데, 이번 기회에 개념 정리가 되었다.
• Logstash 와 Fluentd가 구체적으로 어떤 차이가 있는지 궁금해서 조금 더 찾아보았다.
• https://smoh.tistory.com/365
• 요약 : 기존 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 요소로 두 가지 작업을 수행한다.
    • 처리한 로그 레코드를 일래스틱서치 등의 대상으로 보낸다.
    • 라우팅으로 로그 레코드 처리 방법을 결정한다. 라우팅 룰을 사용해 추가 처리를 위한 태그를 재작성하고 플루언티드 라우팅 엔진으로 로그 레코드를 다시 보낼 수 있다. 요소 안의 요소로 라우팅 룰을 표현한다.

[LOG-INFO]

끄적끄적

• 사내 ELK 플랫폼(Nelo)에서 UI단(Kibana wrapping으로 보임)만 사용하다가 내부 동작방식을 이해하게 됨
  • 차이점은 우린 Log 설정파일에 nelo appender(Thrift or HTTP)를 추가하여 사용함
    • Thrift는 RPC 방식
  • https://guide.ncloud-docs.com/docs/elsa-elsa-1-5-6-1
• MSA가 아니더라도 어떤 시스템이든 인스턴스가 두 개 이상이면 로그 중앙화 필수라고 생각함
  • 지금 callback 서버가 n대가 있는데, 인코딩 콜백 잘못된거 확인하려면 n대 전부 돌면서 로그파일 확인해야함...
• 기존엔 ELK 스택 많이 사용했지만, 메모리 사용량의 문제로 EFK로 넘어가는 추세인 듯
  • (민국님이 자세한 비교글 올려주셨음)
• 설정파일 너무 복잡하다.... 정규식 끔찍....

문제풀이

1. NOT이라서?
2. p.717 ?
3. spring.trace로 검색
4. 뒤에 * 하나 없음
5. curl http://elasticsearch.logging.svc.cluster.local:9200 -s | jq -r .tagline
6. ??

[MinJunKweon]

느낀점

• 사내 플랫폼이 ELK를 사용해서 Fluentd의 동작방식이 좀 궁금했는데 이번 장에서 쉽게 알 수 있었음!
• 로그 레코드 파싱하는 설정파일이 꽤 복잡한 건 새로 알게 됨. 적용하려면 서베이를 좀 자세히 해야할 듯..
• 데몬셋으로 플루언티드를 사용할 수 있다는 점이 k8s 환경이라면 Logstash 보다는 플루언티드를 써야하는 이유인듯.
• 이미 카카오는 이 스택을 쓴다는 점이 부럽.. 그것도 쉽게 한다니