▲

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

 (henrikgerdes.me)
17P by GN⁺ 3일전 | ★ favorite | 댓글 6개
  • 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 1일전  [-]

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

답변달기
▲
dongho42 1일전  [-]

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

답변달기
▲
cysl0 1일전  [-]

대안이 딱히 없긴 하네요

답변달기
▲
jindol9177 1일전  [-]

그라파나가 Labs를 운영하면서 기존 지표 이상으로 활용할 기회를 주고 위탁 관리 서비스로 관리 매니저를 운영하면서 많은 부분이 나아졌으나, 10. X.X 버전 이후로는 플러그인 의존성과 오픈소스로서 여러 문제점이 발생하고 있음.
메이저 버전으로 올리면 차트에서 호환되었던 데이터의 불러오기 형식이 바뀐다든지, 기존 시계열 데이터를 사용하기 위해 플러그인(influx db, 프로메테우스 등)을 붙여서 빠르게 표기할 수 있는 장점이 있지만 데이터 테이블을 호출할 경우, 이전 버전과 상이하게 불러오거나 지표의 시간대가 바뀌는 등의 문제가 발생함.
지금은 타 오픈소스 모니터링과 모니터링 솔루션에 비하면 알람도, 대시보드도, 사용자 관리 패널 기능 그 어떤 것도 버전이 올라가면서 나아지는 것이 없음. 또한 메이저 버전이 올라가면서 신규 기능이랑 UI를 매번 새로 만들어놔서 "이게 뭐 하는 짓이지?"라는 의문을 남길 수밖에 없음.
개발 단계의 간단한 기능 모니터링이랑 지표를 보기에는 좋지만, 시계열 데이터나 관리 데이터는 차라리 클라우드 종속형 서비스(Time stream 등) 이나 그냥 프로메테우스 쓰는 게 나을 것으로 보임.

답변달기
▲
savvykang 1일전  [-]

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

답변달기
▲
GN⁺ 3일전  [-]
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은 수집기 교체와 재구성을 요구하는 셈임
답변달기