promkr 뉴스레터 2026년 2월호

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

1. Prometheus Remote Write v2의 전송 비용 절감

원문: How Prometheus Remote Write v2 can help cut network egress costs by as much as 50% · Sam DeHaan, Kyle Eckhart · 2026-02-03

Grafana Labs가 내부 모니터링의 Prometheus Remote Write 프로토콜을 v1에서 v2로 바꾼 결과와 Alloy 설정법을 소개합니다. v1은 메트릭 샘플을 보내는 역할에 충실하지만, 메트릭 이름과 레이블 문자열을 반복해서 전송합니다. 메트릭 유형·단위·도움말 같은 메타데이터를 다루는 데도 제약이 있었습니다. v2는 샘플 페이로드에 메타데이터를 포함하고, 심볼 테이블로 반복 문자열의 전송량을 줄입니다.

심볼 테이블은 메트릭 이름, 레이블 이름과 값, 메타데이터의 문자열을 모아 두고 샘플에서 숫자로 참조하는 방식입니다. 같은 문자열이 많이 반복될수록 기존 형식보다 효율이 높아집니다. Grafana Labs는 수백만 개의 활성 시계열을 1~4 DPM으로 모니터링하며, 이전 가을에 내부 Prometheus 모니터링 워크로드를 모두 v2로 전환했다고 밝혔습니다. 이때 CPU와 메모리 사용량은 5~10% 증가했고, 내부 텔레메트리의 네트워크 이그레스 비용은 50% 넘게 줄었습니다. 배치를 크게 설정하면 트래픽 감소 폭이 더 커질 가능성이 있다는 설명도 덧붙입니다.

글 작성 시점의 v2 사양은 Prometheus와 Alloy에서 실험 단계입니다. Prometheus와 Mimir가 현재 사양을 지원하지만, 최종 사양이 나오기 전 호환성을 깨는 변경이 생길 수 있습니다. Alloy에서는 실행 플래그 --stability.level=experimental을 추가하고, prometheus.remote_write의 endpoint 블록에 protobuf_message = "io.prometheus.write.v2.Request"를 지정합니다. 출시 예정으로 소개한 Kubernetes Monitoring Helm chart v3.8에서는 목적지에 remoteWriteProtocol: 2를 지정하거나 protobufMessage를 직접 설정하는 방식도 안내합니다.

2. Lucas의 Kubernetes 점검과 자동 조치

원문: A2W: Lucas · A2W

Lucas는 Kubernetes 클러스터 안에서 파드와 로그를 살펴보는 운영·안정성 에이전트입니다. README는 Slack 대화의 스레드 문맥을 활용한 조사, 여러 네임스페이스의 예약 점검, 허용된 모드에서의 문제 수정 기능을 소개합니다. 실행 기록은 SQLite에 저장하며, 대시보드에서 실행 내역과 세션, 토큰 사용량, 비용, 런북을 확인할 수 있습니다.

실행 형태는 대화형 에이전트와 CronJob 에이전트로 나뉩니다. 대화형은 SRE_MODE=autonomous에서 문제를 수정할 수 있고, watcher에서는 보고만 합니다. CronJob은 autonomous와 보고 전용인 report를 구분합니다. 두 형태 모두 기본 모드는 autonomous입니다. 대화형 요청의 기본 네임스페이스는 TARGET_NAMESPACE, 예약 점검 대상은 쉼표로 구분한 TARGET_NAMESPACES로 지정합니다. 예약 점검 간격인 SCAN_INTERVAL_SECONDS의 기본값은 300초입니다.

대화형 에이전트에는 Claude API 키와 Slack 봇·앱 토큰이 필요합니다. CLAUDE_MODEL은 sonnet 또는 opus를 선택하며 기본값은 sonnet입니다. CronJob은 API 키 또는 자격 증명 파일로 인증하고, 예약 실행 결과를 SQLite에 기록하며 선택적으로 Slack 웹훅 알림을 보냅니다. README의 배포 절차는 sealed secrets 준비, 이미지 빌드와 푸시, 매니페스트 적용 순서입니다. 대시보드 로그인은 AUTH_USER와 AUTH_PASS로 설정하며, 저장소의 일반 Secret 예제 파일은 실제 운영에 적용하지 말라고 명시합니다.

3. Kubernetes 이벤트의 Loki 보관과 경보 과제

원문: Monitoring Kubernetes Events – have you ever thought about how many of them we miss? · Dmitry Ponomaryov

