목차
promkr 뉴스레터 2026년 3월호
원문 정보
- 원문: Prometheus & Observability - 2026년 3월 소식
- 발행: 2026-03-21
이 호에 실린 소식 7개의 원문을 읽고 요약했습니다. 뉴스레터 설명이 아니라 링크가 가리키는 글의 내용을 기준으로 썼습니다. 한 해 전체의 흐름은 2026년 소식에 있습니다.
1. Grafana 12.4 대시보드 관리와 시각화 개선
원문: Grafana 12.4 release: faster and easier data visualization, observability as code updates, and more · Grafana Labs Team · 2026-02-25
Grafana 12.4는 대시보드 작성과 탐색, 코드 기반 관리 기능을 확장한 릴리스입니다. Git Sync는 대시보드 버전 관리와 pull request, 승인 작업을 GitHub이나 Grafana에서 수행하도록 연결합니다. 이번 버전에서는 개인 액세스 토큰 외에 GitHub App 인증을 지원하고 저장 화면의 브랜치 선택을 개선했습니다. 제공 단계는 Grafana Cloud에서 퍼블릭 프리뷰이며, OSS와 Enterprise에서는 실험적 기능입니다.
Dynamic dashboards는 모든 에디션에서 퍼블릭 프리뷰로 제공됩니다. 탭으로 내용을 가로 방향으로 나누고, 변수 선택이나 데이터 반환 여부에 따라 패널·행·탭을 표시하거나 숨길 수 있습니다. Auto grid는 화면 공간에 맞춰 패널 크기를 조절하며 최소 열 너비, 행 높이, 최대 열 수를 설정합니다. 표시·숨김 규칙을 쓰려면 빈 공간이 남지 않도록 Auto grid를 먼저 적용해야 합니다. 클릭 가능한 콘텐츠 개요와 오른쪽 도구 모음에서는 항목 탐색과 제목·설명 편집을 지원합니다.
새 대시보드를 시작하는 경로도 늘었습니다. Suggested dashboards는 연결한 데이터 소스에 맞는 기존 대시보드를 제안합니다. 템플릿은 샘플 데이터가 담긴 레이아웃을 제공하며, 사용자가 패널의 데이터 소스를 실제 데이터로 바꿉니다. 시각화 추천은 데이터 소스 메타데이터를 활용하고 선택 전에 전체 크기 미리보기를 보여줍니다. 이 기능들은 모든 에디션에서 퍼블릭 프리뷰이며, 갱신된 시각화 추천에는 newVizSuggestions 기능 토글이 필요합니다.
- 게이지 개선: 원형 스타일, sparkline, 그라데이션, Center glow와 막대 두께 설정 추가. 퍼블릭 프리뷰이며
newGauge로 활성화 - 시간 범위 탐색: 시계열 x축 드래그로 이동하고
t+와t-로 시간 범위를 절반 또는 두 배로 조절. 모든 에디션에서 GA - 변수 개선: 표시 텍스트에 정규식 적용 가능. multi-property variables로 여러 식별자를 한 변수에 연결
- 로그 탐색: OTel 로그 메타데이터 직접 표시는 실험적 기능. Logs Drilldown의 기본 열 설정과 탐색 저장·재개는 퍼블릭 프리뷰
- 접근 관리: Cloud와 Enterprise에서 SCIM 사용자·팀 프로비저닝 GA, saved queries의 Writer·Reader 역할 기반 권한은 퍼블릭 프리뷰
2. Loki 초당 110만 건 로그 수집 파이프라인 설계
원문: Building a 1M/sec Log Ingestion Pipeline with Grafana Loki: Design, Bottlenecks, and Optimization · Ali Hussein Safar · 2026-02-24
Ali Hussein Safar는 80개 이상 서비스의 JSON 로그를 수집하는 파이프라인을 설명합니다. 서비스마다 스키마를 관리하지 않으면서 서비스명·시간·trace_id로 검색하고, 장기 저장에는 S3를 쓰는 것이 요구사항이었습니다. 로그 전체 대신 레이블을 색인하는 Loki를 선택했지만, 값이 계속 늘어나는 trace_id를 레이블로 쓰면 메모리의 청크 수가 급증하는 문제가 있었습니다.
이를 해결한 Go 기반 Puller는 Kafka에서 로그를 읽고, 외부 메타데이터를 보강한 뒤 레이블과 배치를 구성해 Loki로 보냅니다. 각 actor shard는 독립된 메모리 맵을 가지며, service_name 해시로 메시지를 배정해 공유 잠금 경쟁을 피합니다. 저자는 이 방식으로 캐시 적중률 92%를 얻었다고 보고합니다. trace_id는 해시에서 8비트를 취해 256개 bucket으로 바꿉니다. 서비스 80개를 기준으로 service_name과 bucket 조합의 스트림 상한은 20,480개입니다. 검색할 때는 Grafana Infinity 플러그인이 Puller의 HTTP 엔드포인트에서 버킷 번호를 받고, 해당 버킷 안에서 원래 trace_id 문자열을 찾습니다.
수집 앞단은 중앙 HAProxy의 병목을 없애기 위해 OSPF와 ECMP로 Rsyslog 노드에 트래픽을 분산했습니다. Rsyslog는 Snappy 압축과 배치 전송을 맡고, 메모리 큐·디스크 보조 큐·무제한 재시도로 Kafka 장애나 짧은 네트워크 단절을 흡수합니다. Puller와 Loki는 노드당 16 CPU 코어·48 GB 메모리를 갖춘 Kubernetes 노드 8개에서 실행합니다. 저자는 수주간 부하와 튜닝을 거쳐 관찰 가능한 역압이나 청크 불안정, 저장소 병목 없이 최고 초당 약 110만 건을 유지했다고 밝힙니다. 평균 Loki 지연은 약 5~6 ms, 압축률은 약 3.6배였습니다.
추가 최적화에서는 같은 노드의 Distributor로 우선 전송하고, 5분마다 shard 부하를 검사해 서비스 배정을 조정했습니다. 단일 코어를 포화시킨 가상 NIC의 RX/TX 큐는 노드 CPU 코어 수에 맞춰 16개로 늘렸습니다. Kafka 파티션 48개를 Puller 8개에 고정 배정했을 때 생긴 소비 지연은 Kafka 4.2의 KIP-932 shared groups를 도입해 해결했다고 설명합니다. 레코드 단위로 작업을 나눠 노드별 처리 속도 차이를 흡수한 것입니다. 저자가 보고한 초당 100만 건에 근접한 부하 조건에서 쿼리는 5초 미만에 결과를 반환했고, 새 로그는 10초 미만에 검색할 수 있었습니다.
3. Kubernetes History Inspector의 감사 로그 시각화
원문: Kubernetes History Inspector · GoogleCloudPlatform
Kubernetes History Inspector(KHI)는 Kubernetes 로그를 대화형 타임라인으로 바꾸는 도구입니다. README는 여러 컴포넌트에 걸친 복잡한 문제를 조사하는 용도로 소개합니다. 클러스터에 에이전트를 설치하지 않고 로그를 읽어 리소스 변화와 관계를 보여줍니다. Timeline view는 감사 로그에서 리소스 상태가 바뀐 시점과 매니페스트 차이를 표시합니다. Topology view는 kube-apiserver 감사 로그만으로 Kubernetes 리소스 간 관계를 시각화합니다.
Google Cloud에서는 GKE, Cloud Composer, GKE on AWS·Azure, GDCV for Baremetal·VMWare를 지원 대상으로 명시합니다. 주 로그 소스는 Cloud Logging입니다. 선택적으로 Cloud Asset Inventory를 사용해 이미 존재하던 리소스의 초기 상태 스냅샷을 복원할 수 있습니다. 다른 Kubernetes 클러스터에서는 JSONlines 형식의 kube-apiserver 감사 로그 파일을 업로드하는 경로를 제공합니다. README에는 Loki를 사용하는 OSS Kubernetes 연동 가이드도 연결되어 있습니다.
실행 안내는 초기 자격 증명 설정이 필요 없는 Cloud Shell을 가장 간단한 경로로 제시합니다. 메타데이터 서버가 없는 로컬 PC에서는 Application Default Credentials(ADC) 파일을 컨테이너에 읽기 전용으로 마운트합니다. 웹 서버 없이 자동화 작업에서 실행하는 Job Mode도 별도 안내합니다. 브라우저 테스트와 지원 범위는 최신 Google Chrome으로 한정됩니다.
KHI는 공식 지원을 받는 Google Cloud 제품이 아니며, 문제와 기능 요청은 저장소 이슈에서 최선의 노력으로 대응한다고 명시합니다. 자체 인증·인가 기능도 없습니다. README는 로컬 사용자의 접근을 전제로 하며 KHI 포트를 인터넷에 노출하지 말라고 안내합니다.
4. Perforator의 클러스터 연속 프로파일링
원문: Perforator · Yandex
Perforator README는 Yandex가 만든 대규모 데이터센터용 연속 프로파일링 도구를 소개합니다. Yandex는 수만 대 서버에 배포해 서비스 성능 문제를 찾는 데 사용하고 있다고 밝힙니다. Google-Wide Profiling에서 영감을 받았으며, 실행 중인 애플리케이션의 CPU 프로파일을 수집하고 조회하는 기능을 제공합니다.
수집기는 eBPF로 커널과 사용자 공간의 스택을 수집합니다. 호스트에 프레임 포인터와 디버그 심볼이 없어도 스택을 풀어낼 수 있으며, 프로파일과 바이너리를 저장하는 확장 가능한 저장소를 갖췄습니다. 사용자는 쿼리 언어와 UI에서 CPU 사용량을 조사하고 flamegraph로 살펴봅니다. AutoFDO를 사용하는 Profile Guided Optimization(PGO) 빌드에 필요한 sPGO 프로파일 생성도 지원합니다.
지원 언어는 C++, C, Go, Rust이며 Java와 Python 지원은 실험적 단계입니다. 최소 실행 플랫폼은 x86 64비트 Linux입니다. README가 제시한 자원 사용량은 RAM 512Mb와 호스트 CPU의 1% 미만이며, CPU가 많은 매우 큰 호스트에서는 메모리가 더 필요하다고 명시합니다. 로컬에서는 perforator record CLI 명령으로 프로파일링하고, Kubernetes에는 Helm chart로 배포할 수 있습니다.
프로젝트의 기본 라이선스는 Apache 2.0입니다. eBPF 프로그램 소스와 OpenJDK 프로파일링 지원 코드 일부에는 GPL 2.0이 적용됩니다.
5. GPU Metrics Agent의 NVIDIA 메트릭 수집
원문: GPU Metrics Agent · Polar Signals
Polar Signals의 GPU Metrics Agent는 NVIDIA GPU 메트릭을 수집해 OpenTelemetry Arrow 프로토콜로 내보내는 에이전트입니다. README는 GPU 활용률과 프로세스별 사용량을 관찰해 자원 배정, 성능 문제 조사, 전력 비용 분석에 활용하는 방식을 설명합니다. 모델 학습과 추론 중 GPU 사용 패턴을 추적하는 용도도 제시합니다.
구성은 NVIDIA Management Library(NVML)에서 값을 읽는 NVIDIA Producer, 메트릭을 배치로 내보내는 Metric Exporter, 원격 저장소와의 보안 연결을 관리하는 gRPC Client로 나뉩니다. 모든 메트릭에는 GPU 식별자인 uuid와 GPU 번호인 index 속성이 붙습니다. 프로세스 단위 메트릭에는 pid와 comm도 포함되어 어떤 프로세스가 GPU를 사용하는지 구분합니다.
수집 주기는 메트릭 종류마다 다릅니다. GPU 연산 활용률과 메모리 활용률은 5s, 전력·전력 제한·클록·온도는 1s, PCIe 송수신 처리량은 100ms입니다. 메트릭을 원격으로 내보내는 주기는 --collection-interval로 설정하며 기본값은 10s입니다. 수집과 내보내기의 주기를 구분해 설명한 README입니다.
실행에는 Linux, NVIDIA 드라이버 390.x 이상, 사용 가능한 NVML이 필요합니다. 원격 gRPC 주소인 --remote-store-address는 필수 설정입니다. NVIDIA 메트릭 수집 옵션 --metrics-producer-nvidia-gpu는 기본값이 false이므로 실행 예제에서는 이를 활성화합니다. 노드 레이블은 --node로 지정하며 기본값은 Machine ID입니다.
- 활용률:
gpu_utilization_percent,gpu_utilization_memory_percent로 각각 0~100% 측정 - 전력:
gpu_power_watt,gpu_power_limit_watt로 현재 소비 전력과 최대 전력 제한 수집 - 클록과 온도:
gpu_clock_hertz,gpu_temperature_celsius수집. 클록 대상은 graphics, SM, memory, video - PCIe:
gpu_pcie_throughput_transmit_bytes,gpu_pcie_throughput_receive_bytes로 송수신 처리량 수집
6. Hercules의 SQL 기반 Prometheus 메트릭 생성
원문: Hercules · jakthom
Hercules는 DuckDB 기반 Prometheus exporter입니다. YAML에 메트릭을 정의하고 SQL로 원본 데이터를 집계하거나 보강해 메트릭 값을 만듭니다. 지원 유형은 gauge, counter, summary, histogram입니다. 여러 데이터 소스의 메트릭을 하나의 exporter에서 생성할 수 있으며, 소스는 캐시해 주기적으로 갱신하거나 원본 데이터를 참조하는 뷰로 사용할 수 있습니다.
입력 범위는 로컬 파일부터 원격 저장소와 데이터베이스까지 이어집니다. README는 Parquet·JSON·CSV·XLSX 파일, GCS·S3·Azure Blob, HTTP 엔드포인트를 나열합니다. PostgreSQL·MySQL·SQLite와 Iceberg·Delta, BigQuery, Arrow IPC 버퍼도 포함됩니다. 소스와 메트릭에 외부 정보를 결합해 값을 계산하거나 레이블을 보강하는 기능도 설명합니다.
반복되는 변환은 SQL 매크로로 재사용합니다. 로그 파싱, useragent 문자열 해석, 비정형 데이터의 스키마 구성, 외부 도구를 이용한 결과 보강, 속성 토큰화가 예시입니다. 전역 레이블은 설정 파일이나 환경 변수에서 가져와 모든 메트릭에 적용합니다. 확장 기능·소스·메트릭·매크로는 패키지로 묶어 배포할 수 있으며, README는 NYC Taxi, Snowflake, TPCH, Bluesky 예제 패키지를 제공합니다.
로컬 빌드에는 Go 1.22 이상과 Git이 필요합니다. 기본 설정 파일은 프로젝트 루트의 hercules.yml이며, HERCULES_CONFIG_PATH로 다른 경로를 지정합니다. 실행 후 /metrics 엔드포인트에서 Prometheus 호환 수집기가 메트릭을 읽습니다. README의 기본 실행 설명은 포트 9999를 제시하고, YAML 예제와 메트릭 접근 예시는 9100을 사용합니다. 포트는 설정 파일에서 바꿀 수 있습니다. 메트릭 정의에는 여러 SQL 방언을 사용할 수 있으며, 추가 기능으로 pipe SQL과 PRQL도 소개합니다.
7. DeepTracer의 AI 오류 조사와 모니터링
원문: DeepTracer — AI Error Monitoring for Developers · DeepTracer
DeepTracer 제품 소개 페이지는 오류 감지 뒤 원인 조사와 수정안 설명을 자동화하는 모니터링 서비스를 설명합니다. 오류 급증이나 이상 징후가 발생하면 관련 로그, 트레이스, 최근 배포, 환경 변경을 모아 AI가 상관관계를 분석합니다. DeepTracer는 이 과정에서 근본 원인과 영향받는 사용자 수, 위험에 놓인 매출을 평가하고 구체적인 수정안을 제시한다고 밝힙니다. 조사 소요 시간은 업체 설명 기준 30~90초입니다.
Next.js 연동 예제는 @deeptracer/nextjs를 설치하고 withDeepTracer로 설정을 감싸는 방식입니다. SDK는 gzip 압축 기준 10KB 미만이며, 이벤트를 백그라운드에서 비동기로 전송해 요청·응답 처리를 막지 않는다고 설명합니다. DeepTracer 서버에 연결할 수 없으면 SDK가 조용히 실패하고 앱은 계속 실행됩니다. 지원 대상은 Next.js의 App Router와 Pages Router, React, Node.js, Express입니다. Vercel 앱에는 log drains를 사용하며, Bun과 Hono는 Node SDK로 동작합니다. Python과 Go SDK는 출시 예정으로 안내합니다.
기능에는 오류 자동 조사 외에 5분마다 수행하는 상태 점검, 모델별 지출과 사용자당 비용을 보는 LLM 비용 추적, 사용량 급증 알림이 포함됩니다. AI Chat은 실제 앱 데이터를 근거로 오류 증가 시점이나 느린 엔드포인트를 묻는 대화 기능입니다. 페이지에 등장하는 결제 실패, 메모리 누수, 인증 미들웨어 순서 문제는 제품 동작을 보여주는 예시입니다.
요금제에 따라 자동 감시와 조사 한도가 달라집니다. 무료 Reactive Mode는 프로젝트 1개, 월 25K 이벤트, 월 AI 조사 3회, 채팅 10회와 데이터 보존 1일을 제공합니다. 월 결제 기준 $19인 Pro의 Guardian Mode는 프로젝트 수 제한 없이 프로젝트당 월 2M 이벤트, 무제한 AI 조사·채팅, 상시 모니터링을 제공합니다. 보존 기간은 7일이며 오류는 30일이고, 팀 좌석은 5개입니다. 무료 한도에 도달해도 수집은 중단하지 않으며, 다음 달이 되거나 Pro로 바꾸기 전까지 새 AI 조사를 시작할 수 없다고 안내합니다.