promkr 뉴스레터 2026년 4월호

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

1. Prometheus 쿼리의 평가 시점과 데이터 범위

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

이 글은 instant query와 range query를 데이터 선택자의 종류와 구분해 설명합니다. node_cpu_usage 같은 표현식은 instant vector selector이며, 실행 방법에 따라 단일 시점이나 여러 시점에서 평가할 수 있습니다. Instant query는 표현식을 한 번 평가하고, range query는 시작부터 끝까지 step 간격으로 반복 평가합니다. 따라서 표현식에 시간 범위가 있는지와 쿼리를 몇 번 평가하는지는 별개의 문제입니다.

Instant vector selector는 평가 시점을 넘지 않는 가장 최근 샘플을 시계열마다 하나씩 선택합니다. Prometheus의 기본 lookback delta는 5분이며, --query.lookback-delta로 바꿀 수 있습니다. 이 범위 안에 최근 샘플이 없으면 해당 시계열은 결과에서 빠집니다. Range query에서도 각 평가 시점에 같은 규칙을 적용하므로, 실제 수집 시각과 결과의 타임스탬프가 달라집니다. 예를 들어 00:10 평가에는 00:09 샘플을, 00:15 평가에는 00:13 샘플을 사용할 수 있습니다.

[5m] 같은 range selector의 범위는 step과 역할이 다릅니다. max_over_time(node_cpu_usage[3m])을 step: 5m으로 실행하면 5분마다 직전 3분의 최댓값을 계산합니다. 그 3분 안에 샘플이 없으면 해당 평가 결과도 없습니다. http_requests_total[5m]을 instant query로 실행하면 한 번의 평가에서 직전 5분의 원시 샘플을 반환하며, 원래 수집 타임스탬프를 유지합니다.

Prometheus는 range query의 각 평가 결과로 scalar나 instant vector를 요구합니다. 그래서 http_requests_total[5m]처럼 range vector를 반환하는 표현식을 그대로 실행하면 오류가 납니다. 글은 VictoriaMetrics가 이 경우 last_over_time(http_requests_total[5m])처럼 각 평가 시점의 최근 값을 선택한다고 설명합니다. VictoriaMetrics의 lookback 범위도 Prometheus와 달리 자동으로 결정하며, 설정으로 덮어쓸 수 있습니다.

2. Shopify의 자체 옵저버빌리티 플랫폼 Observe

원문: Shopify’s Journey to Planet-Scale Observability · Dotan Horovits · 2025-02-27

Dotan Horovits가 Shopify의 옵저버빌리티 개편을 이끈 Elijah McPherson과 나눈 대화를 소개합니다. Shopify는 수천 개 서비스와 초당 수십억 개 이벤트를 처리하는 규모에서 비용, 성능, 데이터 통제 요구를 충족하려고 Observe를 만들었습니다. 기사에 따르면 기존 외부 솔루션의 연간 비용은 데이터 유입 증가에 따라 수천만 달러에 이를 것으로 예상됐습니다. Shopify는 자체 구축 이후 스토리지 비용을 80% 넘게 줄이고 쿼리 성능과 시스템 신뢰성을 개선했다고 밝혔습니다.

Observe는 로그, 메트릭, 트레이스, 프로파일링 데이터를 하나의 UI에서 연결합니다. 메트릭에는 StatsD와 Prometheus, 로그에는 Loki, 분산 트레이싱에는 Tempo를 사용합니다. 시각화는 Grafana가 맡고 분석 저장소에는 ClickHouse와 Apache Parquet를 활용했습니다. Shopify는 자체 Grafana 플러그인도 만들어 고객 전환율과 인프라 성능을 같은 패널에 표시했습니다. 자동 의존성 매핑은 장애 서비스 식별을 돕고 평균 복구 시간을 줄였다고 설명합니다.

OpenTelemetry 도입으로 서비스 간 호환성을 확보하고, 처리량이 높은 서비스에서 15~20%의 성능 오버헤드를 일으키던 독점 에이전트를 제거했습니다. 엔지니어의 사용 경험도 플랫폼 설계에 포함했습니다. McPherson은 자연어 쿼리 도우미가 흔한 문제 해결 패턴에 맞춰 PromQL과 LogQL을 제안해 진단 시간을 30~40% 절약했다고 말합니다. 요청 지연과 결제 이탈률을 연결하는 대시보드는 고객 영향에 따라 수정 순서를 정하는 데 쓰입니다.

