promkr 뉴스레터 2026년 5월호

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

1. 알림 규칙과 Alertmanager의 처리 흐름

원문: Prometheus Alerting 101: Rules, Recording Rules, and Alertmanager · Phuong Le · 2025-03-18

Phuong Le는 규칙 평가부터 Alertmanager의 알림 전달까지 이어지는 과정을 설명합니다. Alerting rule은 주기적으로 식을 평가하고, 결과에 포함된 시계열마다 별도의 알림을 만듭니다. 글의 CPU 예제에서는 사용률이 80%를 넘는 상태가 for: 5m 동안 유지되어야 알림이 발화합니다. 4분 1초에 임계값 아래로 내려가면 대기 중인 알림은 비활성화되며 통지는 발생하지 않습니다.

Recording rule은 자주 쓰는 계산 결과를 새 시계열로 저장하는 규칙입니다. 글에서는 vmalert가 계산한 벡터를 remote write로 저장하고 대시보드와 알림에서 재사용하는 방식을 소개합니다. 그룹은 규칙의 평가 주기를 정하며 기본 실행 순서는 순차적입니다. vmalert의 concurrency는 병렬 실행 수를, eval_offset은 평가 시점의 이동을 설정합니다.

Alertmanager는 레이블과 라우팅 트리로 수신자를 선택합니다. continue: true를 지정하면 앞선 경로에 일치한 알림도 다음 경로에서 계속 검사합니다. 그룹화 예제는 alertname이 같은 알림을 묶고, group_wait: 30s 동안 첫 통지를 기다립니다. 이후 group_interval: 5m마다 새 알림이나 해결된 알림을 확인하며, 변화가 없어도 마지막 통지로부터 repeat_interval: 4h가 지나면 다시 보냅니다.

Inhibition은 더 중요한 알림이 있을 때 관련 알림의 통지를 억제하는 기능입니다. 억제된 알림은 UI에 남습니다. Silencing은 매처와 시작·종료 시각을 지정해 규칙을 바꾸지 않고 통지를 잠시 끕니다. 해결 통지는 수신자의 send_resolved 설정에 따르며, 해결 즉시가 아니라 다음 group_interval 주기에 전달됩니다.

2. Strobelight의 CUDA 커널 실행 추적

원문: Strobelight · GitHub

Strobelight README는 Meta가 대규모 인프라의 성능 병목과 자원 사용을 분석하기 위해 만든 프로파일링 프레임워크를 소개합니다. 여러 프로파일러를 조합하고 각 프로파일러가 특정 유형의 데이터를 수집하는 방식입니다. CPU, GPU, 메모리 등을 프로파일 유형으로 들며, 구체적인 빌드와 사용 설명은 gpuevent에 집중되어 있습니다.

gpuevent는 cudaLaunchKernel 이벤트에 연결되어 실행되는 GPU 커널의 정보를 수집합니다. 수집 대상은 디맹글링한 커널 이름, 인자, 호출 스택, 실행 차원 등입니다. README의 출력 예시에는 커널 주소와 스트림, GRID와 BLOCK 크기, 함수 인자, cudaLaunchKernel에서 상위 호출자로 이어지는 스택이 표시됩니다. 대상 CUDA 프로세스의 PID를 지정해 해당 프로세스의 커널 실행을 추적하는 도구입니다.

실행 전제는 Linux 시스템, NVIDIA CUDA가 설치된 GPU 호스트, 테스트할 CUDA 바이너리, cmake입니다. 저장소를 복제하고 ./scripts/build.sh -u로 빌드한 뒤 생성된 gpuevent_snoop을 실행합니다. -p는 대상 PID, -a는 커널 실행 인자, -s는 호출 스택 수집 옵션이며, -d로 추적 시간을 초 단위로 제한할 수 있습니다. 프로젝트는 Meta 엔지니어링 팀이 관리하며 Apache License 2.0으로 공개되어 있습니다.

3. Versus의 인시던트 탐지와 알림 전달

원문: github VersusControl/versus-incident · GitHub