Dmitry Ponomaryov의 LinkedIn 게시글을 기준으로 정리했습니다. 저자는 장애가 난 뒤에야 Kubernetes 이벤트를 확인하곤 했지만, 기본 보관 시간이 약 한 시간인 --event-ttl 때문에 조사 전에 이벤트가 사라지는 문제를 겪었습니다. 이를 해결하려고 kubernetes-event-exporter로 이벤트를 Loki에 보내고 대시보드에서 확인하도록 구성했습니다.

이 방식의 이벤트 이력은 Loki 보관 기간에 따라 유지됩니다. 저자는 Kubernetes 이벤트 TTL을 늘리거나 etcd에 추가 부하를 주지 않고 이력을 확보했다고 설명합니다. 경보 설계는 아직 해결 과제로 남겨 두었습니다. Loki 규칙을 작성하고 VictoriaMetrics에서 PromQL로 조회해 경보를 만들 수 있지만, 알림 소음을 피하려면 중요 구성 요소나 kube-system 네임스페이스로 범위를 제한해야 하는지 질문합니다. 게시글은 경보 정책을 확정하거나 그 효과를 검증한 결과까지 제시하지는 않습니다.

4. Kruize의 워크로드 리소스 권장값 생성

원문: Kruize – Intelligent Kubernetes Resource Optimization · Kruize

Kruize는 Kubernetes 워크로드의 과거 사용량을 분석해 리소스 크기 조정 권장값을 만드는 오픈소스 도구입니다. Prometheus나 Thanos 같은 모니터링 시스템에 연결하고, 실제 사용 패턴에서 과다 할당과 부족한 할당을 찾습니다. 프로젝트는 과다 할당 비용을 줄이고 리소스가 부족한 워크로드의 성능을 개선하는 용도로 소개합니다. Red Hat Insights의 Resource Optimization Service를 뒷받침하는 엔진으로도 쓰이며, README는 이 서비스가 모든 OpenShift Container Platform 사용자에게 제공된다고 설명합니다.

권장값의 관찰 기간은 미리 정의된 단기·중기·장기 또는 사용자 지정 기간을 선택합니다. 워크로드의 우선순위에 따라 성능 최적화 프로필과 비용 최적화 프로필도 구분합니다. Metadata Profile은 네임스페이스·워크로드·컨테이너 정보를 가져올 쿼리와 데이터 소스별 레이블 등을 정의합니다. Metric Profile은 CPU·메모리·응답 시간처럼 관찰할 메트릭과 비용·성능 목표를 정의하며, Kruize가 비용과 성능 사이의 선택 기준을 판단하는 데 사용합니다.

배포에는 Operator를 사용할 수 있습니다. Operator는 CRD로 핵심 서비스와 UI를 선언적으로 구성합니다. 수동 설정 예제는 Kubernetes와 Prometheus가 준비되어 있고, 대상 애플리케이션이 최소 30분 동안 실행되었다고 가정합니다. 프로필과 메타데이터를 등록한 뒤 컨테이너 또는 네임스페이스 실험을 생성합니다. 권장값 생성 전에는 최소 2개의 데이터 포인트가 필요하며, 기본 설정에서는 수집에 약 30분이 걸린다고 안내합니다.

• 컨테이너: CPU·메모리의 requests와 limits 권장값
• 네임스페이스: CPU·메모리 리소스 쿼터 제한값
• NVIDIA GPU: A100·H100 등 지원 가속기의 MIG 슬라이스 구성
• 애플리케이션 런타임·프레임워크: Hotspot·Semeru JVM과 Quarkus 등의 설정 권장값, Alpha 단계

5. Retina를 이용한 가용 영역 간 트래픽 측정

원문: Monitoring Inter-Pod Traffic at the AZ Level with eBPF based tool Retina · Aslanov Javid · 2024-08-25

Aslanov Javid는 AWS 비용에서 큰 비중을 차지하는 가용 영역 간 트래픽을 분석하기 위해 Retina를 사용했습니다. 서비스에 topology-aware routing을 적용하기 전에, 파드 사이의 통신 중 얼마나 많은 양이 가용 영역 경계를 넘는지 파악하려는 목적입니다. 글은 eBPF 기반 Retina, Kube State Metrics, Prometheus, Grafana를 조합해 이 비율을 측정하는 실습을 설명합니다. 저자는 네임스페이스나 파드 단위로 관찰 범위를 쉽게 설정할 수 있다는 이유로 Retina를 선택했습니다.

