promkr 뉴스레터 2025년 6월호

이 호에 실린 소식 12개의 원문을 읽고 요약했습니다. 뉴스레터 설명이 아니라 링크가 가리키는 글의 내용을 기준으로 썼습니다. 한 해 전체의 흐름은 2025년 소식에 있습니다.

1. Git Sync로 관리하는 Grafana 대시보드

원문: Grafana dashboards as code: How to manage your dashboards with Git · Roberto Jiménez Sánchez, Fabrizia Rossano · 2026-04-22

Grafana Labs는 UI에서 대시보드를 편집하면서 Git의 변경 이력과 승인 절차를 사용할 수 있도록 Git Sync를 만들었습니다. 대시보드 수가 늘면 UI만으로 변경을 추적하기 어렵고, 별도 코드 관리 체계는 설정과 관리자 부담이 커진다는 문제에서 출발했습니다. 제공된 글은 2025년 5월 최초 게시 후 2026년 4월 갱신된 판본으로, Grafana 13에서 정식 출시된 Git Sync를 설명합니다.

Git Sync는 Git wire protocol 버전 2와 호환되는 저장소를 연결하는 범용 pure Git 방식과 GitHub·GitLab·Bitbucket 전용 연동을 제공합니다. 범용 방식은 표준 Git을 사용하지만 웹훅이나 PR 자동화 같은 공급자별 기능은 제공하지 않습니다. 전용 연동은 API를 사용해 즉시 동기화, PR 댓글, 직접 연결 링크 등을 추가합니다.

저장소 연결을 설정하면 Grafana의 저장 과정에서 대시보드 변경을 저장하고 PR을 열 수 있습니다. 편집한 대시보드는 편집자 또는 PR의 미리보기 링크에서 확인하며, main에 병합하면 모두에게 공개됩니다. Grafana는 PR에 원본과 미리보기 링크를 댓글로 남기고, 온프레미스 버전에서는 변경 전후 스크린샷도 제공합니다. PR을 병합하면 변경 내용이 Grafana에 자동으로 동기화됩니다.

글은 모든 Grafana 에디션에서 Git Sync를 사용할 수 있다고 밝히며, 소수의 대시보드부터 점진적으로 적용하도록 권합니다. 연결된 폴더와 대시보드의 기준 데이터는 Git에 있습니다. 연결 설정을 삭제하면 해당 대시보드가 Grafana 인스턴스에서 사라지지만, Git 저장소에는 남으므로 gcx CLI 등으로 다시 가져올 수 있습니다.

2. Grafana 12의 코드 기반 리소스 관리 도구

원문: Observability as code: automate observability workflows and manage dashboards as code in Grafana · Fabrizia Rossano, Artur Wierzbicki · 2025-05-08

Grafana Labs는 Grafana 12에서 대시보드를 코드로 관리하는 공식 도구와 API 기반을 함께 공개했습니다. 기존에는 여러 도구가 있었지만 Grafana에 직접 통합되고 회사가 지원하는 일관된 사용 경로가 부족했다고 설명합니다. 이번 릴리스는 대시보드의 버전 관리·검증·배포 경험을 우선 개선하고, 다른 리소스까지 관리 범위를 넓힐 기반을 마련합니다.

App Platform은 Kubernetes API 패턴을 참고한 버전별 리소스 API를 도입합니다. Grafana는 기존처럼 설정된 데이터베이스를 사용하며, 대시보드와 폴더용 /apis/... API가 기존 /api/...와 함께 제공됩니다. 새 API 버전은 v1beta1입니다. 별도의 v2alpha1 Dashboard API로 접근하는 대시보드 스키마 v2는 레이아웃과 패널 설정을 분리해 Git 변경 비교와 새로운 화면 배치를 지원합니다.

Foundation SDK는 JSON을 직접 작성하는 대신 타입이 지정된 빌더로 대시보드와 알림 규칙을 정의하도록 돕습니다. grafanactl은 새 API가 관리하는 리소스를 조회·가져오기·배포·검증하며, SDK와 연동한 serve 명령으로 로컬 미리보기도 제공합니다. Terraform에도 새 API와 스키마 검증을 사용하는 대시보드 및 재생 목록 리소스가 추가됐습니다.

