promkr 뉴스레터 2026년 10월호

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

1. ObservabilityCON 2026 Grafana Cloud 기능 확장

원문: ObservabilityCON 2026: A guide to all the announcements from Grafana Labs · Grafana Labs Team · 2026-10-20

Grafana Labs가 ObservabilityCON 2026에서 발표한 Grafana Cloud 기능을 소개합니다. 정식 출시한 Assistant Watchers는 자연어로 지정한 감시 대상과 데이터 소스를 바탕으로 과거 텔레메트리의 기준선을 세우고, 기존 알림 규칙에 없는 변화를 찾습니다. 퍼블릭 프리뷰인 Managed Sandboxes는 저장소 코드와 실시간 텔레메트리를 참고해 수정안과 풀 리퀘스트를 준비하며, 사람이 검토하고 승인하는 방식입니다. Grafana Pages도 퍼블릭 프리뷰로 공개했으며, Assistant에 필요한 화면을 설명하면 코드를 작성하지 않고 앱에 가까운 시각화를 만들 수 있습니다.

비용 관리에서는 Adaptive Telemetry를 확장했습니다. Grafana Labs는 고객의 텔레메트리 지출이 평균 30%~50% 줄었다고 밝힙니다. 정식 출시한 Adaptive Metrics auto-apply는 권고를 계속 적용하며, cost-first mode는 전체 활성 시계열 수를 늘리는 권고를 막습니다. Adaptive Logs Archive는 사용자 소유 오브젝트 스토리지로 로그를 보내는 퍼블릭 프리뷰이고, 로그를 다시 가져오는 replay는 프라이빗 프리뷰입니다. Adaptive Traces가 버린 트레이스도 최근 24시간 안의 데이터라면 ID로 조회할 수 있습니다. Grafana Labs의 초기 테스트에서 Volumetric sampling은 같은 데이터량의 확률적 샘플링보다 정보 밀도가 약 25% 높았습니다.

Grafana Cloud Logs에는 Logline 기술을 적용한 전문 검색을 추가 비용 없이 정식 제공했습니다. Knowledge Graph는 시스템 구성 요소와 관계, 상태를 연결하는 플랫폼 기능으로 확장합니다. 프런트엔드 앱과 추가 클라우드 리소스 연결은 정식 출시했고, Synthetic checks와 AI agents 연결은 퍼블릭 프리뷰입니다. 사용자 정의 엔터티·관계와 AI 에이전트용 실행 시점 컨텍스트도 정식 제공하며, 서비스 담당 팀·온콜·런북과 과거 장애의 대응 기록 연결은 프라이빗 프리뷰로 소개했습니다.

사용자 경험 영역에서는 Session Replay를 퍼블릭 프리뷰로, Mobile Observability와 Critical User Journeys를 프라이빗 프리뷰로 공개했습니다. Grafana Workflows는 장애 채널 생성, 담당자 호출, 인수인계 보고서 작성 등을 이벤트 기반 단계로 연결하는 퍼블릭 프리뷰입니다. 정식 출시한 Grafana Marketplace에는 30개가 넘는 파트너 플러그인이 있습니다. Grafana Cloud 사용자는 Marketplace 플러그인의 모든 기능을 14일 동안 무료로 체험할 수 있습니다.

2. Netflix의 온톨로지 기반 장애 분석

원문: Ontology-Driven Observability: Building an End-to-End Knowledge Graph at Netflix Scale · Netflix TechBlog

Netflix는 장애 조사 지연의 원인을 데이터 부족보다 시스템 사이의 의미 불일치에서 찾습니다. Atlas, Radar, incident.io, PagerDuty, Spinnaker가 같은 대상을 서로 다른 이름과 개념으로 다루므로, 사람이 관계를 복원해야 했습니다. 글에서 든 홈 화면 지연 사례는 수정까지 4시간이 걸렸으며, 상당 부분을 이미 존재하는 관계를 다시 조립하는 데 썼습니다. 이를 줄이려고 애플리케이션, 장애, 배포 등의 유형과 속성, 관계를 명시한 Observability Ontology를 만들었습니다.

데이터 모델은 RDF, 온톨로지는 OWL, 검증은 SHACL, 질의는 SPARQL을 사용합니다. 그래프는 Rust 기반 임베디드 키·값 데이터베이스 redb를 토대로 만든 분산 quad store인 QuipuDB에 저장합니다. 애플리케이션은 ops:Application으로 통일하고, 약 49,000개 항목의 소프트웨어 카탈로그와 대조한 뒤 생성합니다. 의존 관계의 양방향 간선 수도 제한해 특정 서비스가 그래프를 압도하지 않게 했습니다. 텔레메트리뿐 아니라 장애 채팅의 가설, 폐기한 시도, 유효했던 완화 조치도 기록합니다.