Versus Incident README는 자체 호스팅하는 AI SRE Agent와 기존 모니터링 도구의 웹훅을 인시던트 입력 경로로 소개합니다. 프로젝트는 에이전트가 정상 패턴을 학습하고 새로운 오류나 이상을 발견하면 인시던트를 생성한다고 설명합니다. Alertmanager, Grafana, Sentry 등이 보낸 알림도 받을 수 있습니다. 어느 경로로 들어오든 같은 메시지 템플릿, 알림 채널, 온콜 처리 로직을 사용합니다.

에이전트의 training 모드는 패턴을 학습하고 저장하지만 알림을 보내지 않습니다. shadow는 알림을 보냈을 상황을 로그로 남기며, detect는 처음 보는 패턴으로 인시던트를 생성하는 모드입니다. README는 관리자 대시보드에서 학습 결과를 확인하며 이 순서로 전환하도록 안내합니다. 로그는 민감 정보 제거와 정규식 사전 필터를 거쳐 패턴 분류기에 전달되며, 어떤 규칙에도 맞지 않는 항목은 분류 전에 버려집니다.

설정 예제의 로그 소스는 파일과 Elasticsearch이며 별도 agent_sources.yaml에서 관리합니다. 패턴 목록과 인시던트 이력의 저장 백엔드는 현재 file만 구현되어 있고, redis와 database는 설정 자리만 마련된 상태입니다. 이 저장소와 별개로 Redis는 각 로그 소스를 어디까지 읽었는지 기억하는 데 필요합니다. 관리자 API에는 gateway_secret이 필요하며, 값이 없으면 관리자 엔드포인트를 등록하지 않고 에이전트도 시작하지 않습니다.

웹훅은 기본 포트 3000의 POST /api/incidents에서 받습니다. 메시지는 Go 템플릿으로 구성하고 Slack, Microsoft Teams, Telegram, Viber, Email, Lark로 전달할 수 있습니다. 온콜 설정 예제는 AWS Incident Manager와 PagerDuty를 다루며, 확인 응답을 기다리는 기본 시간은 3분입니다. wait_minutes를 0으로 설정하면 즉시 온콜을 호출하고, 요청별 쿼리 매개변수로 온콜 활성화 여부와 대기 시간을 바꿀 수 있습니다.

4. HTTP Check Receiver를 이용한 합성 모니터링

원문: How to Configure the HTTP Check Receiver in the OpenTelemetry Collector · Nawaz Dhandala · 2026-02-06

Nawaz Dhandala는 OpenTelemetry Collector가 직접 HTTP 요청을 보내 엔드포인트 상태를 점검하도록 구성하는 방법을 설명합니다. HTTP Check receiver는 들어오는 텔레메트리를 기다리는 대신 지정된 URL을 주기적으로 호출하는 구성 요소입니다. 응답에서 만든 메트릭은 Collector의 프로세서를 거쳐 관측 백엔드로 전송됩니다. 전제 조건은 해당 리시버가 포함된 otelcol-contrib 또는 otelcol-k8s 배포판과 대상 엔드포인트까지의 네트워크 연결입니다.

기본 설정은 http_check의 targets에 URL과 HTTP 메서드를 나열하고 collection_interval을 지정합니다. 글에 나온 기본 점검 간격은 60초입니다. 확장 예제에는 인증 헤더, POST 본문, 대상별 타임아웃, 사용자 지정 CA와 클라이언트 인증서가 포함됩니다. 응답 본문의 JSON 경로나 문자열을 검증하고, 여러 지역의 Collector에 monitoring.location을 붙여 지역별 결과를 구분하는 구성도 제시합니다.

글은 httpcheck.duration을 밀리초 단위 응답 시간, httpcheck.status를 상태 코드 클래스 일치 여부, httpcheck.error를 점검 오류 메트릭으로 설명합니다. 선택적으로 응답 크기를 바이트 단위로, HTTPS 인증서 만료까지 남은 시간을 초 단위로 수집할 수 있습니다. 알림 예제의 느린 응답 조건은 1,000밀리초 초과가 5분간 지속되는 경우이며, 인증서 만료 조건은 남은 시간이 2,592,000초, 즉 30일 미만인 경우입니다.