전환 과정에서는 기존 스택과 새 스택에 데이터를 함께 기록했습니다. 결과가 일치하는지 확인한 뒤 전환했고, 카나리 배포로 성능 개선을 검증한 후 적용 범위를 넓혔습니다. McPherson은 자체 구축이 Shopify처럼 비용·성능·통제 문제가 큰 규모에서 의미가 있다고 설명합니다. 대부분의 팀에는 관리형 솔루션으로 충분하다는 조건도 제시했습니다.

3. Envoy 사이드카를 이용한 애플리케이션 메트릭 수집

원문: Envoy Sidecar Proxy: Efficient Metrics Without Modifying the Application · Alexander Ibrahim · DevOps.dev · 2024-09-22

Alexander Ibrahim은 애플리케이션 코드를 바꾸지 않고 요청률, 지연, 오류율 같은 메트릭을 수집하는 Envoy 사이드카 구성을 설명합니다. Kubernetes 자동 확장에 필요한 관측 정보를 애플리케이션 내부에 직접 구현하는 대신, 같은 Pod의 프록시가 트래픽을 처리하며 수집하게 합니다. 예제에서는 서비스로 들어오는 요청을 Envoy에 먼저 보내고, Envoy가 로컬 애플리케이션으로 전달합니다.

설정은 envoy-config ConfigMap에 넣습니다. listener_0은 0.0.0.0:8080에서 HTTP 요청을 받고, 모든 도메인의 / 경로를 app_service 클러스터로 보냅니다. 이 클러스터의 대상은 같은 Pod 안의 127.0.0.1:80이며, 연결 제한 시간은 0.25s입니다. Deployment 예제는 nginx:1.21 애플리케이션과 envoyproxy/envoy:v1.20.0 사이드카를 사용합니다. Envoy는 /etc/envoy에 마운트한 설정을 --config-path /etc/envoy/envoy.yaml로 읽습니다.

Service는 HTTP 포트 80을 Envoy의 8080에 연결하고, 메트릭 수집용 admin 포트 9901도 노출합니다. Service 유형은 클러스터 내부에서 사용하는 ClusterIP입니다. 포트 포워딩 후 /stats에서 통계를 확인하고 /stats/prometheus에서 Prometheus 형식의 메트릭을 확인할 수 있습니다. Prometheus 예제에는 job_name: envoy, scrape_interval: 15s, metrics_path: /stats/prometheus, 수집 대상 envoy:9901을 지정합니다.

이 구성에서 애플리케이션 요청은 Envoy를 거쳐야 하며, Prometheus는 별도의 admin 엔드포인트를 수집합니다. 저자는 ConfigMap 작성, 사이드카 추가, Service 수정, Prometheus 등록으로 요청률·지연·연결 정보를 얻고 이를 자동 확장 판단에 활용할 수 있다고 설명합니다. 본문은 수집 구성 절차를 다루며, 전체 구성 파일은 envoy-sidecar 저장소에 제공한다고 안내합니다.

4. 전문 에이전트로 운영 작업을 분담하는 Opsy

원문: Opsy - Your AI-Powered SRE Colleague · GitHub

Opsy는 SRE, DevOps 담당자, 플랫폼 엔지니어를 위한 명령줄 AI 도우미입니다. Anthropic의 Claude 모델로 자연어 요청을 해석하고 실행 계획을 세워 필요한 작업을 수행합니다. README는 장애 조사와 반복 작업 자동화를 용도로 제시합니다. 데모 설명에는 실패한 Pod를 분석해 Jira 이슈 하나로 모으고, Deployment 매니페스트를 새 비공개 GitHub 저장소에 백업하는 복합 작업이 나옵니다.

설계는 각 도구를 해당 분야의 전문 AI 에이전트로 취급하는 tools-as-agents 방식입니다. 주 에이전트가 복잡한 요청을 나누고 Kubernetes, Git, AWS 등의 전문 에이전트에 맡깁니다. 프로젝트는 이 방식이 도구별 검증, 여러 단계 작업의 문맥 관리, 기능 확장을 돕는다고 설명합니다. Git, GitHub CLI, kubectl, AWS CLI, Helm, Google Cloud CLI, Jira CLI와 연동하며, 사용자 시스템에 설치된 도구만 사용합니다. 개별 CLI는 Opsy 실행 자체의 필수 조건은 아닙니다.

