promkr 뉴스레터 2025년 9월호

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

1. 주간 패턴을 반영한 Prometheus 응답시간 이상 탐지

원문: Anomaly Alerting in Prometheus · Karl Stoney · 2023-03-08

Karl Stoney는 Auto Trader에서 서비스마다 고정 임계값을 정하지 않고 응답시간 악화를 탐지하는 방법을 소개합니다. Istio의 istio_request_duration_milliseconds_bucket을 레코딩 룰로 집계하고, histogram_quantile로 destination_workload별 P95 시계열을 만듭니다. 원문의 구성은 네임스페이스당 워크로드가 하나입니다. 구성이 다르면 destination_workload_namespace를 추가하거나 destination_service로 묶을 수 있습니다.

예측값은 지난 1주·2주·3주의 같은 시점에서 가져온 표본의 중앙값입니다. 각 표본은 5분 평균으로 평활화하며, 과거의 해당 시각을 중심으로 앞뒤 2.5분을 포함하도록 오프셋을 조정합니다. 최종 예측 룰에는 최근 1주 평균과 그보다 1주 앞선 평균의 차이를 더해 응답시간 수준의 변화도 반영했습니다. label_replace로 표본을 구분한 뒤 quantile(0.5, …) without(offset)으로 중앙값을 구합니다.

이후 현재 값과 예측값의 5분 평균 차이를 지난 1주 표준편차로 나누어 z-score를 계산합니다. 음수는 과거보다 응답시간이 짧아졌다는 뜻일 수 있으므로, 저자는 응답시간 악화를 나타내는 양수만 경고 대상으로 삼았습니다. 예시 경고는 z-score가 3을 초과하는 상태가 5분간 이어지면 warning으로 발생합니다. 짧은 지연 급증만으로 경고가 발생하지 않도록 지속 시간을 둔 구성입니다.

저자는 더 긴 기간의 데이터를 관찰하고 트래픽 패턴에 맞게 시간 창과 임계값을 조정하라고 설명합니다. 예측에는 레코딩 룰로 쌓은 3주치 데이터가 필요합니다. promtool로 과거 데이터를 채울 수도 있지만 처리 비용이 크고 오래 걸릴 수 있으며, 블록 작성 후 compaction이 일어나야 결과를 확인할 수 있습니다.

2. LLM의 자율 장애 원인 분석 실험

원문: Can LLMs replace on call SREs today? · Lionel Palacin and Al Brown · 2025-08-14

ClickHouse는 SRE 업무 중 근본 원인 분석을 골라 LLM이 얼마나 독립적으로 수행하는지 실험했습니다. OpenTelemetry 데모 애플리케이션에서 결제 실패, 추천 캐시 누수, 특정 상품 조회 실패를 각각 담은 약 1시간 데이터셋을 만들고, 결제 캐시 누수가 있는 기존 48시간 데이터셋도 사용했습니다. 신규 데이터는 부하를 사용자 1,000명까지 늘린 뒤 장애 기능을 약 40분 켜고, 끈 뒤 약 10분 더 수집한 것입니다.

연구진은 먼저 ClickStack에서 수동으로 장애를 조사해 비교 기준을 마련했습니다. 모델에는 LibreChat과 ClickHouse MCP 서버를 연결하고 같은 짧은 프롬프트로 문제·원인·해결책을 찾도록 요청했습니다. 첫 응답이 틀리면 후속 질문이나 추가 맥락을 제공했습니다. 평가는 원인 식별의 정확도뿐 아니라 필요한 안내, MCP 호출 수, 토큰 사용량, 조사 시간과 비용을 포함합니다.

결제 장애에서는 Claude Sonnet 4와 OpenAI o3가 첫 요청만으로 gold 등급 사용자의 토큰 오류를 찾았습니다. 두 모델 모두 MCP 호출 15회와 2분이 걸렸지만, 보고된 비용은 각각 $3.15와 $0.17입니다. GPT-4.1과 Gemini 2.5 Pro에는 추가 안내가 필요했습니다. 추천 캐시 장애에서는 모델들이 서비스 장애나 자원 고갈을 발견하고도 캐시 문제까지 추적하지 못하거나, 정상적인 장시간 스트리밍 호출을 병목으로 오인했습니다. o3는 안내 후 캐시를 원인으로 지목했지만 애플리케이션에 없는 코드를 해결책으로 제시했습니다.