사용자 여정 예제는 홈페이지, 로그인, 대시보드 등에서 쓰는 엔드포인트를 각각 점검합니다. 각 대상은 독립적으로 실행되므로 세션 공유나 엄격한 순차 실행이 필요하면 전용 합성 모니터링 도구를 쓰도록 명시합니다. 요청마다 네트워크, TLS 처리, 응답 버퍼 비용도 발생합니다. 글은 엔드포인트가 100개 이상인 경우 여러 Collector로 대상을 나누거나 중요도가 낮은 점검의 간격을 늘리는 방안을 제시합니다.

5. Rezolus의 고해상도 시스템 기록과 분석

원문: Rezolus · GitHub

Rezolus README는 워크로드가 느려진 순간의 CPU, GPU, 스케줄러, I/O, 네트워크 동작을 조사하는 시스템 텔레메트리 도구를 소개합니다. 개별 요청 트레이스나 호출 스택 프로파일 대신 시스템 수준의 증거를 제공하는 도구입니다. 스케줄러·시스템 호출·I/O 지연 히스토그램은 읽기 사이에 발생한 이벤트의 분포를 보존합니다. 따라서 스냅샷을 1초마다 수집해도 짧은 지연이 분포에 남을 수 있습니다.

이벤트 지속 시간의 해상도와 스냅샷 수집 주기는 서로 다른 개념입니다. 더 자주 읽으면 변화가 발생한 시점을 좁힐 수 있지만, 각 이벤트의 지속 시간 측정 정밀도가 높아지는 것은 아닙니다. 에이전트 캐시와 개별 샘플러 주기도 데이터의 최신성을 제한합니다. eBPF 샘플러는 커널에서 집계하고 메모리 매핑으로 읽으며, 오버헤드는 활성 샘플러, 이벤트 발생률, 하드웨어, 수집 주기에 따라 달라집니다.

단일 바이너리가 Agent, Exporter, Recorder, Viewer, Hindsight, MCP 역할을 제공합니다. Hindsight는 로컬 순환 버퍼에 기록해 사건 발생 후 직전 이력을 저장할 수 있게 하지만, 사전에 실행 중이어야 하며 디스크 공간이 필요합니다. Recorder와 Hindsight는 .dendro 아카이브를 작성하고, 하나의 아카이브에 여러 엔드포인트의 기록을 담을 수 있습니다. Viewer는 실시간 에이전트와 저장된 기록을 분석하며, 브라우저 전용 뷰어는 업로드한 기록을 브라우저 안에서 처리합니다.

Linux 수집에는 사용 가능한 BTF를 갖춘 커널 5.8 이상, x86_64 또는 ARM64, eBPF 계측을 위한 root나 sudo 권한이 필요합니다. macOS의 로컬 수집은 CPU와 Apple GPU 메트릭으로 제한되지만, 기존 기록 분석에는 Linux eBPF나 root가 필요하지 않습니다. MCP의 extract-features는 최소 10초의 데이터에서 통계, 이상, 변화 구간, 상관관계 등을 추출합니다. README는 누락된 데이터가 활동량 0을 뜻하지 않으며 상관관계도 인과관계의 증거가 아니라고 명시합니다.

6. run-o11y-run의 로컬 관측 스택 실행

원문: run-o11y-run · GitHub

run-o11y-run은 설정을 내장한 단일 바이너리로 docker compose를 감싸는 도구입니다. Grafana, Loki, Tempo, MinIO, OpenTelemetry Collector, Prometheus, Pyroscope를 로컬 컨테이너 스택으로 실행합니다. 바이너리 자체가 관측 서비스를 구현하는 방식은 아니며, docker compose를 포함한 최신 Docker Desktop이 필요합니다. 설치 방법으로 Homebrew와 릴리스 바이너리 다운로드를 안내합니다.