Enricher는 비정형 입력을 읽고 분석해 유형이 지정된 트리플을 추가합니다. Netflix는 LLM과 퍼지 매칭의 출력을 좁은 타입 계약으로 제한해, 질의 엔진이 일관되게 읽을 수 있는 그래프를 만든다고 설명합니다. 파이프라인은 앞 단계의 결과를 다음 단계가 읽도록 순차 실행합니다. Netflix는 지표·로그·이벤트 같은 외부 시스템 호출을 최선 노력(best-effort) 방식으로 처리해 느린 하위 API가 수집 전체를 막지 않게 했습니다. 그 대신 일부 품질 저하를 감수합니다. Correlation Engine은 배포, 로그 오류, 메트릭 이상 등 13종 신호를 연결합니다. 10분 구간에서 시간적 근접성과 심각도로 평가하며, 신뢰도 0.6 미만의 연결은 버립니다.

이 엔진이 만드는 것은 결론이 아니라 근거가 붙은 가설입니다. 그래프 위의 AutoRCA는 전문 에이전트들이 같은 어휘로 조사 결과를 교환하도록 구성했습니다. Netflix는 담당 팀, 배포 이력, 유사 장애를 모으던 1~2시간의 작업을 그래프가 흡수한다고 설명합니다. 아직 초기 단계라 순위가 높은 가설도 틀릴 수 있으며, 엔지니어가 근거를 판단하고 코드를 수정해야 합니다. 자동 복구와 사전 대응은 향후 방향으로 제시하며, 제안은 사람이 검토하고 승인한다는 원칙을 둡니다.

3. Fault Tree Analysis를 이용한 인프라 SLI 설계

원문: 언제 고장 났다고 말할 수 있을까? · Lifestack · 2026-10-24

글쓴이는 데이터센터의 서버·랙·파드 관측 체계를 만들면서, 수집 가능한 메트릭보다 워크로드의 실패를 먼저 정의하는 방법을 제안합니다. 여기서 파드는 여러 랙의 서버·네트워크·전원을 묶은 PoD(Point of Delivery)입니다. 부품 목록에서 출발하면 온도, 메모리 사용률, 링크 상태는 많이 모이지만 워크로드가 실제로 영향을 받았는지 판단하기 어렵습니다. FTA는 “서버에 접속할 수 없다”처럼 막고 싶은 결과를 top event로 정하고, 원인을 아래로 분해하는 출발점이 됩니다.

하위 사건이 모두 발생해야 상위 실패가 생기면 AND, 하나만 발생해도 실패하면 OR로 연결합니다. 트리는 관측할 수 있고 대응할 수 있는 지점까지만 내려갑니다. PSU 고장을 확인하고 교체할 수 있다면 내부 부품까지 분석하지 않는 방식입니다. 최소 컷셋을 구하면 실패를 일으키는 최소 원인 조합이 드러납니다. 이중화된 서버들도 같은 PDU와 ToR 스위치를 공유하므로 공통 원인으로 랙 전체가 멈출 수 있습니다. PSU 한쪽이 이미 고장 난 서버는 남은 전원 피드의 계획된 점검만으로도 중단됩니다.

SLI는 top event의 서비스 SLI와 말단의 leaf SLI를 연결해 구성합니다. leaf에는 집계 단위, 위반 조건, 제외 대상을 정의해야 합니다. 전원·네트워크·냉각이라는 계층과, 실제 사용 불가를 뜻하는 장애·다음 고장을 버틸 여유를 뜻하는 헤드룸을 나눠 묶습니다. PSU 하나의 고장은 헤드룸 위반으로 처리하고 서비스 가용성은 유지합니다. 알림은 원인을 식별할 수 있는 leaf에 걸며, 같은 사건을 서버와 시설 지표에서 중복 집계하지 않습니다. 관측하지 못한 시간은 위반과 전체 집계에서 모두 제외하고, 그 공백은 별도의 메타 지표로 셉니다.

트리는 SLO의 상한과 공통 원인의 영향을 보여 줍니다. 전원·네트워크·냉각 가용성이 각각 99.9%이고 서로 독립이라면 서버 가용성은 대략 99.7%입니다. 임의로 설정한 서버 1,000대, 28일, 99.9% 목표의 예시에서는 서버 40대인 랙 하나의 중단이 약 17시간 만에 에러 버짓을 소진합니다. 간헐적 품질 저하, 수집하기 어려운 시설 신호, 워크로드에서만 나타나는 증상은 트리에 남는 빈틈입니다. 글쓴이는 회고, 주기적 점검, 담당 조직과의 연락으로 보완하지만 전부 메울 수는 없다고 설명합니다. 실제 레코딩 룰과 알림 구현은 후속 글의 범위로 남겼습니다.