ClickHouse는 이 평가에서 자율 원인 분석이 기대한 속도와 비용 이점을 충족하지 못했으며, GPT-5도 다른 모델을 앞서지 못했다고 밝힙니다. 저자들이 제안하는 역할은 엔지니어가 조사를 통제하는 가운데 결과를 요약하고, 상황 공유 초안을 작성하며, 다음 조사 단계를 제안하는 보조입니다. 원문은 이어서 상품 조회 실패와 결제 캐시 누수 시나리오도 다룹니다. 점수를 매겨 비교한 결과, o3가 가장 높은 점수를 받았습니다. 저자들은 o3가 Claude Sonnet 4와 비슷한 조사 능력을 보이면서 토큰은 더 적게 썼다고 평가합니다. GPT-4.1은 비용이 가장 낮았지만 조사 능력은 두 모델에 크게 못 미쳤습니다. 모든 모델이 첫 요청만으로 쓸 만한 근본 원인 분석 보고서 초안을 작성했으므로, 저자들은 보고서 초안 작성을 자동화 후보로 꼽습니다. 저자들은 한 시간 분량의 합성 장애를 단순한 프롬프트로 시험한 실험이어서 실제 운영 환경의 복잡도를 반영하지 못했다고 밝힙니다. 컨텍스트 보강이나 파인튜닝 같은 기법도 적용하지 않았다고 설명합니다.

3. OpenTelemetry 기반의 Grafana Beyla 2.5 기능 확장

원문: Building on the foundation of OpenTelemetry eBPF Instrumentation: what’s new in Grafana Beyla 2.5 · Marc Tuduri · 2025-08-04

Grafana Labs는 eBPF 기반 자동 계측 도구 Beyla를 OpenTelemetry에 기여하고, 업스트림 프로젝트 이름을 OpenTelemetry eBPF Instrumentation으로 정했습니다. Beyla는 이 프로젝트의 Grafana Labs 배포판으로 계속 유지됩니다. 2.5는 코드 대부분을 업스트림 저장소에서 직접 가져와 포함하는 첫 Beyla 릴리스입니다. Grafana Labs는 이 방식으로 업스트림 기능을 Beyla에 반영하고, Beyla의 개선 사항을 커뮤니티에 돌려주며, OpenTelemetry 표준과의 호환성을 유지한다고 설명합니다.

자동 계측 범위에는 MongoDB와 Go 애플리케이션의 JSON-RPC가 추가됐습니다. MongoDB 프로토콜로 클라이언트 호출을 수행하는 Go·Python·Java 등의 애플리케이션은 코드 변경이나 SDK 통합 없이 작업을 수집할 수 있습니다. Go의 JSON-RPC 지원은 클라이언트 라이브러리 구현에 관계없이 프로토콜 사용을 계측하는 방식입니다. 원문은 JSON-RPC를 많이 사용하는 블록체인·암호화폐 서비스 간 통신을 활용 대상으로 들었습니다.

Go에서는 수동 스팬을 추가하는 기능도 제공합니다. 자동으로 포착하지 못하는 비즈니스 로직이나 작업을 계측하고 사용자 정의 속성을 붙일 수 있으며, 이 스팬은 Beyla의 자동 계측과 연결됩니다. NodeJS에서는 컨텍스트 전파를 개선해 여러 언어와 프레임워크를 가로지르는 트레이스의 연결 신뢰성을 높였습니다. Grafana Labs는 이 개선으로 끊어진 트레이스 연결을 줄일 수 있다고 설명합니다.

새로운 survey mode는 전체 계측을 수행하기 전에 서비스·프로토콜·통신 패턴을 찾아 보고하는 경량 탐색 기능입니다. 애플리케이션 구성을 파악하거나 자동 계측 대상 서비스를 찾는 용도입니다. 릴리스에는 커뮤니티 피드백과 내부 테스트를 반영한 버그 수정 및 성능 개선도 포함됐습니다.

4. Amazon ECS에서 Beyla 사이드카로 트레이스 수집

원문: Observability for containerized workloads: How to run Grafana Beyla as a sidecar in Amazon ECS · Matt Wimpelberg · 2025-07-10

