Daramu

다람어의 블로그

Monitoring/VictoriaMetrics Stack

이전 포스팅으로 VMAgent를 삭제하는 것 까지는 좋았으나. 한가지 새롭게 안 사실이있다. 메트릭데이터가 한참 안들어와서 조사해본 결과,이전 설정으로 Spring boot와 yaml 로 설정한 "instrumentation.yaml" 를 통해 어플리케이션 데이터가 들어오는건 맞았다. 거기에는 애플리케이션 내부 JVM 메트릭 데이터도 들어가있다.여기까지는 맞다. 하지만 노드나 OS레벨의 메트릭 정보를 보기 위해서는 Otel collector하나로는 부족했다.하나로 수집 가능하다고 생각했었지만, 다시 조사해본결과 그게 아니라 어찌되었든 node-exporter와 kube-state-metrics의 설치는 불가피할 거 ㅅ같다. node-exporter는 유명하겠지만 노드의 cpu, memory 등 상태를 보..

2026. 6. 9.

Monitoring/VictoriaMetrics Stack

이제 위 구성의 동작을 실제 화면으로 확인해 보겠다.현재 monitoring에 떠있는 pod는 다음과 같다.시각화의 grafana, 트레이스의 jeagerm, 전용 로그를 수집하는 otel-ds, 모든데이터를 중앙처리하는 otel-gw, 여러 정보에 라벨을 붙이는 vm-operator, 로그 백엔드의 vmlogs, 메트릭 백엔드의 vmsignle이다. 그리고 여기서 앱의 트레이스와 로그를 push해줄 Open java agent를 주입해보겠다.방식은 이전 포스팅에서 이야기 했듯이, Instrumentation를 사용할 것이다. 참고로 설치했다면 문제 없겠지만, otel crd가 없다면 설치가 필요하다.kubectl get crd | grep opentelemetry#없다면 설치kubectl apply -..

2026. 6. 9.

Monitoring/VictoriaMetrics Stack

이전 포스팅에 이어 2편으로 이어가겠다. 4. vmlogs-values.yamlserver: retentionPeriod: 30d수집된 로그를 30일까지 저장하겠다는 선언이다.이전 포스팅의 VMSingle은 기본 단위가 개월이었지만, 로그는 일단위이니 d를 사용했다.로그데이터는 숫자인 메트릭에 비해 텍스트 정보라 용량이 훨씬 크도 폭팔적이다. 그래서 타이트하게 잡는 것이 보통이다. 근데 여기서 왜 메트릭은 두개인데 로그와 트레이스는 한개인지 의문이 들 수 있다.그 이유는 메트릭은 이전부터 엄청난 영향력을 행사한 Prometheus가 Pull방식을 사용하기 때문이고, 나머지는 push방식을 사용하기 때문이다. pull 방식이기 때문에 VMSingle은 클러스터 전체를 돌아다니며 pod를 감시하고, 가져오..

2026. 6. 9.

Monitoring/VictoriaMetrics Stack

이전 포스팅으로 설치에 대한 내용을 진행했었는데, 그때는 길이와 몇가지 사정으로 설치 yaml만 던져주고 끝났었다.이번 포스팅에서는 각 설정파일이 어떠한 동작을 하는지, 또 필요한 수정이 있다면 어떻게 진행하면 되는지 등 좀 자세한 설정을 볼 것이다. 설치 과정이 궁금하다면 포스팅 참고:https://daramu.tistory.com/94 앞서 말하고 싶은 내용은, 데이터 수집은 전적으로 Otel Collector가 담당한다는 것이다.뒤의 log, trace, metric을 담당하는 여러 요소는 "백엔드"로 통칭할 것이며, 각 백엔드의 역할은 데이터 저장과 쿼리문을 제공하여 Grafana에서 조회가가능 하도록 하는 역할이다. 파이프의 중간 라인이라고 보는것도 좋다. 1. VictoriaMetrics..

2026. 6. 9.

Monitoring/VictoriaMetrics Stack

이전 포스팅에서 논의 했던 VictoriaMetrics Stack 을 활용한 모니터링 구축을 진행할 것이다. 쿠버네티스 환경이며, 모든 것은 쿠버네티스 자원을 통해 생성 될 것이다. 구축 순서는 아래와 같다. 1. NS 생성2. VictoriaMetrics Operator 생성3. VMSingle 생성(Metrics 저장소)4. VictoriaLogs 생성(Log 저장소)5. Jeager 생성(Trace 저장소(올인원))6. VMAgent 생성(스크래핑 + 집계)7. OTEL Collector(노드 로그 수집)8. OTEL Collector(게이트웨이)9. Grafana 우선 모든것이 설치될 네임스페이스 먼저 생성핸다.kubectl create ns monitoring 그리고 repo 를 추가한다.hel..

2026. 6. 4.

Monitoring/VictoriaMetrics Stack

이전 모니터링으로 LGTM + OTel 방식을 살펴보았다. 해당 구성은 아래 그림처럼 구성이 된다.여기서 문제점은 mimir, tempo, loki 가 너무 무겁다는 것에 있다.대규모 인프라 환경이라면 모니터링을 위해 메모리를 8기가 이상 사용할 수 있겠지만, 소~중규모, 혹은 프로젝트의 모니터링이라면 부담이 된다. 물론 간단하게 Prometheus + Grafana를 통해 매트릭을 수집할 수 있겠으나, 로그나 트레이스도 수집하고 싶다면 리소스가 부족한 상황이 된다. 이때 사용하기 좋은 것이 VictoriaMetrics Stack이다. 아이디어 자체는 비슷하다. 다만 metrics은 무거운 mimir 대신에 vmagent와 victoriametrics를,log의 경우 무거운 loki 대신에 가벼운 vic..

2026. 6. 4.