▲

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

 (henrikgerdes.me)
22P 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 3달전  [-]

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

답변달기
▲
dongho42 3달전  [-]

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

답변달기
▲
cysl0 3달전  [-]

대안이 딱히 없긴 하네요

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