이 글은 Amazon ECS 태스크에 Grafana Beyla를 사이드카로 배치해 애플리케이션 코드 변경 없이 트레이스를 수집하는 구성을 설명합니다. 예제는 EC2에서 실행하는 ECS를 사용합니다. AWS Fargate의 ECS는 Beyla가 사용하는 eBPF를 지원하지 않으므로 대상에서 제외됩니다. 수집한 텔레메트리는 Grafana Alloy의 OpenTelemetry 리스너로 보내고, Alloy가 Grafana Cloud로 전달합니다.

Alloy 설정은 AWS Systems Manager Parameter Store에 저장하고 ECS 태스크 정의에서 ALLOY_CONFIG_CONTENT로 참조합니다. 태스크 실행 IAM 역할에는 해당 설정을 읽을 권한이 필요합니다. HTTP 전송은 4318 포트를 열어 사용하며, gRPC를 선택하면 4317 포트를 노출하고 Beyla의 내보내기 설정도 바꿉니다. Alloy에는 서비스 탐색용 DNS 이름을 부여합니다. Grafana Cloud로 전송하는 서비스가 위치한 서브넷에는 인터넷 접근이 필요합니다.

Go 예제 애플리케이션의 태스크 정의에는 "pidMode": "task"를 지정합니다. 이 설정으로 Beyla가 같은 태스크의 다른 컨테이너에 있는 프로세스 ID를 읽을 수 있습니다. 계측 대상은 BEYLA_EXECUTABLE_NAME의 goblog와 BEYLA_OPEN_PORT의 8443으로 지정하고, OTEL_EXPORTER_OTLP_TRACES_ENDPOINT에는 Alloy 수신 주소를 넣습니다. 예제는 애플리케이션의 8443 포트에 로드 밸런서를 연결하며, 수신기와 통신할 수 있도록 서비스를 Alloy와 같은 네임스페이스에 둡니다.

도착한 데이터는 Grafana Tempo 기반의 Grafana Cloud Traces에서 조회합니다. 원문은 TraceQL 조회 결과를 예로 들며, 다른 출처의 트레이스와 함께 분석할 수 있다고 설명합니다. Cloud Traces에서 자동 생성하는 메트릭은 Grafana Cloud Application Observability에도 사용됩니다.

5. OOM 직전 Go 힙 프로필을 수집하는 OOMProf

원문: OOMProf - eBPF-based OOM Kill Profiler · parca-dev

OOMProf는 Linux OOM killer가 Go 프로세스를 종료하기 직전에 힙 프로필을 자동으로 수집하는 eBPF 기반 도구입니다. 종료 후 메모리 사용 패턴을 분석할 수 있도록 할당 내역, 호출 스택, 힙 사용량을 pprof 호환 파일로 남깁니다. 실행 중인 Go 프로그램을 자동으로 찾는 감시 모드 외에, 지정한 PID의 프로필을 즉시 수집하는 기능도 있습니다.

감시기는 시스템의 Go 프로세스를 검색하고 메모리 버킷 주소를 추적합니다. oom/mark_victim 트레이스포인트에서 종료 대상이 된 Go 프로세스를 감지한 뒤, signal/signal_deliver 트레이스포인트를 사용해 커널 공간에서 힙 프로필 데이터를 수집합니다. 생성한 {command}-{pid}.pb.gz 파일은 go tool pprof의 대화형 분석, 웹 인터페이스, 상위 메모리 소비 항목 조회에 사용할 수 있습니다.

주 실행 파일은 oompa입니다. 인자 없이 실행하면 Go 프로세스를 감시하고, -p에 쉼표로 구분한 PID를 전달하면 해당 프로세스들의 프로필을 만든 뒤 종료합니다. 라이브러리로 사용할 때는 oomprof.Setup에 프로필 채널을 전달하고, 수신한 프로필을 애플리케이션에서 저장할 수 있습니다. 실행에는 eBPF를 지원하는 Linux 커널 4.9 이상과 root 권한이 필요하며, 빌드에는 Go 1.21 이상을 요구합니다.

저장소에는 cgroup 메모리 제한으로 OOM을 재현하는 테스트와 GC 캐시 부하 테스트가 포함돼 있습니다. Goroutine 덤프 수집, Kubernetes/cgroup 배포 지원, 원격 프로필 업로드는 로드맵의 계획 항목입니다. jemalloc·tcmalloc·mimalloc 지원과 Python 메모리 프로파일링도 아직 계획으로 구분돼 있습니다.

