목표
- 여러개의 Django 프로젝트(가능하면 Spring 포함 다른 프레임워크도)에서 로그를 수집해 한 곳에서 볼 수 있게 정리
- 설정에 따라 Teams나 이메일로 알람/메일 보내기
- 비용 최소화
왜 ELK 인가?
Elasticsearch
사실 로그 저장은 RDB에서도 할 수 있으나, 로그가 늘어날 수록 저장, 조회, 검색시에 한계가 있다. RDB로 어느정도 까지 감당할지 실험해보는 것도 재밌겠지만 이후에 시스템을 수정하고 데이터를 이동하는 것은 피하고 싶기에 일반적인 로그 저장 데이터 저장소를 사용하기로 했다.
Elasticsearch는 원래 라이선스 문제로 논란이 있었으나, 2024년 8월 30일 다시 AGPL-3.0을 추가하는 변경이 있었다.
Elasticsearch의 대안으로 Loki를 이용한 LGTM 스택을 고려해보았으나, 아직 레퍼런스가 적어 보였다. 또한 대규모로 확장될 수록 LGTM 스택이 좋아보이나 특성상 테라바이트 단위의 로그데이터가 쌓일 것으로 보이지는 않았다.
Logstash
로그 수집 핸들러 영역에서 비교한것은 Logstash와 fluentd 두개의 서비스였다.
- : star 14.3k
- : star 13k
주로 Django에서 사용될 것이니 파이썬 logging 지원이 어느정도 되는지 확인해보자.
- Logstash
- 가 자주 사용되는 것으로 보임. Django에서의 사용 예시도 포함되어 있다
logstash.LogstashHandler
- fluentd
- 공식 문서에서는 를 추천
- logging.Handler interface로 FluentHandler를 제공
fluent.handler.FluentHandler처럼 사용하면 되지 않을까…- 또한 formatter 설정을
fluent.handler.FluentRecordFormatter와 같이 해줘야 한다고 한다
둘다 파이썬 계열에서 비슷한 사용율을 가지는 것으로 보이고, 라이브러리로 쉽게 logging과 연동이 되는것으로 보인다.
그래서 다음글을 참고하였다.
현재 상황에 적용되는 서로의 장점을 정리해보면
- Logstash의 장점
- 흔히 사용되는 ELK 스택의 일부, 즉 레퍼런스가 많을 것으로 보임
- 시스템, 컨테이너 매트릭 수집이 더 쉬움
- fluentd의 장점
- fluentd, Prometheus, Kubernetes 등과 함께 CNCF 프로젝트의 일부
- Docker의 로그를 바로 전달받기 좋음(Docker 로깅 드라이버)
로 둘에 큰 차이가 없다.
모놀리식 어플리케이션에서는 Logstash가 괜찮아 보이고, 쿠버네티스를 사용하는 경우 fluentd에 강점이 있어 보인다.
대부분이 모놀리식 어플리케이션으로 보이고, 처음 구성해보는 것이니 ELK 스택을 따라가는 것이 레퍼런스가 많아보여 Logstash를 사용해보기로 결정했다.
다만 Logstash와 fluentd는 결국 로그 수집의 도구이니 필요하다면 이후에 2개 모두를 혼합하여 사용해도 상관없어 보인다.