실습에서는 서버 파드 6개와 클라이언트 파드 10개를 서로 다른 네임스페이스에 배치하고 여러 가용 영역에 분산합니다. 서버는 자신의 가용 영역을 응답하는 Flask API이며, 클라이언트는 요청을 반복하면서 자신의 가용 영역과 서버 응답을 기록합니다. 두 네임스페이스에 retina.sh=observe를 지정하고, MetricsConfiguration에서 관찰 대상과 출발지·목적지 레이블을 설정합니다. Prometheus는 Retina 파드를 찾아 메트릭을 수집하도록 구성합니다.

트래픽 분석에는 networkobservability_adv_forward_bytes를 사용합니다. 이 메트릭은 출발지와 목적지의 파드·네임스페이스·워크로드 정보 및 트래픽 방향을 담습니다. 파드의 가용 영역은 kube_pod_info로 노드를 찾고, kube_node_labels의 topology.kubernetes.io/zone 정보와 결합해 얻습니다. 제시한 PromQL은 트래픽 변화율에 출발지와 목적지의 영역 정보를 붙인 뒤, 영역이 일치하는 트래픽을 계산합니다. 저자는 나머지 바이트를 영역 간 트래픽으로 분류하고 Grafana 대시보드에서 분석합니다. 글이 제시하는 결과는 이 측정 구성과 분석 방법이며, 라우팅 변경 뒤의 비용 절감 수치는 포함하지 않습니다.

6. ltbridge의 Loki·Tempo 호환 조회 인터페이스

원문: ltbridge · caibirdme

ltbridge는 다른 로그·트레이스 저장소를 Grafana의 Loki·Tempo 데이터 소스로 조회할 수 있게 하는 Rust 프로젝트입니다. 개발자는 로그 저장과 조회를 처리하는 도구가 많아도 쓰기 편한 UI를 별도로 만드는 일이 어렵다는 점을 출발점으로 제시합니다. Grafana의 기존 플러그인을 활용하면서 저장소 선택의 폭을 넓히려는 목적입니다.

ltbridge는 Loki와 Tempo의 HTTP 인터페이스를 구현합니다. Grafana가 보낸 LogQL·TraceQL 쿼리를 해석해 SQL이나 다른 DSL로 변환하고, 해당 백엔드에서 데이터를 조회합니다. 조회 결과는 다시 Loki·Tempo 형식으로 바꿔 반환합니다. README는 ClickHouse, Databend, Quickwit 연동이 구현되어 작동하지만 추가 개선이 필요하다고 밝힙니다. 프로젝트는 활발히 개발 중입니다. 개발자는 실제 서비스 운영에는 아직 사용하지 말라고 안내하면서도, 자신들은 운영 환경에서 사용하고 있다고 덧붙입니다.

빠른 시작 예제에는 Grafana 데이터 소스가 미리 설정된 Databend와 Quickwit 구성이 들어 있습니다. 예제의 Grafana가 접근할 수 있도록 ltbridge를 로컬 6778 포트에서 실행해야 합니다. ClickHouse 연동은 중첩 타입과 맵 타입을 모두 지원하는 Rust SDK가 없다는 설명과 함께 HTTP 및 JSONEachRow를 사용하며, 8123 포트를 요구합니다. 자동 완성용 레이블은 낮은 카디널리티의 값을 지정하도록 안내합니다. Databend 설정의 전문 검색 인덱스는 상용 라이선스가 있을 때 사용하는 옵션입니다. 문서 보강, Databend·Quickwit의 인덱스 키와 값 자동 완성 개선, GA 전환은 향후 계획으로 제시합니다.

7. Tracetest의 트레이스 기반 테스트와 서비스 지원 종료

원문: Every Test Deserves a Trace · Tracetest

Tracetest의 제품 소개 페이지는 OpenTelemetry 트레이스를 테스트와 합성 모니터링에 활용하는 방식을 설명합니다. 각 테스트 실행에서 수집한 트레이스로 웹부터 백엔드까지 처리 과정을 살펴보고, 서비스와 API의 상호작용을 검증합니다. Tracetest는 애플리케이션에 OpenTelemetry 계측이 되어 있다면 코드 변경 없이 사용할 수 있다고 안내합니다. 화면에서 테스트와 세부 검증 조건을 만들고, 실패 원인을 찾거나 담당 팀을 식별하는 작업을 지원합니다.