6. Claude Code 사용량과 비용의 Grafana 모니터링

원문: Claude Code + OpenTelemetry + Grafana: a guide to tracking usage and limits · Rafał Strzaliński · 2025-07-31

Rafał Strzaliński는 Claude Code의 기본 OpenTelemetry 지원을 사용해 사용량과 비용을 관찰하는 구성을 소개합니다. API의 토큰별 과금과 Pro·Max 요금제의 불명확한 사용 제한을 사용자가 파악하기 어렵다는 문제에서 출발합니다. 제시한 방법은 별도 프록시나 수집기를 운영하지 않고 Claude Code에서 Grafana Cloud의 OpenTelemetry 엔드포인트로 로그와 메트릭을 직접 보내는 방식입니다.

Grafana Cloud Portal에서 사용할 스택의 OpenTelemetry 설정을 열고, OTLP 수집 권한이 있는 API 토큰을 생성합니다. Claude Code 실행 전에는 CLAUDE_CODE_ENABLE_TELEMETRY=1로 텔레메트리를 켜고, OTEL_METRICS_EXPORTER와 OTEL_LOGS_EXPORTER를 otlp로 지정합니다. 전송 프로토콜은 http/protobuf이며, 엔드포인트와 인증 헤더도 환경 변수로 제공합니다. 예제의 OTEL_METRIC_EXPORT_INTERVAL 값은 10000, OTEL_LOGS_EXPORT_INTERVAL 값은 5000입니다.

Claude Code가 내보내는 api_request, tool_result 등의 이벤트는 Loki에 구조화된 로그로 쌓입니다. Grafana Explore에서 이를 검색하고 필터링할 수 있으며, LogQL로 로그에서 메트릭을 추출하는 방법도 제시합니다. 저자가 출발점으로 제시한 대시보드는 시간에 따른 전체 API 요청 수, 입력·출력 토큰의 합계, 세션당 예상 비용, P95/P99 요청 지연을 표시합니다. 각 지표는 활동량 변화, 토큰 소비, 작업별 비용, 느린 요청을 파악하기 위한 것입니다.

저자는 기본적인 사용량 모니터링에는 Grafana Cloud 무료 등급으로 충분하다고 설명합니다. 남는 작업은 대시보드 구성입니다. 의미 있는 화면을 만들려면 수작업과 PromQL 또는 LogQL 지식이 필요하다고 밝힙니다.

7. Go OpenTelemetry 계측의 자원 사용량 측정

원문: OpenTelemetry for Go: measuring the overhead · Nikolay Sivko · 2025-06-13

Nikolay Sivko는 요청마다 Valkey의 카운터를 증가시키는 간단한 Go HTTP 서버로 OpenTelemetry SDK의 오버헤드를 측정했습니다. 애플리케이션, Valkey, 부하 생성기, Coroot Community Edition을 각각 별도 Linux 노드에 배치했습니다. 각 노드는 4 vCPU와 8GB RAM을 갖추고, Docker 컨테이너는 host network 모드로 실행했습니다. 부하는 wrk2의 8개 스레드와 100개 연결로 초당 10,000건을 보내며, 각 실행은 20분간 유지했습니다.

Coroot로 측정한 비계측 기준값은 CPU 약 2코어, 메모리 약 10MB, P95 지연 약 5ms, P99 지연 약 10ms입니다. 같은 조건에서 HTTP와 Redis 호출에 OpenTelemetry 추적을 켜자 CPU는 약 2.7코어로 35% 늘고, 메모리는 15~18MB가 됐습니다. P99 지연은 약 15ms로 증가했지만 처리량은 초당 약 10,000건을 유지했으며 오류나 타임아웃은 관찰되지 않았습니다. 텔레메트리 내보내기로 발생한 아웃바운드 트래픽은 초당 약 4MB, 약 32Mbps입니다.

저자는 Coroot의 eBPF CPU 프로파일러로 추가 비용의 위치도 살폈습니다. 전체 CPU 시간의 약 10%는 스팬 배치 처리와 내보내기를 담당하는 go.opentelemetry.io/otel/sdk/trace.NewBatchSpanProcessor에 쓰였습니다. Redis 작업에는 추적에 따른 약 7%의 CPU 오버헤드가 추가됐으며, 나머지 증가는 계측한 HTTP 핸들러와 미들웨어에서 발생했다고 설명합니다.