4. hotpath-rs의 요청 맥락 기반 Rust 성능 분석

원문: How to Profile Rust Performance using Grafana and Prometheus · hotpath.rs · 2026-10-12

이 튜토리얼은 Rust 함수의 실행 시간만 보는 대신, 요청과 SQL·HTTP 호출의 관계를 붙여 성능을 분석하는 방법을 설명합니다. Grafana와 Prometheus가 이미 실행 중이라는 전제이며, 의존성 예시는 hotpath = "0.29"입니다. 기존 hotpath 계측에 hotpath-prometheus feature를 켜면 기본 포트 6772의 /metrics에서 Prometheus 형식의 지표를 제공합니다. 메모리 할당 분석에는 hotpath-alloc도 필요합니다.

SQL 분석에서는 쿼리의 속도와 호출 빈도를 함께 반영한 총 실행 시간 비중을 봅니다. Axum 라우트별로 쿼리를 연결하면 요청 하나에 어떤 SQL이 얼마나 기여하는지 좁힐 수 있습니다. 요청당 SQL 호출 횟수가 예상보다 많은 엔드포인트는 개별 쿼리가 빨라도 N+1 후보로 드러납니다. HTTP 호출도 요청당 횟수와 대기 시간을 나눠 비교합니다. 메모리는 라우트별 평균 할당 바이트에서 함수별 기여도로 내려가며, 기본 집계는 중첩 계측 함수의 할당을 제외합니다. HOTPATH_ALLOC_CUMULATIVE=true로 누적 집계할 수 있지만 재귀 함수는 중복 계산됩니다.

함수 시간은 호출한 하위 함수의 시간까지 포함합니다. 시간 샘플링을 사용하면 측정한 호출 수와 전체 호출 수를 반영해 요청당 기여 시간을 계산합니다. 채널에서는 최대 큐 크기·처리량·송수신 지연을, 락에서는 획득 전 대기 시간과 획득 후 유지 시간을 구분합니다. Tokio 워커별 작업 시간, poll, 작업 가져오기, 로컬 큐 지표도 제공하며 일부는 RUSTFLAGS="--cfg tokio_unstable" 빌드가 필요합니다. 스레드별 CPU와 할당·해제량을 호스트 지표와 나란히 놓으면 자원 사용 변화와 애플리케이션 동작을 연결할 수 있습니다.

저자는 #[hotpath::measure]의 호출당 비용을 약 40ns로 설명하고, 계산에서는 50ns로 올려 잡습니다. 이 값은 5ms 함수의 0.001%, 500ns 함수의 10%에 해당하므로 함수별 오버헤드와 전체 계측 시간에서 차지하는 비중을 함께 필터링합니다. 예시 백엔드는 트래픽이 매우 적어 수치가 다른 애플리케이션에 그대로 적용되지는 않습니다. 기준을 넘는 함수는 계측에서 제외하거나 시간 샘플링으로 비용을 줄이는 방법을 제시합니다. hotpath-cloud에서는 같은 지표를 CI 성능 예산으로 사용해 요청당 SQL 호출 5회나 특정 함수의 할당량 0 B 같은 제한을 검사할 수 있습니다.

5. VictoriaMetrics MCP Server의 조회와 진단 기능

원문: VictoriaMetrics MCP Server · VictoriaMetrics

VictoriaMetrics MCP Server는 MCP 클라이언트에서 VictoriaMetrics 인스턴스의 데이터와 문서를 조회하도록 연결하는 서버입니다. README는 VMUI에서 사용하는 거의 모든 읽기 전용 API를 지원한다고 설명합니다. 메트릭과 레이블 탐색, 시계열 조회·내보내기, 카디널리티와 사용 통계 분석, 쿼리 해설, 알림·레코딩 규칙 테스트를 제공합니다. relabeling, downsampling, retention 설정을 디버깅하는 도구도 포함합니다.

연결 대상은 단일 노드나 클러스터이며, VM_INSTANCE_ENTRYPOINT와 VM_INSTANCE_TYPE으로 지정합니다. VictoriaMetrics Cloud는 VMC_API_KEY를 사용하고 데이터 도구에 deployment_id를 전달합니다. 전송 방식은 기본값인 stdio, SSE의 sse, Streamable HTTP의 http를 지원합니다. HTTP 방식의 MCP 경로는 /mcp입니다. SSE와 HTTP 모드에서는 /metrics와 상태 확인 엔드포인트도 제공하며, MCP_AUTH_TOKEN으로 들어오는 MCP 요청을 인증할 수 있습니다.