이 글의 출시 단계는 2025년 5월 Grafana 12 기준입니다. Grafana Labs는 실험 단계인 Git Sync와 스키마 v2를 실제 서비스 운영에 사용하지 말고 개발 환경에서 시험하도록 권고합니다.

• App Platform과 대시보드 스키마 v2는 실험 단계
• Git Sync는 OSS·Enterprise에서 실험 단계, 일부 Cloud 사용자에게 비공개 프리뷰
• Foundation SDK는 Go·Java·PHP·Python·TypeScript를 지원하는 공개 프리뷰
• grafanactl은 공개 프리뷰
• Terraform의 grafana_apps_dashboard_dashboard_v1beta1과 grafana_apps_playlist_playlist_v0alpha1은 공개 프리뷰

3. Grafana 동적 대시보드의 탐색과 편집 기능

원문: New in Grafana 12: Dynamic dashboards that are smarter, easier to edit, and can be customized for teams · Thanos Karachalios, Fabrizia Rossano · 2025-05-08

Grafana Labs는 대시보드가 커질수록 사용자에게 불필요한 패널, 빈 화면, 긴 스크롤, 수동 배치 조정이 늘어나는 문제를 해결하려고 Dynamic Dashboards를 만들었습니다. Grafana 11에서 도입한 Scenes 라이브러리와 새로운 대시보드 스키마가 기반입니다. 하나의 대시보드 안에서 사용자와 용도에 맞게 내용을 나누고, 필요한 정보로 이동하는 경험을 개선합니다.

새로운 탭은 기존 행과 함께 사용할 수 있고 중첩 배치도 지원합니다. dashboard outline은 트리 형태의 탐색 창으로 섹션 간 이동을 돕습니다. 조건부 렌더링은 변수 선택이나 데이터 유무에 따라 패널 또는 행 전체를 표시하거나 숨깁니다. auto-grid는 최대 열 수나 패널 최대 높이를 지정해 화면 크기와 내용에 맞게 배치를 조정합니다. 선택한 탭·행·패널에 필요한 설정은 문맥에 맞는 측면 창에서 편집할 수 있습니다.

새 스키마는 주요 설정을 kind와 spec 패턴으로 표현하고, 공통 패널 옵션과 시각화 설정을 분리합니다. 쿼리·변환·쿼리 옵션도 명확한 종류로 정의합니다. 데이터 소스 UID 대신 데이터 소스 유형을 지정하면 Grafana가 사용할 데이터 소스를 결정하므로, 글은 이를 대시보드 이동성을 개선하는 변화로 설명합니다.

시작 안내에 따르면 Grafana OSS와 Enterprise에서는 실험 기능이며, Grafana Cloud에서는 비공개 프리뷰입니다. Grafana Labs는 실제 서비스 운영에 사용하지 않도록 강하게 권고합니다. Grafana 12에서 기능을 켜면 이후 저장하는 모든 대시보드가 v2 스키마로 자동 변환되고, 당시에는 백엔드에서 되돌릴 방법이 없습니다. 화면은 v1과 v2를 모두 지원하지만, 특정 스키마에 의존하는 자동화나 코드 기반 관리 작업은 영향을 받을 수 있습니다.

4. Beyla와 OpenTelemetry의 연계 소식

원문: Grafana’s eBPF Beyla Future Hinges on OpenTelemetry · The New Stack

원문 페이지에서 기사 본문을 받지 못해 뉴스레터 소개만 옮깁니다. 뉴스레터는 Grafana의 eBPF 자동 계측 프로젝트 Beyla가 OpenTelemetry eBPF 계측 프로젝트에 기부된다고 소개합니다.

5. Autometrics의 함수 단위 계측과 SLO 관리

원문: Autometrics - Developer-first Observability Framework · Fiberplane

Autometrics 제품 소개 페이지는 함수 단위 계측부터 조회와 알림까지 연결하는 오픈소스 옵저버빌리티 스택을 설명합니다. 개발자가 매크로·데코레이터·래퍼를 함수에 붙이면 요청률, 오류율, 지연 시간 메트릭을 수집할 수 있습니다. 필요한 Prometheus 쿼리도 생성하므로, 함수 동작을 확인하기 위해 쿼리를 직접 구성하는 부담을 줄이는 것이 목표입니다.