글은 별도 선택지로 eBPF 기반 메트릭 수집을 소개합니다. Coroot는 이 벤치마크처럼 부하가 높은 경우 eBPF 추적을 끄고 메트릭만 사용하는 방식을 권고합니다. 각 노드에서 두 실험 내내 실행한 Coroot 에이전트의 CPU 사용량은 0.3코어 미만이었다고 보고합니다. 저자는 상세 트레이스와 낮은 자원 사용량 중 필요한 관찰 수준에 따라 계측 방식을 선택해야 한다고 설명합니다.

8. 동사와 객체로 짓는 비즈니스 스팬 이름

원문: How to Name Your Spans · Juraci Paixão Kröhling · 2025-08-07 업데이트

Juraci Paixão Kröhling은 비즈니스 로직을 계측하는 사용자 정의 스팬에 {verb} {object} 형식을 권합니다. 작업을 수행하는 서비스는 이미 트레이스 맥락에 있으므로, 이름에는 무엇을 하는지와 무엇을 대상으로 하는지만 담는 방식입니다. process payment, send invoice, render ad처럼 일관된 이름을 사용하면 같은 작업을 묶어 지연 시간을 분석하기 쉬워집니다.

사용자 ID, 청구서 번호, 캠페인 이름, 우편번호는 스팬 이름에서 빼고 속성에 기록합니다. 저자는 고유 식별자가 이름에 들어가면 작업마다 별도 이름이 생겨 유사 작업의 집계가 어려워지고 비용이 크게 늘 수 있다고 설명합니다. 결과와 작업도 구분합니다. 실패 결과를 나타내는 validation_failed 대신 작업을 나타내는 validate user_input을 쓰고, 결과는 스팬 상태에 기록하는 예를 제시합니다.

이 명명 방식은 OpenTelemetry Semantic Conventions의 공통 원칙과도 연결됩니다. 원문은 HTTP 서버 스팬의 {method} {route}를 예로 들며, 실제 경로 대신 GET /api/users/:ID 같은 경로 템플릿을 사용해 이름의 카디널리티를 낮춘다고 설명합니다. 데이터베이스에서는 INSERT my_database.users처럼 작업과 대상을 표현하고 삽입 값은 제외합니다. RPC의 com.example.UserService/GetUser는 표기 순서가 달라도 서비스와 메서드로 수행 작업을 설명한다는 예입니다.

저자의 주장은 스팬 이름에 모든 맥락을 넣기보다 작업을 집계할 수 있는 어휘를 유지하자는 것입니다. 상세 디버깅에 필요한 고카디널리티 정보는 속성에 남깁니다. 그러면 결제 처리 시간처럼 비즈니스 작업을 기준으로 한 질문을 해당 스팬의 필터링과 분석으로 연결할 수 있습니다.

9. Go 실행 트레이스 분석 도구 Gotraceui

원문: Gotraceui

Gotraceui 공식 사이트의 짧은 기능 소개와 설치 안내를 기준으로 정리했습니다. Gotraceui는 Go 실행 트레이스를 다루기 위해 만든 프로그램입니다. 수백만 개 이벤트와 goroutine을 포함할 수 있는 트레이스에서 모든 데이터를 실시간으로 표시하는 것을 설계 목표로 제시합니다. 이는 소개문에 적힌 목표이며, 별도의 성능 측정 결과는 제공되지 않았습니다.

Go 전용 도구로서 goroutine, Go 런타임, 가비지 컬렉션의 관계를 이해하고 검색·탐색·필터링·분석 기능을 제공합니다. 함께 제공하는 매뉴얼은 기능 사용법뿐 아니라 Go 런타임의 동작과 그 동작이 실행 트레이스에 나타나는 방식도 설명합니다. 라이선스는 MIT이며, 공식 지원 운영체제는 Linux, macOS, Windows입니다.

설치 안내에는 Nixpkgs 패키지와 소스 빌드 경로가 있습니다. 배포판에 패키지가 없으면 Gio의 빌드 의존성을 준비한 뒤 go install honnef.co/go/gotraceui/cmd/gotraceui@latest로 설치합니다. macOS의 외부 의존성은 XCode이며 Windows에는 외부 의존성이 없다고 명시합니다. 소개된 Flatpak은 프로젝트가 관리하지 않는 비공식 제3자 패키지입니다.