도구가 모두 기본 활성화되는 것은 아닙니다. export, flags, metric_relabel_debug, downsampling_filters_debug, retention_filters_debug, test_rules는 기본 비활성 목록에 있습니다. MCP_DISABLED_TOOLS로 이 목록을 설정합니다. README의 대화 예시는 조회하지 않은 메트릭을 찾고 실제 시계열로 relabel 설정을 시험한 뒤, downsampling 설정을 검토하는 흐름입니다. 이 과정에서 서버는 데이터 조회와 설정 시험에 필요한 도구를 제공합니다. 어시스턴트는 조회·시험 결과를 바탕으로 사용자가 적용할 설정을 제시합니다.

문서와 블로그를 담은 내장 벡터 데이터베이스 덕분에 온라인 접속 없이 문서를 검색할 수 있습니다. README는 이 데이터베이스가 서버 자원 사용의 주된 원인이며, documentation 도구를 비활성화하면 로딩을 완전히 끌 수 있다고 설명합니다. 소스 빌드에는 Go 1.26 이상이 필요하고, 바이너리·Docker·Helm 설치 방법도 제공합니다. 응답 품질은 클라이언트와 모델의 역량에 크게 좌우되며, 프로젝트는 AI 결과의 정확성·완전성·신뢰성을 보장하지 않으므로 결과를 재확인하라고 명시합니다.

6. NVIDIA와 CoreWeave의 메트릭 활용 사례

원문: Observability Lessons NVIDIA and CoreWeave · Pablo Fernandez · 2026-10-19

VictoriaMetrics의 Pablo Fernandez는 NVIDIA와 CoreWeave가 메트릭을 대시보드 밖에서 활용하는 사례를 소개합니다. 저자는 2026년 9월 같은 주에 NVIDIA의 번들 제공과 CoreWeave의 사용 사실을 알게 됐다고 밝힙니다. 저자는 두 회사가 각각 독립적으로 VictoriaMetrics를 도입했다고 설명합니다. 자신도 그 사실을 최근에야 알았다고 덧붙입니다. NVIDIA에서는 메트릭이 GPU 인스턴스 자동 확장에 쓰이고, CoreWeave에서는 AI 에이전트의 시설 분석에 사용됩니다.

NVIDIA Cloud Functions는 추론 모델을 함수로 패키징하고 요청을 GPU 워커로 보내는 플랫폼입니다. 자체 관리형 에디션은 사용자 Kubernetes 클러스터에서 실행되며, NVCF Release 1.0.1은 단일 노드 VictoriaMetrics chart를 기본 메트릭 저장소로 포함합니다. Function Autoscaler는 함수 호출 메트릭과 큐 깊이를 읽어 필요한 GPU 인스턴스 수를 조절합니다. 수집은 OpenTelemetry Collector와 공개 프로토콜을 사용하므로 VictoriaMetrics 사용을 강제하지 않습니다. NVIDIA의 릴리스 노트에는 선택 이유가 없으며, 단일 바이너리의 단순함, 자원 효율, 장애 복구 특성, Apache 2.0 라이선스는 저자가 추정한 이유입니다.

저자가 전해 들은 바에 따르면, CoreWeave는 인프라 고객에게 제공하는 메트릭의 백엔드로 VictoriaMetrics를 사용합니다. 2026년 9월 24일 정식 출시한 Mission Control MCP는 AI 도구가 메트릭, 로그, 문서를 조회하도록 연결합니다. 시설 엔지니어 Rick Donohue는 이미 수집하던 온도와 습도 데이터를 바탕으로 데이터센터의 결로 위험을 조사했습니다. 공기의 이슬점보다 차가운 표면에는 결로가 생기므로, GPU 주변 냉각 배관의 상태를 살피는 데 필요한 분석이었습니다.

Claude는 VictoriaMetrics를 조회해 결로 조건에 가까워지는 측정값을 찾고, 대시보드에 습공기선도를 그릴 JavaScript 코드를 생성했습니다. 습공기선도는 습한 공기의 열역학적 성질을 나타내며, 엔지니어는 어느 조건이 결로 위험 쪽으로 이동하는지 확인할 수 있었습니다. 이 사례에서 시설 지식은 엔지니어가 제공하고, AI는 기존 측정값 탐색과 시각화 코드 작성을 수행했습니다.