Explorer는 함수 성능과 SLO, 알림을 시각화하고 조사하는 인터페이스입니다. CLI는 메트릭 수집과 알림 임계값을 로컬에서 확인하고 조정하도록 돕습니다. 페이지의 Rust 예제는 #[autometrics]로 함수를 계측한 뒤 애플리케이션과 로컬 스택을 실행하는 흐름을 보여줍니다. 소스 코드에서 SLO를 정의하면 오류와 지연 시간에 관한 알림을 구성할 수 있으며, Slack 연동은 문제가 생긴 함수의 차트를 알림에 포함합니다.

Autometrics는 Prometheus 호환 메트릭을 내보내고, Explorer와 Slack 애플리케이션은 Prometheus API를 사용합니다. OpenTelemetry도 지원하며 HTTP와 GRPC로 Collector에 데이터를 보낼 수 있습니다. 소개 페이지는 애플리케이션 버전을 추적해 오류나 지연 시간을 유발한 커밋을 찾는 기능도 제시합니다. GitHub Action은 코드의 계측 상태와 새 커밋이 관측 가능성에 미치는 영향을 추적하고, VSCode 확장과 별도 설정 없이 사용하는 Grafana 대시보드도 제공합니다.

6. OpenTelemetry Sum Connector의 속성 합산

원문: Introduction to the OpenTelemetry Sum Connector · Jeremy Hicks · 2024-12-12

Jeremy Hicks는 로그나 스팬 속성에 들어 있는 숫자를 메트릭 시계열로 바꾸는 OpenTelemetry Sum Connector를 소개합니다. 주문 금액이나 수량처럼 이미 수집 중인 데이터에서 합계 메트릭을 만들려는 용도입니다. 변환 대상은 로그, 스팬, 스팬 이벤트, 메트릭 데이터 포인트이며, source_attribute가 합산할 숫자의 출처를 지정합니다.

예제는 결제 과정의 마지막 스팬에 있는 order.total과 discount.total을 사용합니다. sum/totals는 할인 전 주문 금액을 purchase.order.total로, sum/discounts는 할인액을 purchase.discount.total로 만듭니다. promo.code는 새 메트릭의 속성으로 전달해 프로모션별 시계열을 구분합니다. 해당 속성이 없으면 기본값 none을 붙이고, 숫자 출처에는 "NULL"이 아닌 값만 처리하는 조건을 설정합니다.

Collector의 traces 파이프라인은 OTLP 데이터를 받아 sapm과 합산 커넥터로 전달합니다. 커넥터는 이 파이프라인에서는 exporter 위치에 놓이고, metrics 파이프라인에서는 receiver로 연결됩니다. metrics 파이프라인은 OTLP 메트릭과 커넥터가 만든 메트릭을 함께 받아 signalfx exporter로 Splunk Observability Cloud에 보냅니다. 원래 트레이스 전송과 파생 메트릭 생성이 같은 수집 설정 안에 들어가는 방식입니다.

저자는 생성한 메트릭으로 총구매액, 프로모션별 할인액, 할인 없는 구매액, 프로모션별 구매 비중을 차트로 만들 수 있다고 설명합니다. 매출 감소를 애플리케이션·인프라 장애와 연관 지어 살피거나, 판매 수준이 비정상적으로 낮아지면 알림을 보낼 수도 있습니다. 다른 활용 예로는 메인프레임 로그의 금액·처리 시간 합산과 CI/CD의 테스트 실패 수·산출물 크기·실행 시간 추적을 제시합니다.

7. Pure Storage FlashBlade의 Prometheus 모니터링

원문: Monitoring 10 Petabytes of data in Pure Storage · Victor Bogo · 2025-01-02

37signals는 AWS S3에서 10페타바이트의 데이터를 옮기는 작업에 Pure Storage FlashBlade를 선택했습니다. 대상에는 Basecamp 첨부 파일과 Prometheus 장기 보관 메트릭이 포함됩니다. FlashBlade의 파일시스템 기능은 데이터베이스 백업 저장에도 활용할 수 있습니다. Victor Bogo는 장비 자체 알림과 자동 티켓 생성에 더해, 기존 Prometheus 체계에서 메트릭과 알림을 다루는 방법을 설명합니다.

