-
이전 모니터링으로 LGTM + OTel 방식을 살펴보았다.
해당 구성은 아래 그림처럼 구성이 된다.

여기서 문제점은 mimir, tempo, loki 가 너무 무겁다는 것에 있다.
대규모 인프라 환경이라면 모니터링을 위해 메모리를 8기가 이상 사용할 수 있겠지만, 소~중규모, 혹은 프로젝트의 모니터링이라면 부담이 된다.
물론 간단하게 Prometheus + Grafana를 통해 매트릭을 수집할 수 있겠으나, 로그나 트레이스도 수집하고 싶다면 리소스가 부족한 상황이 된다.
이때 사용하기 좋은 것이 VictoriaMetrics Stack이다.
아이디어 자체는 비슷하다.
다만 metrics은 무거운 mimir 대신에 vmagent와 victoriametrics를,
log의 경우 무거운 loki 대신에 가벼운 victorialogs를,
트레이스는 마찬가지로 무거운 tempo 대신 jeager를 사용한다.
모든 것이 경량화된 버전으로 생각해도 좋아.
다만, 경량화 된 만큼 확장시 기능이나 성능적으로 조금 불리한 면이 있고,
Grafana와의 완벽한 통합이 안되어 있어서 기능적으로 조금 부족하다.
하지만 기대 리소스 자원에서 엄청난 이점이 존재한다.
LGTM + : 메모리 약 12기가, CPU 4
VictoriaMetrics : 메모리 약 3기가, CPU 1
최소 2배 ~ 5배까지 차이가 나는 것을 보면, 기능은 챙기고 싶지만 가용 리소스 자원이 적다면 충분히 고려해볼 선택지 중 하나임을 분명하다.
'Monitoring > VictoriaMetrics Stack' 카테고리의 다른 글
VictoriaMetrics Stack 완전해부 - 4: VMAgent를 없애고 VMSingle 만 사용하기 : 메트릭 (0) 2026.06.09 VictoriaMetrics Stack 완전해부 - 4: VMAgent를 없애고 VMSingle 만 사용하기 실제 확인 (0) 2026.06.09 VictoriaMetrics Stack 완전해부 - 2 (0) 2026.06.09 VictoriaMetrics Stack 완전해부 - 1 (0) 2026.06.09 VictoriaMetrics Stack 을 활용한 모니터링 구축 (0) 2026.06.04 댓글
