# Grafana를 더 이상 추천할 수 없는 이유

> Clean Markdown view of GeekNews topic #24399. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=24399](https://news.hada.io/topic?id=24399)
- GeekNews Markdown: [https://news.hada.io/topic/24399.md](https://news.hada.io/topic/24399.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2025-11-17T04:37:22+09:00
- Updated: 2025-11-17T04:37:22+09:00
- Original source: [henrikgerdes.me](https://henrikgerdes.me/blog/2025-11-grafana-mess/)
- Points: 22
- Comments: 6

## Summary

최근 커뮤니티에서는 **Grafana 제품군의 잦은 구조 변경과 호환성 문제**가 장기 운영의 가장 큰 리스크로 지적되고 있습니다. Grafana Agent에서 **Alloy로의 전환**, Mimir 3.0의 **Kafka 의존성 추가**, 그리고 Prometheus Operator와의 **CRD 비호환성**까지 겹치며, 한 번 구축한 모니터링 스택을 안정적으로 유지하기가 점점 어려워졌습니다. 빠른 혁신보다 **예측 가능한 운영과 신뢰성**을 중시하는 팀이라면, 이제 Grafana 생태계를 재검토할 시점일지도 모릅니다. 개인적으로는 “지루할 정도로 안정적인 모니터링”이야말로 진짜 프로덕션의 미덕이라는 점을 다시 떠올리게 됩니다.

## Topic Body

- Grafana 제품군은 **짧은 주기로 주요 구성요소를 잦게 폐기하거나 교체**해 장기 운영이 어려운 구조를 만듦  
- 새 솔루션 도입 시마다 **구성 방식, DSL, Helm 차트, Operator 등이 반복적으로 바뀌어** 안정적 유지보수가 힘든 환경이 됨  
- Prometheus Operator 생태계와 **CRD 호환이 완전하지 않아**, ServiceMonitor·PodMonitor는 되지만 AlertmanagerConfig 등 핵심 기능은 지원 공백이 발생함  
- Mimir 3.0은 **Apache Kafka 의존성을 강제로 추가해** 클러스터 복잡성과 운영 부담을 크게 높임  
- Grafana Cloud와 Mimir·Loki·Grafana 제품군 전반에서 **설정 위치·엔드포인트가 변경되기 쉬워**, 한 번 구축해 오래 쓰기 힘든 구조가 반복됨  
  
---  
### Grafana 제품군의 잦은 구조 변경  
- Grafana Agent, Flow Mode, OnCall 등 핵심 기능들이 **1–3년 안에 폐기·대체**되는 일이 반복됨  
  - Angular 기반 Grafana UI는 React로 전환되며 기존 대시보드 상당수가 깨짐  
  - Helm 차트 중 일부는 더 이상 유지보수가 이뤄지지 않음  
  
### Alloy 도입으로 인한 복잡성 증가  
- All-in-one을 표방한 **Grafana Alloy**가 기존 Agent를 대체했으나 안정성 초기 문제가 존재했음  
  - 자체 DSL(HCL 유사)을 사용해 기존 YAML 기반 흐름과 단절  
  - Alloy Operator까지 추가되면서 구성 요소는 더 복잡해짐  
  
### Prometheus Operator 생태계와의 불완전한 정합성  
- K8s 모니터링 표준인 `ServiceMonitor`, `PodMonitor`는 지원하지만  
  - `PrometheusRules`는 추가 설정 필요  
  - `AlertmanagerConfig`는 미지원  
  - Mimir가 자체 Alertmanager를 사용해 **버전 차이와 세부 비호환성**이 생김  
  
### Mimir 3.0의 Kafka 의존성 도입  
- 기존보다 더 높은 확장성을 목표로 했지만  
  - 핵심 구성에 **Kafka를 필수로 추가하며 운영 난이도**가 크게 상승  
  - 단일 Helm 설치 → 다중 컴포넌트 조율로 복잡성이 기하급수적으로 증가함  
  
### 안정적 사용이 어려운 생태계  
- Grafana Cloud ingestion endpoint는 새로운 관리 시스템 도입으로 더 찾기 어려워짐  
- 주요 구성 요소의 업그레이드·폐기 주기가 빨라 “**지루하고 안정적인 모니터링**”을 원하는 조직과 맞지 않음  
- 기술 자체의 문제보다 **제품 관리 방식과 빠른 변화 속도**가 신뢰성을 떨어뜨리는 핵심 요인으로 작용함

## Comments



### Comment 46485

- Author: ifmkl
- Created: 2025-11-18T14:59:20+09:00
- Points: 1

influxdb에서 기본 제공하는 대시보드도 나름 간단하게는 쓸만함다

### Comment 46481

- Author: dongho42
- Created: 2025-11-18T13:10:42+09:00
- Points: 1

Grafana가 별로라는 점에 대해서는 공감하는데 Grafana만큼 여러 Datasource를 지원하는 솔루션 다른거 추천할만한게 있을까요?

### Comment 46484

- Author: cysl0
- Created: 2025-11-18T14:26:31+09:00
- Points: 1
- Parent comment: 46481
- Depth: 1

대안이 딱히 없긴 하네요

### Comment 46472

- Author: [deleted]
- Created: 2025-11-18T10:32:41+09:00
- Points: 1

[삭제된 댓글입니다]

### Comment 46475

- Author: savvykang
- Created: 2025-11-18T12:03:54+09:00
- Points: 1
- Parent comment: 46472
- Depth: 1

그라파나에도 승진이나 이력서 장식을 하고 싶은 분들이 많았나보네요

### Comment 46380

- Author: neo
- Created: 2025-11-17T04:37:23+09:00
- Points: 1

###### [Hacker News 의견](https://news.ycombinator.com/item?id=45934940) 
- 나도 글쓴이와 같은 이유로 **Grafana를 완전히 버릴까** 진지하게 고민 중임  
  매년 대시보드를 다시 만들고, 알림을 재설정하고, 새 기능을 따라가야 하는 게 지침  
  그냥 서비스가 죽었을 때만 알려주면 좋겠고, 데이터소스나 메트릭이 바뀌지 않는 한 10년 동안 같은 대시보드 정의를 유지하고 싶음  
  예전엔 사이드바에 주요 링크 4~5개만 있었는데, 지금은 메뉴 안의 서브메뉴가 너무 많아서 기본 기능(대시보드, 알림)을 찾기도 힘듦  
  한 달에 한 번쯤 보는 UI를 매번 새로 배워야 하는 게 너무 비효율적임  

- 서비스 수명이 2~3년밖에 안 되는 상황에서 여러 제품을 쌓아올리면, 결국 **기술 부채의 산**만 커지는 느낌임  
  분기마다 뭔가 큰 걸 교체해야 하는 현실이 고통스러움  

- Mimir는 완전히 다른 규모의 메트릭을 처리하도록 설계된 시스템임  
  그 수준에서는 Kafka가 실제로 필요함  
  하지만 대부분의 사용자는 그 정도 **확장성**이 필요하지 않음  
  전용 Kubernetes 클러스터에서 Mimir를 돌리지 않는다면, 과도하게 설계된 셈임  
  그냥 Prometheus를 쓰는 게 현실적임
  - [Victoria Metrics](https://victoriametrics.com/)를 추천함  
    단일 인스턴스 모드에서도 놀라울 만큼 잘 작동하고, **확장도 매우 쉬움**  
    여러 조직과 개인 프로젝트에서 써봤는데 항상 만족스러웠음
  - “동급의 오픈소스 확장성은 없다”고 단정하는 표현이 재밌음  
    하지만 AWS의 Amazon Managed Prometheus는 Cortex 기반이고, **OpenObserve**도 이미 페타바이트 단위로 운영 중임  
  - 작은 앱의 모니터링에는 어떤 솔루션을 선호하는지 궁금함  
    **단일 바이너리**로 배포가 간단하고, OpenTelemetry와 호환되며, 나중에 다른 OTEL 제공자로 옮길 수 있는 게 이상적임  

- OTEL 기반으로 새 솔루션을 만든다면 Prometheus/Grafana의 대안으로 어떤 게 가장 유망할지 궁금함  
  - 우리도 kube-prometheus-stack으로 시작했지만 PromQL이 마음에 들지 않았음  
    로그와 트레이스를 처리하려면 복잡한 구성요소가 더 필요했음  
    그래서 [GreptimeDB](https://github.com/GreptimeTeam/greptimedb)를 찾았고, **메트릭·로그·트레이스 통합 처리**가 가능함  
    OpenTelemetry로 수집하고 Grafana로 시각화함  
    SQL로 대시보드를 만들 수 있어서 팀 역량과 잘 맞음  
    단순한 구조 덕분에 플랫폼 엔지니어로서 만족스러움  
  - [OpenObserve](https://github.com/openobserve/openobserve)를 추천함  
    Grafana와 Elastic의 복잡함을 해결하기 위해 만들어졌고, **단일 컨테이너로 로그·메트릭·트레이스·대시보드·알림**을 모두 처리할 수 있음  
    (작성자는 OpenObserve의 메인테이너임)  
  - 최근 회사에서는 Grafana에서 **SigNoz**로 전환 중임  
    오픈소스이고 활발히 개발 중이며, 팀 커뮤니케이션도 좋음  
  - [SigNoz](https://github.com/SigNoz/signoz)는 **OpenTelemetry-native** 오픈소스임  
    여러 백엔드를 직접 다뤄야 하는 Grafana의 복잡함을 피하려는 사용자들이 많이 옮겨옴  
    (작성자는 SigNoz 메인테이너임)  

- 왜 개발자들이 매주 세팅을 바꾸며 **최신 기술을 쫓는지** 모르겠음  
  나는 2017년부터 Grafana + Prometheus 조합을 써왔고, 지금도 잘 작동함  
  1~2년에 한 번 LTS 버전으로만 업데이트함  
  대시보드는 여전히 완벽하고, 아무 문제도 없음  
  대부분의 사람에게는 이 **지루하지만 안정적인 조합**이 최선임
  - Angular 지원이 중단됐을 때는 어떻게 처리했는지 궁금함  
    혹시 구버전을 그대로 쓰고 있는 건지 묻고 싶음  

- 오픈소스에서 Grafana를 대체할 수 있는 **대시보드 빌더**가 있을까? 회사에서도 Grafana를 광범위하게 사용 중임  
  - [Perses](https://perses.dev/)가 가장 유망한 대안으로 보임  
    아니면 Prometheus 콘솔 템플릿이나 VictoriaMetrics 내장 대시보드를 쓸 수도 있지만, 기능은 훨씬 제한적임  
  - 글쓴이의 불만은 Grafana 자체보다는 그 회사의 다른 제품군에 대한 것 같음  
    Grafana 대시보드 자체는 **VictoriaMetrics + ClickHouse** 조합으로 쓸 때 꽤 쾌적함  
  - 예전엔 Grafana 이전에도 여러 FOSS 대안이 있었지만 대부분 사라졌음  
    RRD, Nagios 같은 이름만 어렴풋이 기억남  
  - [OpenSearch Dashboards](https://github.com/opensearch-project/OpenSearch-Dashboards)도 대안이지만, 순수 시각화 용도로는 여전히 Grafana가 더 나음  
  - 우리는 **Graylog + ElasticSearch** 조합으로 Loki 스택을 완전히 대체함  

- Grafana의 **끊임없는 변화**가 오히려 익숙해지게 만들었음  
  매 major release마다 대시보드가 깨지거나 UI가 바뀌지만, 그냥 그러려니 하게 됨  
  진짜 문제는 Prometheus의 **PromQL 락인**임  
  메트릭 이름을 바꾸면 모든 규칙과 알림, 대시보드를 수정해야 함  
  PromQL은 문법 오류 외에는 에러를 거의 안 내서, [pint](https://github.com/cloudflare/pint) 같은 도구로 검증해야 함
  - PromQL 문제는 Grafana보다는 Prometheus의 책임임  

- 단일 서버 배포 시에는 Prometheus Pushgateway + Grafana를 **docker-compose 템플릿**으로 자주 씀  
  간단하고 잘 작동하지만, 메트릭 양이 커지면 복잡도가 폭발함  
  Prometheus가 더 효율적인 **전송 포맷**을 유지했다면 이런 문제는 덜했을 것임  
  텍스트 포맷 대신 compact한 **binary metric format**이 있었다면 수백만 단위의 라벨도 무리 없이 처리했을 것임  

- [SigNoz](https://github.com/SigNoz/signoz)는 좋은 선택이며 활발히 개발 중임  
  - 나도 SigNoz에 동의함  
    예전엔 클라우드 관측 플랫폼에 큰 비용을 썼는데, 지금은 Hetzner 박스에 **self-hosted SigNoz**를 올려 월 $10로 해결함  

- Prometheus와 Grafana가 각각 **풀스택 솔루션**을 지향하다가 OTEL이 등장하면서 판이 복잡해졌음  
  - 아직 OTEL이 오픈소스 모니터링 스택에서 어떻게 자리 잡는지 완전히 이해하지 못했음  
    OTEL은 메트릭·트레이스·로그용 프로토콜이지만, 이를 지원하는 단일 DB는 없음  
    대부분은 Prometheus(메트릭) + OpenSearch(로그)를 조합함  
    결국 OTEL은 **수집기 교체와 재구성**을 요구하는 셈임