수집에는 Pure가 유지보수하는 pure-fb-openmetrics-exporter를 사용합니다. Chef 예제는 버전 1.0.13 바이너리와 API 토큰 설정을 배치하고 systemd 서비스로 실행합니다. /metrics 하나로 수집할 수도 있지만, 37signals는 메트릭을 한꺼번에 가져오는 부담을 줄이려고 작업을 분리했습니다. /metrics/array, /metrics/clients, /metrics/usage, /metrics/policies를 각각 수집하며, name에서 ch, fb, bay 레이블을 추출해 부품별 집계 쿼리를 단순화합니다.

37signals는 장비 내부에서 생성한 경고와 직접 정의한 하드웨어 규칙을 함께 알림에 사용합니다. 최근 30분간의 평균 지연 시간이 100ms를 넘으면 채팅으로 알리는 규칙도 두었습니다. 단일 하드웨어 고장은 Ops의 Basecamp 4 채팅에 알리고, 같은 섀시에서 같은 유형의 부품이 여러 개 고장 나거나 같은 블레이드의 bay가 여러 개 고장 나면 호출 알림을 보냅니다. 섀시와 XFM 장애도 별도로 감시합니다. 저자는 여러 부품의 고장이 곧바로 심각한 상태를 뜻하지는 않지만, 예상하지 못한 상황에 대비한 기준으로 설정했다고 설명합니다.

용량 규칙은 최근 30일의 빈 공간 추세에 predict_linear를 적용해 730시간 뒤의 빈 공간이 전체 용량의 10% 미만인지 확인합니다. HTTP 접근은 클러스터 앞단 BigIp의 기존 알림이 담당하고, Grafana 대시보드는 exporter 저장소의 JSON을 조정해 가져옵니다. Pure 자체 알림과 사용자 정의 알림의 상호작용은 아직 평가 중이며, 결과에 따라 한쪽만 유지할 수 있다고 밝힙니다.

8. Prometheus 메트릭 유형과 분포 표현

원문: Prometheus Metrics Explained: Counters, Gauges, Histograms & Summaries · Phuong Le · 2025-02-21

Phuong Le는 메트릭 이름·레이블·값·타임스탬프에서 출발해 Counter, Gauge, Histogram, Summary의 의미를 설명합니다. 메트릭 이름과 레이블 조합이 시계열을 식별하므로, 같은 메트릭이라도 경로나 상태 코드가 다르면 별도 시계열입니다. 글은 IP나 사용자 ID처럼 값의 종류가 많은 레이블이 시계열 수를 급격히 늘리고 모니터링 시스템을 느리게 만들 수 있다고 경고합니다.

Counter는 누적 요청 수나 오류 수처럼 증가하다가 재시작 등으로 초기화되는 값을 표현합니다. rate()와 increase()는 감소를 초기화로 판단해 계산에 반영합니다. 저자는 VictoriaMetrics에서 이런 처리가 메트릭 자체의 유형 분류가 아니라 사용하는 함수에 달려 있다고 설명합니다. Gauge는 사용 가능한 메모리처럼 증가와 감소가 모두 가능한 현재 상태를 표현합니다.

Histogram은 관측값을 구간별로 나눕니다. _bucket은 le 이하인 관측 수를 누적으로 기록하고, _sum과 _count는 전체 합과 관측 수를 보관합니다. 예제의 요청 92건은 응답 시간 합계가 16.025초이며, histogram_quantile()로 최근 5분의 95백분위수를 추정합니다. 고전적 Histogram은 버킷 경계를 미리 정해야 하고, 버킷을 늘리면 저장 공간과 쿼리 비용이 커집니다. 경계가 다른 Histogram끼리는 함께 집계할 수 없다는 제약도 제시합니다.

Summary는 클라이언트에서 분위수를 계산해 내보냅니다. 버킷 경계를 정할 필요는 없지만, 미리 계산하지 않은 분위수를 나중에 구하거나 여러 인스턴스의 분위수를 합쳐 전체 값을 만들 수 없습니다. 글은 이러한 차이와 함께 메트릭 이름에 기본 단위를 쓰고, 레이블에 중복된 문맥을 넣지 않으며, 같은 의미에는 일관된 이름을 사용하도록 권합니다.

9. Instant Query와 Range Query의 평가 방식

원문: Prometheus Monitoring: Instant Queries and Range Queries Explained · Phuong Le · 2025-02-21

