Prometheus·Grafana 대안: 자체 운영 확장과 관리형 전환의 기준

Prometheus와 Grafana로 온콜 업무를 잘 수행하고 있다면 화면을 바꾸기 위해 이전할 이유는 크지 않습니다. 지표 용량이 부족하면 백엔드부터 확장하고, 저장소·업그레이드·복구를 지속적으로 맡을 사람이 없다면 관리형 서비스를 살펴보는 편이 좋습니다. 플랫폼 전체를 바꿀 만한 경우는 데이터가 있는데도 장애가 날 때마다 여러 시스템에서 같은 사건의 맥락을 다시 조합해야 할 때입니다.

Prometheus와 Grafana는 서로 보완하는 도구입니다. Prometheus는 지표 수집·저장·쿼리와 recording rule, 알림 규칙 평가를 맡습니다. Grafana는 데이터 소스에 연결해 탐색, 대시보드와 알림을 제공합니다. Prometheus·Grafana 대안을 비교할 때는 수집, 저장, 조사 과정 중 어느 부분을 바꾸려는지부터 정해야 합니다. Grafana만 교체한다고 지표 백엔드까지 바뀌지는 않습니다. Prometheus 아키텍처, Grafana 데이터 소스

Guance 편집팀 · 2026년 10월 28일. 공식 자료를 바탕으로 자체 운영과 관리형 서비스의 엔지니어링 선택을 설명합니다. Guance도 후보 중 하나입니다. 계산은 명시한 가정이며 운영 성능 시험이나 고객 절감액이 아닙니다.

운영 방식이 달라져야 하는 계층부터 찾기

장기 보존이나 멀티클러스터 쿼리가 문제라면 Thanos, Mimir, VictoriaMetrics 같은 지표 백엔드를 먼저 검토할 수 있습니다. 기존 exporter, PromQL과 Grafana 사용 방식을 유지할 여지가 있습니다. 대신 선택한 구성 요소의 용량, 가용성, 업그레이드와 복구는 계속 플랫폼 팀이 책임집니다. 각 프로젝트의 아키텍처와 호환 범위가 다르며, 지표를 받는 것만으로 로그·트레이스·사용자 경험까지 모두 갖춰지지는 않습니다.

Grafana를 유지하면서 백엔드 운영을 줄이고 싶다면 Grafana Cloud나 적절한 클라우드 관리형 Prometheus를 비교할 수 있습니다. Grafana Cloud와 자체 운영 LGTM은 제공 방식이 다릅니다. Loki, Grafana, Tempo, Mimir로 다중 신호 스택을 구성해도 직접 운영한다면 각 구성 요소를 업그레이드하고 복구해야 합니다. Elastic Observability와 Guance 같은 더 넓은 플랫폼에서는 신호 간 조사 흐름과 실제 제공 범위가 선택의 중심이 됩니다.

선택에 따라 달라지는 것은 지속적으로 해야 할 일입니다. Prometheus는 Apache 2.0, Grafana OSS는 AGPLv3 라이선스를 사용합니다. 선택한 배포판, 플러그인과 추가 제품에는 각자의 조건이 있습니다. 직접 설치할 수 있다는 사실이 운영과 통합 비용까지 없애 주지는 않습니다. Prometheus 라이선스, Grafana 라이선스

단가를 비교하기 전에 시계열과 수집 간격 계산하기

높은 카디널리티는 데이터와 함께 이동합니다. 요청 ID나 사용자 ID를 지표 라벨로 넣으면 라벨 값 조합에 따라 시계열이 계속 늘 수 있습니다. 더 큰 백엔드로 옮겨도 어떤 차원이 필요한지 정하는 일은 남습니다. Prometheus 데이터 모델

단순한 가정을 해 보겠습니다. 서비스 20개에 각각 경로 10개, 상태 5개가 있고, 모든 조합을 Pod 8개가 하나의 스칼라 지표로 실제 생성한다면 20 × 10 × 5 × 8 = 8,000개 시계열입니다. 15초마다 수집하면 분당 약 32,000개, 60초마다 수집하면 약 8,000개 샘플입니다. 시계열 수는 같지만 샘플 수는 4분의 1이 됩니다. 재시작, 시계열 교체, 히스토그램과 복제본을 제외한 정상 상태의 예입니다.

차원을 없애면 그 기준으로 데이터를 나눠 볼 수 없고, 간격을 늘리면 시간 해상도가 낮아집니다. 실제 쿼리와 알림 시간 창에서 이 차이를 받아들일 수 있는지 판단해야 합니다. 조사에 쓰지 않는 차원은 미리 집계하거나 필터링할 수 있지만, Pod 단위의 원인 분리가 필요하면 해당 데이터를 남겨야 합니다.

Grafana Cloud Metrics는 활성 시계열과 분당 데이터 포인트 수(DPM)를 과금에 반영합니다. 다른 서비스는 다른 단위를 사용할 수 있어 바이트, 시계열, 데이터 포인트를 그대로 환산할 수 없습니다. 전송 범위, 빈도, 보존 기간과 필요한 쿼리를 맞춘 뒤 관리형 서비스 비용을 비교해야 합니다. Grafana Cloud 지표 과금

remote write를 연결해도 규칙과 과거 데이터는 별도로 남는다

Prometheus server는 remote write 대상마다 큐를 유지하고 WAL에서 샘플을 읽어 샤드별로 전송합니다. 수신 측이 느려지면 미전송 데이터가 쌓입니다. 로컬 쿼리가 성공해도 원격 저장소가 최신 상태라는 뜻은 아닙니다. 복구 후에는 새로 들어오는 데이터보다 빠르게 전송해야 하며 WAL도 무제한 오프라인 보관소가 아닙니다. remote write 큐와 복구

