DevOps

【홈랩 정비】 ES를 Loki로 바꾸며 Grafana를 더 위대하게..

흑당망고 2026. 8. 20. 20:27

근황

저는 요즘 집에서 쉬었음 청년을 하고 있습니다.

사실 회사에 다니다보면 피로하다는 핑계, 집에서도 회사일을 한다는 핑계를 대면서 홈랩을 정리하는게 여간 쉬운일이 아닌걸 홈랩 관리하시는 분들을 아실거라고 생각합니다.

그래서 이번에 큰맘 먹고 쉬었음이 된 만큼 편하게 한번 홈랩을 재정비를 해보았습니다.

Prometheus 정비

사실 조금 귀찮다는 이유하나로 Prometheus-Stack을 Helm 명령어로 관리하고 있었습니다.

그러다가 이번에 정비를 하면서 Grafana 설정을 건들일이 생겼는데 얼라리? 관리하던 values파일을 잃어먹었더라고요.

안되겠다는 생각이 들어서 이참에 gitops로 이관하였습니다.

기본 설정을 쓰고있던 터라 Empty Dir을 쓰고 있던걸 데이터 유실을 감안하고 편하게 이관하고자 OpenEBS에 연결한 host저장소로 지정하여 이관하였습니다.

이제는 다행히 이렇게 gitops 체제로 관리를하게 되어 정말 다행입니다.

드릴 다운 기능까지 잘 써보고자 grafana의 세부설정까지도 잘 설정해보았습니다.

생각보다 Grafana를 단독으로 띄우는거보다 이렇게 prometheus-stack 차트를 쓰면 편한점이 많더라고요.

추후에도 지원을 할지는 미지수지만 STS의 저장소를 PVC형태로 띄워둔 만큼 마이그레이션은 ArgoCD Annotaion을 이관하면서 한다면 문제 없을 거라고 판단하였습니다.

 

결국 쉬었음 정리 이후에도 편하게 관리 가능한 방향으로 설정 하였습니다.

 

Grafana 고도화 

조금은 쉽지 않은 길이였습니다.

매번 Kibana, Datadog만 사용하던 저라서 그런지 Grafana가 조금은 난잡하게 느껴졌습니다.

 

그래서 생각의 방향을 바꿔보았습니다.

Grafana를 한번 제대로 써보자!

드릴다운이던 익스플로러던 대시보드건 상관없이 말이죠.

 

가장 유명한 기능인 대시보드 기능을 잘 써보기 위해서 우선 values에 prometheus, tempo, loki를 기본적인 data source로 사용할 수 있게 지정을 해주었습니다.

그리고 k8s secret으로 admin 계정을 관리하도록 설정하였습니다.

물론 이건 나중에 하시코프 볼트 등을 홈랩에 적용하여 관리하는게 제일 깔끔할것 같긴합니다...

(사실 그 전에는 values에 비번 하드코딩하고 접속해서 변경하는 형태로 썼습니다. )

 

그 뒤 대시보드를 고도화 해보았습니다.

현재 홈랩에서는 prometheus, blackbox exporter, node-exporter 등을 사용하고 있기 때문에 다양한 메트릭 데이터를 prometheus로 보내고 있는 상황입니다.

그 만큼 표시할 수 있는 데이터가 많다는 의미이기도 하죠.

클로드와 함께 대시보드 json을 만들어서 DevOps 전용 대시보드를 만들었습니다.

Service Latency, Resource Dashboard, FinOps DashBoard 등을 만들었습니다.

이후에는 Alret Manager를 통해서 특정 이상 주기가 탐지되면 슬랙으로 알림을 보내도록 설정까지도 해볼 예정입니다.

여기까지 오니 Grafana에서 제공하는 무료버전의 DataSource가 뭐뭐가 있나 궁금하더라고요.

 

그렇습니다 좀 많더...라고요...?

클라우드 워치도 있는 것을 보고 하이브리드 형태로 Site to Site VPN을 다시 살린다면 꽤나 유용할 것 같다는 생각을 했습니다.

RDS 지표까지도 Grafana에서 본다면 상당히 유용한 형태로 Grafana가 통합 대시보드를 제공할 것 같습니다.

Datadog에서는 이런 Custom Metric을 붙이는게 유료였어서 그런가 적응이 조금은 안되더라고요.

 

아무래도 Fortigate 장비는 API를 제공해서 그런가 데이터소스에 Fortigate도 있는 것을 발견하였습니다..!

하지만 저는 Juniper 장비를 사용하기 때문에 해당 기능은 못쓰는게 조금은 아쉽네요.

물론 junos기반이라서 이를 통해 SNMP 데이터를 받아서 그를 통해 대시보드화 하고 Alert Manager를 엮어서 각 포트별 활성화 상태를 체킹하고 알림을 받아볼 수 있을 것 같습니다.

https://grafana.com/grafana/dashboards/23625-junos-12-3-snmp-prometheus/

 

Junos 12.3+ SNMP Prometheus | Grafana Labs

More detail here : https://www.paulerrington.co.uk/blog/2025/06/29/srx-snmp-prometheus.html HOWTO: Install prometheus-snmp-exporter (tested working on 0.19.0).Download the MIBS from juniper networks to /usr/share/snmp/mibs.Setup a generate.yml. modules: sr

grafana.com

실제로 이런 것을 제공하네요!

 

ES를 버리고 이제는 Loki로...

사실 ES를 썼던건 회사에서 사용하기도하고 개인적으로 관심이 갔던 스택이였기 때문이였습니다.