Phuong Le는 쿼리의 실행 방식과 표현식의 데이터 유형을 구분합니다. Instant Query는 표현식을 한 시점에 평가하고, Range Query는 시작부터 끝까지 일정 간격으로 반복 평가합니다. node_cpu_usage 같은 instant vector selector는 어느 방식으로도 실행할 수 있습니다. 표현식에 메트릭 이름만 적었다는 이유로 Instant Query가 되는 것은 아닙니다.

Instant vector selector는 평가 시점보다 늦지 않은 최근 샘플을 시계열마다 선택합니다. Prometheus의 기본 lookback delta는 5분이며 --query.lookback-delta로 바꿀 수 있습니다. 이 범위 안에 샘플이 없으면 해당 시계열은 결과에서 빠집니다. Range Query의 step은 반복 평가 간격입니다. 그래서 실제 수집 시각이 00:09, 00:13, 00:16이어도 평가 간격에 따라 결과가 00:10, 00:15, 00:20 시점에 표시될 수 있습니다.

[window]는 step과 다른 역할을 맡습니다. max_over_time(node_cpu_usage[3m])를 step: 5m으로 실행하면, 5분마다 직전 3분의 샘플을 모아 최댓값을 구합니다. 해당 3분 안에 샘플이 없으면 그 평가 시점에는 결과가 없습니다. step은 계산 시점의 간격이고, [3m]은 각 계산에 사용할 데이터 범위입니다.

http_requests_total[5m]을 Instant Query로 실행하면 평가 시점 직전 5분의 원본 샘플을 반환합니다. 이때 결과는 원래 수집 타임스탬프를 유지합니다. 같은 표현식을 Prometheus의 Range Query로 실행하면, 각 평가에서 여러 샘플을 반환하는 range vector이므로 오류가 발생합니다. 글은 VictoriaMetrics에서는 이를 last_over_time(http_requests_total[5m])처럼 처리한다고 설명하며, 두 시스템의 동작 차이를 구분합니다.

10. PromQL 함수와 벡터 매칭의 계산 순서

원문: Prometheus Monitoring: Functions, Subqueries, Operators, and Modifiers · Phuong Le · 2025-04-25

Phuong Le는 함수가 시간축과 시계열 중 어디를 계산하는지 구분해 PromQL과 MetricsQL을 설명합니다. rate()나 max_over_time() 같은 rollup 함수는 한 시계열의 시간 구간을 하나의 값으로 줄입니다. sum()이나 avg() 같은 집계 함수는 같은 시점의 여러 시계열을 합칩니다. abs()·ceil() 같은 변환 함수는 샘플 값에 수학 연산을 적용하고, label_replace()와 label_join()은 레이블을 가공합니다.

입력 유형을 구분하면 오류 원인도 드러납니다. PromQL에서 rollup 함수에 시간 범위 없이 instant vector를 넘기거나, 집계 함수에 range vector를 넘기면 오류가 발생합니다. MetricsQL은 생략된 범위를 추정하거나 내부 변환을 적용하는 경우가 있습니다. 글은 rate() 계산도 VictoriaMetrics는 실제 샘플 타임스탬프를 사용하고, Prometheus는 외삽을 사용할 수 있다고 설명합니다.

서브쿼리는 내부 표현식을 시간 범위에 걸쳐 평가한 결과를 바깥 함수에 넘깁니다. 저자는 Counter를 먼저 합산하고 나중에 rate()를 적용하는 순서를 흔한 실수로 지적합니다. 합산이 개별 시계열의 초기화를 가릴 수 있기 때문입니다. 제시한 권장 형태는 sum(rate(http_requests_total[5m])) by (service)로, 각 Counter의 초기화를 처리한 뒤 서비스별 결과를 합칩니다.

벡터 간 연산은 레이블로 시계열을 대응시키며, 산술 연산에서 짝이 없는 시계열은 결과에서 빠집니다. 비교 연산은 기본적으로 조건에 맞는 값을 남기고, bool을 붙이면 참과 거짓을 1과 0으로 표현합니다. on()은 매칭에 사용할 레이블을 지정하고, group_left()와 group_right()는 다대일·일대다 매칭을 다룹니다. 글은 집합 연산을 제외한 다대다 매칭을 Prometheus가 허용하지 않는다고 설명합니다. VictoriaMetrics는 결과 레이블 조합이 중복되지 않는 조건에서 이를 허용합니다.

