promkr 뉴스레터 2025년 8월호

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

1. Prometheus 네이티브 계측을 권하는 이유

원문: Why I recommend native Prometheus instrumentation over OpenTelemetry · Julius Volz · 2025-07-17

Prometheus 공동 창시자 Julius Volz는 Prometheus에서 사용할 메트릭이라면 네이티브 클라이언트 라이브러리와 풀 방식 수집을 권합니다. OpenTelemetry는 로그·메트릭·트레이스의 생성과 전송을 다루고, Prometheus는 메트릭 수집·저장·질의까지 맡는 모니터링 시스템이라는 차이에서 출발합니다. 저자는 자신의 편향을 밝히며, OpenTelemetry를 써야 하는 이유가 있을 수 있다는 전제를 둡니다.

첫 번째 근거는 타깃 상태 감시입니다. Prometheus는 서비스 디스커버리로 존재해야 할 타깃을 파악하고, 스크레이프 성공 여부를 up 값 0 또는 1로 기록합니다. OTLP 푸시에는 이 연동이 없어 데이터가 오지 않을 때 정상 종료와 장애를 구분하지 못합니다. 같은 수준으로 감시하려면 타깃의 기대 상태를 별도 메트릭으로 수집하고, 들어오는 데이터와 직접 연결해야 합니다.

이름과 속성 처리에도 차이가 있습니다. 기본 변환은 k8s.pod.cpu.time을 k8s_pod_cpu_time_seconds_total로 바꿉니다. Prometheus 3.0부터 UTF-8 이름을 보존할 수 있지만 확장 문자가 든 이름은 PromQL에서 따옴표로 감싸야 합니다. OTLP 수신 시 service.name과 service.instance.id는 기본적으로 job과 instance가 되며, 나머지 리소스 속성은 target_info에 붙습니다. 이를 질의에 포함하려면 조인하거나 속성을 각 시계열의 레이블로 승격하도록 설정해야 합니다. 수신에는 --web.enable-otlp-receiver 활성화와 비인가 전송 차단도 필요하며, 순서가 뒤바뀐 데이터에는 out_of_order_time_window: 30m 같은 설정을 제시합니다.

Volz의 Go 카운터 증가 벤치마크에서는 20코어 Intel i7-12700KF와 Arch Linux 조건에서 Prometheus SDK가 약 4.4~26배 빨랐습니다. 레이블이 같은 하위 메트릭 참조를 캐시하면 차이는 최대 53배였습니다. 이는 저자의 특정 연산 측정이며, 모든 언어의 상황을 확정하지는 않습니다. 저자는 Prometheus도 공개 표준과 개방형 거버넌스를 갖췄고, 필요하면 네이티브 메트릭을 나중에 OTLP로 연결할 수 있다고 덧붙입니다.

2. 대규모 옵저버빌리티 파이프라인의 설계 패턴

원문: May thy bits chip and shatter: Patterns for Building High-Performance Observability Pipelines at Scale · Sümer Cip · 2024-12-30

Sümer Cip은 텔레메트리의 특성에서 출발해 수집·인제스트·저장 단계의 설계 패턴을 설명합니다. 데이터는 대량으로 몰려들고, 차원이 많으며, request-id 같은 고카디널리티 필드를 포함합니다. 장애 조사 때 어떤 조건으로 검색할지 미리 알기 어려워 사전 집계를 최소화해야 하고, 수집한 데이터도 빠르게 질의할 수 있어야 한다는 주장입니다.

저자는 시계열 데이터베이스가 메트릭 압축과 다운샘플링, 기존 시계열에 값을 추가하는 작업에 강점이 있다고 설명합니다. 그러나 태그 조합마다 별도 시계열을 만들면 고유한 요청 식별자가 시계열 수를 폭증시킵니다. 따라서 다양한 신호의 자유로운 분석에는 시계열 저장 방식만으로 해결하기 어려운 요구가 있다고 봅니다. 보존 기간 역시 조직의 용도에 따라 정해야 하며, 하나의 설계가 모든 문제를 해결하지는 않는다고 명시합니다.