기존 수집을 유지할 이유가 여기에 있습니다. 모든 exporter를 교체하기 전에 목적지를 바꿀 수 있습니다. 다만 저장된 과거 데이터, recording rule, 알림 규칙과 Grafana 대시보드는 별도 자산이므로 각각 유지, 가져오기 또는 재구축 경로를 정해야 합니다.

HA 복제본도 주의할 부분입니다. Grafana Cloud Metrics는 기본적으로 cluster와 __replica__로 HA Prometheus 데이터를 식별해 중복을 제거합니다. 복제본끼리는 같은 cluster 값을 쓰고 replica 값은 서로 다릅니다. 이는 수신 측의 규칙이며 remote write 프로토콜이 모든 백엔드에 보장하는 동작은 아닙니다. 수신 측을 바꿀 때 복제본 식별, 중복 제거 방식과 실제 수신 시계열을 함께 확인해야 합니다. Grafana Cloud HA 수집

Guance는 DataKit Prometheus Remote Write 수신기를 제공해 기존 수집 경로를 이어갈 수 있습니다. 필드 매핑은 미리 정해야 합니다. measurement 등 이름 설정을 덮어쓰지 않은 기본 구성에서는 go_memstats_heap_objects가 measurement go와 필드 memstats_heap_objects로 나뉘며, keep_exist_metric_name = true로 원래 전체 필드명을 유지할 수 있습니다. 샘플을 받은 뒤에도 기존 쿼리의 이름과 필터를 새 모델에 맞춰야 합니다. MetricsQL 쿼리도 제공하지만 호환 구문이 있다는 사실만으로 실제 결과까지 같다고 볼 수는 없습니다.

조사 흐름을 잇는 것은 화면과 데이터 규칙이다

Grafana는 여러 데이터 소스에 연결할 수 있고 Prometheus 데이터 소스에는 exemplar에서 트레이스로 이동하는 링크도 설정할 수 있습니다. 이미 적절한 로그·트레이스 백엔드, 안정적인 식별자와 작동하는 링크가 있다면 전체 이전보다 현재 구성을 다듬는 편이 쉬울 수 있습니다. Grafana Prometheus 데이터 소스 설정

지속적인 연계 작업은 서비스명, 환경, 시간 범위와 권한을 시스템마다 맞추는 데 있습니다. 오류율 알림의 service로 같은 서비스의 로그를 고를 수 있는지, 로그의 trace_id가 아직 보존 중인 Trace로 이어지는지가 조사 경로의 사용성을 결정합니다.

Guance 워크스페이스는 지표, 로그, 트레이스와 RUM을 받을 수 있고 트레이스 상세에 관련 데이터로 이어지는 진입점이 있습니다. 식별자가 일치하고 필요한 데이터가 이미 수집돼 조회 가능한 상태라면 그 경로로 조사를 이어갈 수 있습니다. 팀이 개별 링크와 여러 백엔드를 직접 유지하는 일을 줄일 수 있지만 필드와 보존 정책은 계속 정해야 합니다. 수집하지 않은 요청을 플랫폼 통합만으로 복원할 수는 없습니다. 로그와 트레이스 연계

AI 지원도 같은 데이터 경로 안에서 사용해야 합니다. Obsy Agent Teams는 설정된 도구와 허용된 데이터로 작업해 조사를 진행할 수 있습니다. 인용한 이벤트, 필터와 시간 범위는 사람이 확인할 수 있어야 합니다. 도구 접근에 성공한 것과 행동으로 옮길 근거 있는 원인을 찾은 것은 다른 결과입니다. Agent Teams 작업

알림 자산과 반복 비용으로 이전 범위 결정하기

Alertmanager에는 중복 제거, 그룹화, 라우팅, 알림 일시 중지(silence)와 억제(inhibition) 기능이 있습니다. 클러스터 장애로 하위 알림이 늘면 inhibition으로 중복 통지를 줄일 수 있습니다. 담당, 임계값과 경로 설정이 잘못됐다면 이전 후에도 고쳐야 합니다. 알림 수만 줄이기보다 대응이 필요한 알림과 처리 지침을 보존해야 합니다. Alertmanager

대시보드도 용도에 따라 남깁니다. 최근 90일간 열지 않았다는 이유만으로 재해 복구나 규정 준수 모니터링을 삭제해서는 안 됩니다. 이전하는 쿼리는 단위, 집계, 누락 데이터와 시간 창의 의미를 유지해야 합니다. 알림에는 평가 주기, 대기 시간과 통지 경로도 포함됩니다.

첫해 비용을 다음과 같이 나눌 수 있습니다.

첫해 투입 비용
= 12 × (플랫폼 요금 + 고객 측 수집 자원 비용
        + 네트워크 비용 + 남아 있는 운영 비용)
+ 일회성 이전 비용
+ 전환 기간의 추가 지출

엔지니어링 시간과 현금 지출은 따로 기록합니다. 병행 운영은 정상 운영 구성을 넘는 추가 비용만 계산해 중복을 피합니다. Guance도 선택한 플랜의 수집, 처리, 저장과 컴퓨팅 항목을 맞춰 견적을 받아야 하며 지표 단가 하나로 전체 비용을 나타낼 수는 없습니다. Guance Enterprise 과금

주된 제약이 지표 백엔드라면 먼저 백엔드를 확장합니다. Grafana를 유지하면서 백엔드 운영을 줄이고 싶다면 적절한 관리형 서비스부터 살펴봅니다. 여러 신호의 조사와 분산 시스템 유지에 팀 시간이 계속 소모된다면 Guance 같은 통합 플랫폼을 더 넓은 대안으로 비교할 가치가 있습니다. 실제로 중단할 수 있는 기존 구성 요소, 유지할 조사 역량과 반복 비용이 이전 범위를 결정합니다.