11. 알림 규칙과 Alertmanager의 역할 분담

원문: Prometheus Alerting 101: Rules, Recording Rules, and Alertmanager · Phuong Le · 2025-03-18

Phuong Le는 규칙 평가부터 알림 전달까지의 흐름을 vmalert와 Alertmanager 중심으로 설명합니다. 알림 규칙은 데이터 소스에 표현식을 주기적으로 실행하고, 결과로 반환된 시계열마다 별도 알림을 만듭니다. for: 5m은 조건이 5분 동안 유지되어야 알림을 발화시키는 설정입니다. 그 전에 조건이 사라지면 알림이 비활성화되며, 이미 발화한 알림의 조건이 해소되면 Alertmanager에 해소 상태를 전달합니다.

Recording Rule은 반복해서 사용하는 계산 결과를 새 시계열로 저장합니다. 글의 vmalert 예제에서는 remote write로 결과를 기록하고, 대시보드와 알림이 저장된 값을 다시 사용합니다. 규칙 그룹은 평가 주기를 정합니다. vmalert의 concurrency는 그룹 안의 병렬 실행 수를 설정하며, eval_offset은 평가 시점을 옮깁니다. 예를 들어 1시간 주기에 eval_offset: 30m을 지정하면 매시 30분에 실행합니다.

Alertmanager는 레이블을 기준으로 수신자를 정하고, 알림을 묶고 중복을 제거합니다. 라우팅의 continue: true는 한 경로에 일치한 알림을 뒤의 경로에서도 계속 검사하도록 합니다. 묶음 예제는 group_wait: 30s로 첫 통지를 기다리고, group_interval: 5m마다 추가·해소된 알림을 확인합니다. 변경이 없을 때 반복 통지하는 간격은 repeat_interval: 4h입니다.

Inhibition은 더 중요한 알림이 있을 때 관련 알림의 통지를 억제하며, 억제된 알림도 UI에는 남습니다. Silence는 일치 조건과 시작·종료 시각, 작성자, 사유를 지정해 특정 알림을 잠시 음소거합니다. 최종 메시지는 수신자별 템플릿으로 구성하고, 해소 알림 포함 여부는 send_resolved가 결정합니다. 해소 통지도 즉시 발송하는 것이 아니라 group_interval에 따른 다음 통지 주기를 기다립니다.

12. Keep의 알림 통합과 워크플로 자동화

원문: Keep - Open-source AIOps platform · Keep

Keep 제품 소개 페이지는 여러 도구에서 발생한 알림과 이벤트를 모으고, 정보를 보강하며, 대응 작업을 자동화하는 플랫폼을 설명합니다. 모니터링뿐 아니라 사고 대응, 티켓, 소스 코드 관리, 변경 관리, CMDB 시스템을 연결 대상으로 제시합니다. Keep은 양방향 연동으로 알림과 신호의 상태를 동기화한다고 밝힙니다.

수집한 알림은 하나의 화면에서 조회합니다. 페이지에서 Common Express Language라고 부르는 쿼리 기능으로 데이터를 검색·분할·분석하고, 규칙에 따라 알림을 묶습니다. 워크플로 엔진은 GitHub Actions와 비슷한 YAML 형식에 UI를 더한 방식입니다. MySQL 조회 결과를 알림에 추가하거나, Jira 티켓을 갱신하거나, Python 스크립트를 실행하는 작업을 예로 듭니다.

연동, 수집·조회, 워크플로 자동화는 OSS·Cloud·Enterprise에 제공되는 기능으로 안내합니다. 과거 사고와 지식 기반을 사용하는 AI 알림 상관관계 분석은 Keep Enterprise 전용입니다. Keep은 지속적인 피드백으로 이 기능의 성능을 개선한다고 설명합니다.

배포 방식은 직접 호스팅하는 오픈소스 도구, Keep이 배포를 관리하는 Cloud, 클라우드와 온프레미스를 지원하는 Enterprise로 나뉩니다. Enterprise 안내에는 AI 기반 알림 상관관계 분석과 요약이 명시되어 있습니다. 페이지 상단에는 Keep이 Elastic과 합류한다는 공지가 있지만, 제공된 자료에는 거래 조건이나 구체적인 일정은 담겨 있지 않습니다.