인제스트에서는 Kafka 같은 메시지 큐가 쓰기 분산, 복제, 재처리, 역압을 맡습니다. 객체 스토리지의 요청 비용을 줄이려고 데이터를 모아 쓰더라도 저장이 끝나기 전에는 큐에서 재생할 수 있도록 유지해야 합니다. 장애가 나면 큐를 WAL처럼 사용해 복구하는 방식입니다. 저자는 메시지 큐의 장점과 함께 운영 비용과 복잡성도 크다고 지적합니다. 저장 단계에서는 저렴한 객체 스토리지의 높은 지연과 요청별 과금에 맞춰 병렬 읽기, 캐시, 메타데이터와 인덱스를 설계해야 합니다.

컴퓨트와 스토리지를 분리하면 계산 자원과 저장 용량을 각각 확장할 수 있습니다. 컬럼 지향 저장은 많은 행에서 일부 열만 읽는 분석 질의에 맞고, 비슷한 값의 압축과 데이터 지역성, SIMD 기반 실행에도 유리합니다. Apache Parquet, Apache Arrow, Apache Iceberg가 관련 포맷과 도구로 등장합니다. 글에서 다룬 패턴은 다음과 같으며, 질의 실행 단계의 상세 설명은 후속 글로 남겨 두었습니다.

• OpenTelemetry 기반 텔레메트리 수집
• 메시지 큐를 이용한 내결함성 확보와 쓰기 부하 분산
• 객체 스토리지를 활용한 대량 데이터 저장 비용 절감
• 컴퓨트와 스토리지의 독립 확장
• 컬럼 지향 저장을 이용한 분석 질의 최적화

3. EBS 성능 저하를 장애로 보는 운영 경험

원문: The Real Failure Rate of EBS · Nick Van Wiggeren · 2025-03-18

PlanetScale의 Nick Van Wiggeren은 EBS 장애를 데이터 손실만으로 판단해서는 안 된다고 주장합니다. PlanetScale은 전 세계에서 수백만 개의 EBS 볼륨을 배포했고, 데이터베이스 생성·백업·테스트 과정에서 매일 수만 개를 만들고 제거했다고 밝힙니다. 이 경험에서 완전한 고장이나 데이터 손실은 매우 드물지만, 성능 저하도 사용자에게는 서비스 장애가 된다는 점을 강조합니다.

글에 나온 볼륨은 최소 10시간 동안 유휴 비율 67%, 작업당 한 자릿수 밀리초의 쓰기 지연을 보였습니다. 이후 지연이 작업당 200~500ms로 뛰고 유휴 시간이 0이 되면서 읽기와 쓰기가 사실상 막혔습니다. 저자는 AWS 문서가 EBS 최적화 인스턴스에 연결한 gp2·gp3 볼륨에 관해 연간 시간의 99% 동안 프로비저닝한 IOPS의 최소 90%를 제공하도록 설계됐다고 설명한다고 인용합니다. 나머지 1%는 하루 14분 또는 연간 86시간의 잠재적 영향에 해당한다는 해석입니다.

PlanetScale이 관찰한 성능 저하는 한 번에 1~10분가량 이어졌습니다. 글은 별도로 성능이 프로비저닝 값의 1~89% 사이로 무작위 저하되고, 애플리케이션이 처리량 50% 손실까지 견디며, 사건마다 10분간 지속된다는 가정을 둡니다. 이 모델에서 샤드 256개에 주 노드 하나와 복제본 둘씩, 총 768개 볼륨을 쓰면 어느 시점에든 최소 한 노드가 서비스에 영향을 주는 사건을 겪을 확률을 99.65%로 계산합니다. 이는 관측한 전체 장애율이 아니라 가정에 따른 계산입니다. 같은 가용 영역 안에서 서로 연관된 장애도 관찰했다고 전합니다.

PlanetScale은 읽기·쓰기 지연과 유휴 비율을 감시하고 파일 쓰기 검사도 수행합니다. 성능 저하를 감지하면 수초 안에 중단 없이 다른 노드로 주 노드 역할을 옮기고 대체 볼륨을 자동 생성합니다. 장애 전에 감지할 수 없어 영향을 완전히 없애지는 못하지만, 대부분은 사람의 복구 작업 없이 처리한다고 설명합니다. 로컬 스토리지를 사용하는 shared-nothing 방식의 PlanetScale Metal도 이러한 문제에 대응하려고 만들었다고 밝힙니다.