Claude 사용에는 Anthropic API 키가 필요합니다. 설정 파일은 ~/.opsy/config.yaml이며, OPSY_ 접두사를 붙인 환경 변수로도 값을 지정할 수 있습니다. API 키에는 ANTHROPIC_API_KEY도 지원합니다. README의 기본 설정은 모델 claude-3-7-sonnet-latest, temperature: 0.5, max_tokens: 1024, 도구 실행 제한 시간 120초입니다. Go로 설치할 때는 Go 1.24 이상이 필요하고, Homebrew와 릴리스 바이너리 설치도 제공합니다.

확장 지점은 시스템 프롬프트, 도구 정의, UI 테마입니다. 도구 정의에는 실행 파일, 입력값, 사용 규칙 등을 YAML로 기록합니다. 라이선스는 Apache License 2.0입니다. 프로젝트는 아직 초기 개발 단계이며 일부 기능을 다듬고 있다고 밝힙니다. 현재는 실제 서비스 운영에 쓰지 않는 환경에서 사용하도록 권고합니다.

5. eBPF와 PSI로 자원 경합을 추적하는 Linnix

원문: Linnix · GitHub

Linnix는 자원 사용량만으로 설명하기 어려운 지연을 조사하는 Linux 옵저버빌리티 도구입니다. PSI로 실제 정체 시간을 측정하고 eBPF 이벤트를 연결해 어떤 프로세스나 Pod가 다른 워크로드와 경합했는지 추적합니다. README는 noisy neighbor, fork storm, CPU·I/O·메모리 압력을 탐지 대상으로 제시합니다. 기본 동작은 관측과 보고이며, 명시적으로 설정하지 않으면 제어 동작을 실행하지 않습니다.

eBPF 수집기는 fork, exec, exit, 스케줄러 이벤트를 관찰합니다. 프로젝트는 이 수집기의 오버헤드가 1% 미만이라고 설명합니다. 분석 엔진은 PSI, CPU, 프로세스 트리를 결합하고 임계값을 넘으면 시스템 상태를 수집합니다. 탐지 조건에는 PSI 40% 초과와 CPU 90% 초과의 조합, 2초 동안 초당 10회 초과의 fork가 포함됩니다. AI 모델은 선택 사항이며 기본적으로 꺼져 있습니다. 경합 귀속에는 모델이 필요하지 않고, 로컬 LLM을 켜면 첫 실행 때 2.1GB 모델을 내려받습니다.

관측 결과는 Prometheus counter로 제공합니다. linnix_pod_psi_pressure_total은 피해 Pod의 압력을 마이크로초 단위로, linnix_stall_induced_seconds_total은 원인으로 지목된 Pod와 피해 Pod 쌍의 정체를 초 단위로 기록합니다. 피해 Pod의 정체 시간은 각 상대의 기여도에 비례해 나누므로 합계가 실제 정체 시간을 넘지 않습니다. linnix-cli investigate는 저장된 귀속 기록을 모아 사후 조사에 사용합니다. README는 이 결과가 경합의 귀속이며 입증된 인과관계는 아니라고 명시합니다. 수정 효과는 한 조건을 바꾸고 정체 시간이 감소하는지 관찰해 확인하도록 설명합니다.

지원하지 않는 커널이나 BTF 누락으로 eBPF를 연결하지 못하면 /proc/pressure의 PSI 제공은 계속됩니다. 이 상태에서는 원인 식별 기능을 잃으므로 /readyz가 503을 반환합니다. Kubernetes 배포는 현재 privileged 모드의 DaemonSet을 사용합니다. 분석은 로컬에서 수행하며, Slack 알림을 명시적으로 설정하지 않으면 인프라 밖으로 데이터를 보내지 않는다고 밝힙니다. cognitod 에이전트는 AGPL-3.0, eBPF 수집기는 GPL-2.0 또는 MIT 라이선스입니다.

6. 여러 지역에서 사용자 흐름을 검사하는 Upright

원문: Introducing Upright: An Open Source Synthetic Monitoring System · Lewis Buckley · 2026-02-16

37signals는 Basecamp, HEY, Fizzy 등을 감시하던 자체 합성 모니터링 시스템 Upright를 MIT 라이선스로 공개했습니다. 기존 Pingdom에서는 검사 방식과 실행 위치를 원하는 대로 통제하기 어려웠고, 인증이 필요한 브라우저 흐름에는 추가 비용이 들었다고 설명합니다. Upright는 기존 모니터링을 보완하는 내부 도구로 시작했으며, 글을 쓴 시점에는 전 세계 다섯 거점의 합성 모니터링을 모두 담당하고 있습니다.