기존 Cypress, Playwright, k6, Postman, Artillery 테스트와 함께 사용할 수 있으며, GitHub 등을 포함한 CI/CD 연동도 소개합니다. 작성한 트레이스 기반 테스트는 중요한 흐름이 계속 작동하는지 확인하는 합성 모니터로 실행할 수 있습니다. Tracetest는 E2E 테스트 작성 시간을 12시간에서 15분으로 줄여 98% 단축하고, 서비스 배포 전 테스트 실패의 문제 해결 시간을 80% 줄인다고 주장합니다. 이는 제품 페이지가 제시한 수치입니다.

같은 페이지에는 2024년 10월 31일자 「End of Life Announcement for Tracetest Cloud」 안내도 실려 있습니다. 안내문은 오픈소스 Tracetest가 계속 존재하지만 상용 Tracetest Cloud와 Enterprise 애플리케이션의 지원은 종료된다고 밝힙니다. 제품 기능 소개와 함께 이 지원 상태를 확인할 수 있습니다.

8. otel-desktop-viewer의 로컬 텔레메트리 조회

원문: otel-desktop-viewer · CtrlSpice

otel-desktop-viewer는 로컬에서 OpenTelemetry 데이터를 받아 브라우저와 CLI로 살펴보는 도구입니다. 제공된 README는 트레이스뿐 아니라 메트릭과 로그 조회도 설명합니다. 내부적으로는 맞춤형 OpenTelemetry Collector 배포판이며, desktop exporter가 duckdb 확장의 저장소에 텔레메트리를 기록합니다. 확장은 POST /rpc의 JSON-RPC API와 바이너리에 포함된 Svelte 웹 UI를 제공합니다.

기본 UI 주소는 localhost:8000이며, OTLP 수신기는 gRPC 4317 포트와 HTTP 4318 포트에서 실행됩니다. 애플리케이션의 OTLP exporter 목적지를 이 주소로 지정하면 됩니다. 데이터는 기본적으로 메모리에 저장하고, --db로 DuckDB 파일 경로를 지정하면 파일에 보관합니다. 저장 크기 제한의 기본값은 메모리 사용 시 512MB, 파일 사용 시 2GB입니다. 제한을 넘으면 오래된 텔레메트리를 지우며, --db-max-size로 제한을 바꾸거나 0으로 자동 삭제를 끌 수 있습니다.

실행 중인 뷰어에는 query 명령으로 읽기 전용 SQL을 보낼 수 있습니다. traces, logs, metrics 명령은 기본적으로 최근 한 시간에서 최대 25개의 요약을 반환하며, 서비스·시간 범위·결과 수와 JSON 출력을 지정할 수 있습니다. trace는 한 트레이스의 스팬과 연결된 로그를 보여주고, span은 스팬의 상세 정보와 연결된 로그를 조회합니다. 같은 스팬 ID가 여러 트레이스에 있으면 임의로 선택하지 않고 후보 요약을 반환합니다. 트레이스 ID와 스팬 ID를 함께 주면 정확한 쌍을 조회합니다.

설치 경로로 Homebrew Cask, 릴리스 바이너리, Linux 패키지, go install, Docker를 안내합니다. Linux 릴리스 바이너리는 glibc 2.39 이상이 필요하며, README는 이 조건이 압축 파일·패키지·Docker 이미지에 적용된다고 명시합니다. 소스 빌드에는 Go와 CGO가 필요합니다. go install의 @latest는 알파나 베타가 아닌 최신 안정 태그를 선택한다고 설명합니다.

9. VizTracer의 Python 함수 실행 시각화

원문: Welcome to VizTracer’s documentation! · VizTracer

VizTracer 1.1.1 문서의 첫 페이지 소개문과 목차를 기준으로 정리했습니다. 문서는 VizTracer를 오버헤드가 낮은 Python 로깅·디버깅·프로파일링 도구로 소개합니다. 코드를 추적하고 시각화해 실행 흐름을 이해하고 시간이 많이 드는 부분을 찾도록 돕습니다.

VizTracer는 프로그램 시작부터 끝까지 실행된 각 함수와 해당 함수의 진입·종료 시각을 표시할 수 있습니다. 문서는 이 기능이 간헐적으로 발생하는 성능 문제를 찾는 데 유용하다고 설명합니다. 목차에는 필터, 사용자 정의 이벤트, 추가 로그, 동시성, 원격 연결, 플러그인 항목이 나열되어 있습니다. 제공된 첫 페이지에는 이 기능들의 상세 동작이나 오버헤드 측정 수치는 없습니다.