4. Statsviz의 Go 런타임 메트릭 실시간 시각화

원문: Statsviz · GitHub

Statsviz는 Go 프로그램의 runtime/metrics를 브라우저에서 실시간 그래프로 보여 주는 라이브러리입니다. README는 힙, 객체 수, 고루틴, GC 일시 정지, 스케줄러 상태 등을 애플리케이션에 붙여 관찰하는 방법을 안내합니다. 기본 사용법은 애플리케이션의 http.ServeMux에 statsviz.Register(mux)로 HTTP 핸들러를 등록하고 서버를 실행하는 방식입니다. 예제의 접속 주소는 http://localhost:8080/debug/statsviz입니다.

화면과 데이터 전송은 별도 핸들러가 맡습니다. Index()는 대시보드 UI를 제공하고, Ws()는 WebSocket 연결을 받습니다. 브라우저에서 UI를 열면 WebSocket에 연결하며, 프로그램의 런타임 메트릭이 1초마다 전달됩니다. HTTP 프레임워크에 연결하거나 경로를 바꾸고, HTTPS 또는 미들웨어를 적용하려면 statsviz.NewServer()로 서버를 만든 뒤 각 핸들러를 가져와 배치합니다. 저장소에는 echo, fasthttp, fiber, gin 등의 연동 예제가 있습니다.

UI에서는 카테고리별 그래프 선택, 표시 시간 범위 조정, GC 이벤트 수직선 표시, 갱신 일시 정지와 재개를 지원합니다. 그래프에는 메모리 할당·해제율, CPU 사용, GC 주기와 스캔, 고루틴, 뮤텍스 대기, 실행 가능 상태의 대기 시간 등이 포함됩니다. 실제 표시 항목은 Go 버전과 선택한 카테고리에 따라 달라집니다. v0.6부터는 사용자 그래프를 추가해 애플리케이션 메트릭을 런타임 메트릭 옆에 표시할 수 있으며, 라이선스는 MIT입니다.

5. Prometheus 알림 피로를 줄이는 맥락 보강과 라우팅

원문: 3 Steps To Minimize Alert Fatigue When Using Prometheus · Robusta · 2024-11-21

Robusta는 알림이 너무 많으면 담당자가 알림을 무시하게 되고 중요한 장애까지 놓칠 수 있다고 설명합니다. 글은 개별 알림의 판단에 필요한 정보를 보강하고, 비슷한 알림을 묶으며, 관련 있는 담당자에게 전달하는 방법을 제안합니다. 알림의 내용과 개수, 수신 대상을 각각 조정하는 접근입니다.

맥락 보강은 알림을 받은 뒤 별도로 데이터를 모으는 시간을 줄이려는 작업입니다. 글은 Alertmanager의 알림 템플릿에 추가 필드를 넣는 방법을 소개합니다. Robusta OSS는 레이블 외에도 애플리케이션 로그, Kubernetes 이벤트, 자원 그래프를 알림에 포함하도록 구성돼 있다고 설명합니다. 예시로 든 OOMKilled 알림에는 판단에 필요한 부가 정보가 붙으며, Alertmanager를 Robusta에 연결하면 별도의 보강 설정 없이 이런 알림을 받을 수 있다는 설명입니다.

그룹화는 개별 알림의 내용을 유지하면서 전달되는 메시지 수를 줄이는 데 초점을 맞춥니다. Robusta는 클러스터, 네임스페이스, 알림 이름 등을 기준으로 묶을 수 있습니다. 글에는 알림 1,985개를 메시지 하나로 모은 예시가 나오며, Robusta OSS의 그룹화는 Helm 값으로 설정한다고 안내합니다. 이 수치는 제품 사용 예시이며, 일반적인 알림 감소율을 측정한 결과는 아닙니다.