하지만 ES를 쓰면서 겪은 여러 귀찮은 일들을 생각하니 홈랩에서까지 이 귀찮은 일을 벌이고 싶지 않아졌습니다..

또한 리소스가 불필요하게 혼자 노드의 절반 가까이를 기본적으로 먹을만큼 JVM Heap의 비중이 컸는데요.

생각하다보니 진절머리가 나서 결국 Loki로 넘어가게 되었습니다.

과거에는 eck-operator + elk-stack까지해서 CRD의존성과 귀찮은 State관리를 위한 LifeCycle 제약까지 생기면서 홈랩에서 해야하는 가벼운 오퍼레이션에 병목지점을 많이 느꼈습니다.

 

이제는 Loki로 넘어가면서 ES의 특장점인 로그 전문 인덱싱을 통해 얻었던 속도적인 측면에선 손해를 볼 수 있을 줄 알았습니다.

하지만 생각해보니 어짜피 보던 필드들은 분명히 한정적으로만 존재했었고, 해당 필드들은 Loki의 라벨링을 통해 인덱싱을해버리면서 해결이 가능했습니다.

당연히 어그리게이션과 같은 기능을 많이 놔줌으로서 복합 쿼리의 성능이 낮아졌지만, 이 또한 한마디로 정리가 가능했습니다.

'어짜피 홈랩인데 그렇게 많은 성능이 필요해?'

당연히 그정도는 아니기에 Loki로 가는 것이 이득이라고 판단했습니다.

(최소 4기가에서 6기가씩 주면서 사용했던 ES인 만큼 오퍼레이션을 해야하는 일이 생길때마다 상당히 기분이 나빴던것도 있긴 했지만요.)

 

그리고 동시에 ELK 생태계에서 벗어난 만큼 Grafana에서 보게 될텐데 이걸 굳이 드릴다운이나 익스포터에서 하나씩 쿼리해서 찾는건 엄청난 비효율이라고 생각했습니다.

그렇습니다. 또 AI와 함께 대시보드로 만들어버렸습니다.

사실 현재는 Backend 수량이 많지 않아서 Tempo는 사실상 잉여로 쓰이고 있습니다.

하지만 쉬었음을 하면서 Go, Ruby 등을 통해 Backend Application을 고도화해서 연결할 것이기 때문에 각각에서 일어나는 상황을 모두 한눈에 볼 수 있는 통합 관리 솔루션이 필요하긴 했었습니다.

Kubecost에서 OpenCost로 Grafana를 더 위대하게..

난 사실 AWS 대비 홈랩이 어느정도의 득을 불러오는지가 매번 궁금했었습니다.

아무래도 온프렘 환경은 클러스터링과 같은 기법을 쓰지 않는한 HA같은 장점을 챙기기에 조금은 제약적인 환경이기 때문이기도 했습니다.

(대기업식을 말하는게 아니라 홈랩 수준을 말하는 거긴 하지만요..)

그런 트레이드 오프로 얻는 실질적인 금액을 가시적으로 보고자 올해 초 Kubecost를 홈랩에 도입하였습니다.

 

그런데 이친구 방치해두었더니 생각보다 리소스를 많이 먹었었더라고요??

야금야금 먹다니...가난한 쉬었음 청년으로서 이런 불의를 보고있자니 용서할 수 없었고 바로 척결을 시작했습니다.

커밋메세지는....실수로....이전꺼를 그대로 써버렸습니다...ㅎㅎ

이젠 Outdated 시켜버리고 application.yaml도 주석처리하고 죄다 지워버렸습니다.

물론! 지우기전 대책도 생각했습니다.

Kubecost는 기본적으로 IBM에서 제공하는 솔루션 입니다.

유료버전이 아닌 경우 어느정도 제약사항이 존재합니다. 자체적인 분석도 진행하고 말이죠.

어짜피 저는 Data-Driven한 의사결정을 할 정도로 중요한 데이터를 보는게 아닌 만큼 커스텀 가격을 입력해서 분석할만한 대체제인 OpenCost를 도입하였습니다.

 

결국 또 선택 사유에는 Prometheus와 Grafana가 있었습니다.

이 두가지를 사용가능한 이유는 OpenCost도 Prometheus를 사용하고 이를 사용한다면? Grarana에서 대시보드화도 가능하기 때문입니다!

위에 설명했던 FinOps 대시보드는 이렇게 만들어진 것 입니다.

자체적으로 대시보드도 제공하지만 저는 이젠 Grafana에 모든걸 담기로 했습니다.

저는 Golden Path를 지향하는 철학을 기반으로 엔지니어링을 하기 때문에 기술스택이 불필요하게 분산되는 것을 무척 싫어합니다.

물론 그와 트레이드 오프 할 정도로 괜찮은 성능과 리소스 가성비가 있다면 그를 선택하곤 하지만요.

(그 결과가 바로 Vector를 로그 수집기이자 Ingest 목적으로 쓴다는 점 입니다...ㅎㅎ..)

결론

자원도 아끼고 새로운 스택도 추가하고 Grafana의 생태계 친화적인 모습까지 알 수 있던 정말 값진 시간이였습니다.

물론 쉬었음 하는 동안 계속 고도화 할거라서 이게 끝은 아닐 것이지만 그래도 이번만큼 대공사 할일은 적었으면 좋겠네요...

부디 제 눈에 띄는 문제점이 없길 바랍니다...ㅜㅜ