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

• 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는 새로운 관리 시스템 도입으로 더 찾기 어려워짐
• 주요 구성 요소의 업그레이드·폐기 주기가 빨라 “지루하고 안정적인 모니터링”을 원하는 조직과 맞지 않음
• 기술 자체의 문제보다 제품 관리 방식과 빠른 변화 속도가 신뢰성을 떨어뜨리는 핵심 요인으로 작용함

[ifmkl]

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

[dongho42]

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

[cysl0]

대안이 딱히 없긴 하네요

[savvykang]

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

[GN⁺]

Hacker News 의견

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

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

• Mimir는 완전히 다른 규모의 메트릭을 처리하도록 설계된 시스템임
  그 수준에서는 Kafka가 실제로 필요함
  하지만 대부분의 사용자는 그 정도 확장성이 필요하지 않음
  전용 Kubernetes 클러스터에서 Mimir를 돌리지 않는다면, 과도하게 설계된 셈임
  그냥 Prometheus를 쓰는 게 현실적임

  • Victoria Metrics를 추천함
    단일 인스턴스 모드에서도 놀라울 만큼 잘 작동하고, 확장도 매우 쉬움
    여러 조직과 개인 프로젝트에서 써봤는데 항상 만족스러웠음
  • “동급의 오픈소스 확장성은 없다”고 단정하는 표현이 재밌음
    하지만 AWS의 Amazon Managed Prometheus는 Cortex 기반이고, OpenObserve도 이미 페타바이트 단위로 운영 중임
  • 작은 앱의 모니터링에는 어떤 솔루션을 선호하는지 궁금함
    단일 바이너리로 배포가 간단하고, OpenTelemetry와 호환되며, 나중에 다른 OTEL 제공자로 옮길 수 있는 게 이상적임

• OTEL 기반으로 새 솔루션을 만든다면 Prometheus/Grafana의 대안으로 어떤 게 가장 유망할지 궁금함

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

• 왜 개발자들이 매주 세팅을 바꾸며 최신 기술을 쫓는지 모르겠음
  나는 2017년부터 Grafana + Prometheus 조합을 써왔고, 지금도 잘 작동함
  1~2년에 한 번 LTS 버전으로만 업데이트함
  대시보드는 여전히 완벽하고, 아무 문제도 없음
  대부분의 사람에게는 이 지루하지만 안정적인 조합이 최선임

  • Angular 지원이 중단됐을 때는 어떻게 처리했는지 궁금함
    혹시 구버전을 그대로 쓰고 있는 건지 묻고 싶음

• 오픈소스에서 Grafana를 대체할 수 있는 대시보드 빌더가 있을까? 회사에서도 Grafana를 광범위하게 사용 중임

  • Perses가 가장 유망한 대안으로 보임
    아니면 Prometheus 콘솔 템플릿이나 VictoriaMetrics 내장 대시보드를 쓸 수도 있지만, 기능은 훨씬 제한적임
  • 글쓴이의 불만은 Grafana 자체보다는 그 회사의 다른 제품군에 대한 것 같음
    Grafana 대시보드 자체는 VictoriaMetrics + ClickHouse 조합으로 쓸 때 꽤 쾌적함
  • 예전엔 Grafana 이전에도 여러 FOSS 대안이 있었지만 대부분 사라졌음
    RRD, Nagios 같은 이름만 어렴풋이 기억남
  • OpenSearch Dashboards도 대안이지만, 순수 시각화 용도로는 여전히 Grafana가 더 나음
  • 우리는 Graylog + ElasticSearch 조합으로 Loki 스택을 완전히 대체함

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

  • PromQL 문제는 Grafana보다는 Prometheus의 책임임

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

• SigNoz는 좋은 선택이며 활발히 개발 중임

  • 나도 SigNoz에 동의함
    예전엔 클라우드 관측 플랫폼에 큰 비용을 썼는데, 지금은 Hetzner 박스에 self-hosted SigNoz를 올려 월 $10로 해결함

• Prometheus와 Grafana가 각각 풀스택 솔루션을 지향하다가 OTEL이 등장하면서 판이 복잡해졌음

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