동적 라우팅은 담당 업무와 근무 시간에 맞춰 수신자를 정합니다. 근무 중이 아닌 지원팀에는 알림을 보내지 않고, 결제 처리 서비스를 맡은 팀에 다른 팀의 로그인 서비스 알림을 전달하지 않는 사례를 제시합니다. Robusta는 이런 규칙으로 각 팀이 받는 알림의 양을 줄이고 업무 관련성을 높일 수 있다고 주장합니다. 소개된 Robusta OSS는 MIT 라이선스로 제공됩니다.

6. LogSentinelAI의 선언적 로그 분석

원문: Show GN: LogSentinelAI — 선언만 하면 LLM이 로그를 분석 (PoC) · call518 · 2025-08-01

개발자 call518이 GeekNews에 올린 프로젝트 소개 글입니다. LogSentinelAI는 Apache, Linux 등의 시스템 로그에서 보안 이벤트와 이상 징후를 LLM으로 분석하는 오픈소스 PoC입니다. 분석 결과를 Elasticsearch와 Kibana에 연결해 시각화할 수 있고, GeoIP, 실시간 모니터링, SSH 원격 로그 분석도 지원한다고 소개합니다.

개발자가 원하는 결과의 형태를 선언하면 LLM이 그 형태에 맞춰 로그를 분석하는 Declarative Extraction이 중심 기능입니다. 예제는 Pydantic의 BaseModel을 상속한 클래스에 ip, url, is_attack 필드를 정의합니다. LLM은 각 로그를 분석해 이 필드를 갖춘 JSON을 반환합니다. 개발자는 복잡한 파싱과 후처리 대신 추출할 항목을 정의하는 방식이라고 설명합니다.

결과가 정해진 JSON 형태로 나오므로 통계와 대시보드 작업에 바로 사용할 수 있다는 소개입니다. 글은 PoC의 사용 방식과 지원 기능을 보여 주며, 분석 정확도나 처리 성능의 측정 결과는 제시하지 않습니다.

7. 옵저버빌리티 AI·ML 적용 기술 토크

원문: Applying AI/ML in Observability - Tech Talk #7 · YouTube

제공된 YouTube 페이지에서 확인할 수 있는 영상 제목을 기준으로 정리했습니다. 제목은 옵저버빌리티에 AI·ML을 적용하는 주제를 다루는 일곱 번째 기술 토크임을 나타냅니다.

자료에는 발표 설명이나 자막, 발언 내용이 없습니다. 따라서 구체적인 도구와 모델, 실행 조건, 알림 규칙은 이 자료에서 확인할 수 없습니다.

8. Coroot 노드 에이전트 기반 Grafana 대시보드

원문: coroot-grafana-dashboards · GitHub

저장소의 짧은 README를 기준으로 정리했습니다. 이 프로젝트는 Coroot 노드 에이전트와 Prometheus 호환 데이터 소스를 사용하는 Grafana 대시보드 모음입니다. Coroot UI나 ClickHouse 없이 노드 에이전트와 메트릭만으로 구성하는 배포 방식을 제시합니다.

시작 절차는 VMRule.yaml을 바탕으로 VMRule을 만들거나 이를 Prometheus recording rules로 사용하는 것입니다. 이어 대시보드를 Grafana에 가져오고 Prometheus 또는 VictoriaMetrics를 데이터 소스로 지정합니다. recording rules 지원이 필요하며, README는 VictoriaMetrics를 권장합니다. 컨테이너 메트릭을 확장하려면 kube-state-metrics와 cAdvisor를 선택적으로 사용할 수 있습니다.

기능에는 전체 개요에서 네임스페이스·서비스 수준으로 내려가는 탐색, FQDN과 트래픽 방향을 포함한 TCP 연결 정보, HTTP 오류·지연·트래픽 표시가 있습니다. CPU throttling 메트릭과 트래픽 유입·유출 방향별 오류 및 지연 구분도 제공하며, Postgres와 Kafka 메트릭은 베타로 표시돼 있습니다. 로드맵에는 인스턴스·노드 수준 대시보드, 오류 타임라인 개선, PSI 메트릭 통합이 미완료 항목으로 남아 있습니다.