Playwright 프로브는 실제 브라우저로 로그인하고 화면을 이동하며 사용자 흐름을 검사합니다. 검사는 Playwright API를 사용하는 Ruby 클래스로 작성하고, 실패하면 영상과 로그를 남깁니다. HTTP 프로브는 모든 거점에서 30초마다 URL의 상태 코드를 확인합니다. SMTP 프로브는 EHLO 응답, STARTTLS 지원, SSL 인증서 유효성을 점검하고, Traceroute 프로브는 MTR 보고서로 홉별 지연을 추적합니다. 모든 프로브는 배포한 각 거점에서 실행하며, 시작 시각을 몇 초씩 분산할 수도 있습니다.

Upright는 Rails engine이며 SQLite에 검사 결과를 저장하고 Solid Queue로 백그라운드 작업과 반복 작업을 실행합니다. Kamal이 여러 서버 배포를 맡고 Prometheus와 AlertManager가 메트릭 조회와 알림을 담당합니다. 각 노드는 독립적으로 검사하며, 로컬 OpenTelemetry collector가 수집한 메트릭을 주 거점으로 보냅니다. 37signals는 이중화를 위해 자체 데이터센터들과 주 Upright 인스턴스에 있는 총 세 Prometheus 인스턴스로 메트릭을 전송한다고 설명합니다. 여러 거점의 결과는 특정 지역의 연결 문제와 전체 장애를 구분하는 데 쓰입니다.

37signals가 제시한 구성은 각각 2 vCPU·4GB RAM인 DigitalOcean 서버 네 대와 3 vCPU·4GB RAM인 Hetzner 서버 한 대이며, 전체 비용은 월 약 110달러입니다. Hetzner만 사용하는 최소 두 거점 구성은 월 20달러 미만으로 실행할 수 있다고 안내합니다. 설치 생성기는 Prometheus·AlertManager·OpenTelemetry collector 설정, 프로브 디렉터리, Kamal 배포 템플릿, 로컬 개발용 Docker Compose 파일을 만듭니다.

7. Cloudflare Workers용 Rust 트레이스 수집기

원문: An OpenTelemetry collector in Rust for Cloudflare Workers · Mies · 2025-02-18

Fiberplane은 Cloudflare D1에서 지속되는 지연의 병목을 찾으려고 otel-worker를 만들었습니다. Cloudflare Workers에 맞춘 오픈소스 OpenTelemetry 수집 서비스로, 트레이스를 수집하고 D1에 저장해 탐색합니다. Fiberplane은 일반적인 수집기 운영에 필요한 인프라와 YAML 설정을 줄이는 것을 목표로 설명합니다. 글의 작성 시점에는 D1의 읽기 복제본이 아직 구현되지 않았다는 제약도 언급했습니다.

구현 언어는 Rust이며 API에는 Axum을 사용합니다. 공통 코드는 otel-worker-core에 두어 Worker와 CLI가 함께 사용합니다. otel-worker에는 Cloudflare에서 OTLP 수집 코드를 실행하는 workers-rs 코드, D1용 Store 구현, Durable Objects를 이용한 WebSocket 연결 구현이 들어갑니다. CLI는 Cloudflare Worker 환경을 모사하는 로컬 개발 서버와 트레이스·스팬 조회 및 삭제 명령을 제공합니다. 데이터베이스 정리와 실시간 트레이스 갱신을 보는 WebSocket 모니터링 기능도 포함합니다.

수집 프로토콜은 OTLP/HTTP이며 JSON과 Protocol Buffers 인코딩을 지원합니다. gRPC는 지원하지 않습니다. /v1/traces에 트레이스를 전송하고 HTTP 엔드포인트로 저장된 트레이스를 조회할 수 있습니다. 새 트레이스 알림에는 WebSocket을 사용합니다. OTLP/HTTP 수집 엔드포인트와 트레이스 조회 엔드포인트 모두 bearer token 인증이 필요하며, 설정에서 AUTH_TOKEN을 지정합니다.

로컬 개발에는 Rust와 Wrangler CLI가 필요합니다. D1 데이터베이스를 만들고 마이그레이션을 적용한 뒤 wrangler.toml에 데이터베이스 정보를 기록합니다. 인증 토큰은 .dev.vars에 설정하고 npx wrangler dev로 서버를 시작합니다. 글에서 제시한 로컬 주소는 http://localhost:8787입니다. 작성 시점에는 Windows에서 WSL 없이 Worker를 컴파일하는 방식을 지원하지 않았습니다. Fiberplane은 Cloudflare의 공식 OpenTelemetry 솔루션 출시 전까지 트레이스를 저장하고 탐색할 수 있는 대안으로 이 도구를 소개합니다.