PLG 로그 관리 시스템 구축(ELK vs PLG)

승현·2024년 8월 8일

PLG 도입

목록 보기
1/3
post-thumbnail

시작하게 된 계기

요즘 인프라 구축이나 자동화 이런 것에 관심이 많아졌다는 이야기를 선임한테 했더니 과제(키워드)를 하나 선물 받았다.

내부적으로 서버가 많이 돌아간다. Virtual Server로 많이 돌아가고 있는데, 그 중 사용도와 중요도가 비교적 낮은 서버가 하나 있다.

그 서버에 로그 관리 시스템을 한번 구축 해보라는 과제를 받았다. 처음엔 ELK로 구축하면 로그 관리, 리소스 모니터링 등 많은 장점이 있을 것이라고 생각했다.
하지만 라이센스 문제가 있어서 비교를 해보고 정하기로 했다.

ELK vs PLG

ELK Stack


Elastic Search + Logstash + Kibana (+Beats)
3가지 기술로 로그 수집, 적재, 표현으로 유기적으로 동작하는 스택이다.
MSA 처럼 클러스터가 나눠져 있는 경우는 Beats를 추가적으로 사용하기도 한다.

  • 장점
    • Java 기반으로 이뤄져 있어 다루기 쉽다.
    • 중앙 집중식 로깅
    • 실시간 데이터 시각화
  • 단점
    • 구축이 복잡하고 어렵다.
    • 리소스를 많이 차지한다. 서비스 규모가 커질 수록 부각되는 단점이다.
    • 미래의 라이센스 만료 예정

ELK 스택 참조 링크
라이센스 만료

PLG Stack

Promtail + Loki + Grafana

Promtail을 Client에 설치,
Loki와 Grafana를 Server에 설치한다.

Promtail을 agent처럼 로그 파일을 Loki에 전송한다.
Loki는 받은 파일을 적재하고 Grafana에서 시각화하는 방식이다.

이번 결정에 더 비중을 둔 점은 ELK니 PLG니 이런걸 모르는 사람도 사용이 가능해야하고, 로그 분석이 더 필요했다. ELK와 PLG 둘다 사용해 보니 바로 사용하기에 간편하고, 로그 자체를 보기 편한 PLG로 선택했다.

다른 개발자 분들이 같이 너무 바빠서 시스템을 도입할 때, 추가적인 학습이나 시간소모 없이 사용하기 편한 것이 비중이 가장 컸다.

레퍼런스 링크

따끈따끈한 전사 로그 시스템 전환기: ELK Stack에서 Loki로 전환한 이유
Logging in Kubernetes: EFK vs PLG Stack

0개의 댓글