실행 후 애플리케이션의 텔레메트리 전송 주소를 로컬 수신 엔드포인트로 맞춥니다. README는 암호화하지 않는 연결을 사용하도록 안내하며, OTLP gRPC는 4317, OTLP HTTP는 4318, Jaeger는 14268, Zipkin은 9411 포트를 사용합니다. 로그는 로컬의 /var/log/*.log와 ./*.log를 따라 읽거나 8094 포트의 Syslog RFC 3164 리시버로 받습니다. 프로파일 데이터는 4040 포트로 보낼 수 있습니다.

start는 스택을 실행하며 --detach로 백그라운드 실행을 선택할 수 있습니다. 기본 이미지 레지스트리는 Docker Hub이고 --registry로 변경합니다. --external-network는 기존 Compose 구성과 연결할 때 쓰며, patch는 사용자의 docker-compose.yaml을 수정해 네트워크 연결을 구성하는 명령입니다. --yolo는 모든 이미지에 :latest 태그를 적용하지만, README는 변경된 이미지의 호환성 문제나 예기치 않은 동작 가능성을 명시합니다.

관리 명령은 실행 이후의 확인과 정리도 다룹니다. open은 지정한 서비스 화면을 기본 브라우저로 열고, ports는 스택이 쓰는 포트를 나열합니다. stop은 컨테이너를 정상 종료하며, clean은 컨테이너뿐 아니라 관련 파일과 네트워크도 제거합니다. 실행 중 CTRL+C를 눌러 정상 종료하는 방법도 안내되어 있습니다.

7. GoVisual의 요청별 디버깅과 MCP 연동

원문: GoVisual · Arif Dogan

GoVisual README는 Go의 HTTP 핸들러를 감싸 요청을 수집하고 로컬 대시보드에서 조사하는 런타임 디버거를 소개합니다. govisual.Wrap으로 핸들러를 감싸면 기본 경로 /__viz에서 요청을 확인할 수 있습니다. 2.0의 기본 모듈은 표준 라이브러리와 google/pprof를 사용하며, 데이터베이스 저장소와 OpenTelemetry 연동은 별도 모듈로 분리되어 있습니다. 기본 저장 방식은 메모리이며 보관 요청 수의 기본 한도는 100개입니다.

요청별 조사에는 SQL, 외부 HTTP 호출, slog 로그, 패닉 스택을 함께 연결할 수 있습니다. SQL 드라이버, http.RoundTripper, slog.Handler를 각각 감싸고 원래 요청의 컨텍스트를 전달하는 방식입니다. 로그는 요청당 최대 200줄을 붙이며 기존 로그 핸들러에도 원래 내용을 전달합니다. 패닉은 값과 전체 스택을 기록한 뒤 다시 발생시켜 복구 미들웨어와 net/http의 기존 동작을 유지합니다.

별도 MCP 모듈은 코딩 에이전트가 실행 중인 앱의 요청을 조회하고 재실행하도록 지원합니다. 제공 도구는 12개이며 최근 오류 조회, 요청 검색, 디버깅 문맥 조회, 재실행 전후 응답 비교, 테스트 저장 등이 포함됩니다. 응답 목록과 본문 발췌의 크기를 제한하고 크기 정보도 반환합니다. 재실행, 응답 비교, curl 명령 생성에는 WithBaseURL(...)이 필요하며 요청 대상은 이 주소로 고정됩니다.

대시보드는 상태와 지연 시간별 필터, 요청별 헤더·본문·트레이스·로그, 경로별 요청 수와 p50/p95, 오류율을 제공합니다. 새 요청은 SSE로 반영됩니다. 대시보드와 MCP 엔드포인트는 기본적으로 루프백 접근만 허용하고, 대시보드의 요청 재실행과 시스템 정보 공개는 명시적으로 켜야 합니다. Authorization, Cookie, Set-Cookie 등 민감 헤더는 수집 시 값이 가려지며, 환경 변수도 이름을 허용 목록에 넣은 것만 공개됩니다.