목차
promkr 뉴스레터 2025년 3월호
원문 정보
- 원문: Prometheus & Observability - 2025년 3월 소식
- 발행: 2025-03-03
이 호에 실린 소식 8개의 원문을 읽고 요약했습니다. 뉴스레터 설명이 아니라 링크가 가리키는 글의 내용을 기준으로 썼습니다. 한 해 전체의 흐름은 2025년 소식에 있습니다.
1. Shopify의 사내 옵저버빌리티 플랫폼 Observe
원문: Shopify’s Journey to Planet-Scale Observability · Dotan Horovits · 2025-02-27
Shopify는 수천 개 서비스와 초당 수십억 건의 이벤트를 처리하는 규모에 맞춰 사내 옵저버빌리티 플랫폼 Observe를 구축했습니다. 이 글은 개편을 이끈 엔지니어링 디렉터 Elijah McPherson과의 인터뷰를 바탕으로 작성됐습니다. McPherson은 기존 상용 솔루션으로 신뢰성·성능·비용 요구와 데이터 통제권을 모두 충족하기 어려웠다고 설명합니다. 데이터 유입이 늘면 기존 솔루션의 연간 비용이 수천만 달러에 이를 것으로 예상했으며, 자체 구축 후 저장 비용을 80% 넘게 줄이고 쿼리 성능과 신뢰성을 개선했다고 밝혔습니다.
Observe는 로그·메트릭·트레이스·프로파일링 데이터를 한 UI에 모읍니다. 메트릭에는 StatsD와 Prometheus, 로그에는 Loki, 분산 추적에는 Tempo, 시각화에는 Grafana를 사용합니다. 분석 저장에는 ClickHouse와 Apache Parquet가 쓰입니다. 장기 메트릭 저장은 Google Cloud Storage, Thanos, Parquet를 조합해 보존 기간 제한 없는 분산 쿼리를 지원합니다. Shopify는 Grafana 플러그인도 만들어 고객 전환율과 인프라 성능을 같은 패널에 표시했습니다. 자동 의존성 매핑은 장애 서비스를 빨리 찾도록 도와 평균 복구 시간인 MTTR을 줄였다고 설명합니다.
개방형 표준 채택도 개편의 주요 방향입니다. Shopify는 트레이싱 파이프라인에 OpenTelemetry를 도입하고, 처리량이 높은 서비스에서 15~20%의 성능 오버헤드를 일으키던 독점 에이전트를 제거했습니다. 자연어 쿼리 보조 기능은 일반적인 문제 해결 패턴에 맞춰 PromQL과 LogQL을 제안합니다. McPherson에 따르면 이 기능은 엔지니어의 문제 진단 시간을 30~40% 절약했습니다. 요청 지연과 결제 이탈률을 연결하는 대시보드는 고객 영향에 따라 수정 우선순위를 정하는 데 쓰입니다.
이전 과정에서는 기존 스택과 새 스택에 데이터를 함께 기록하고 결과가 일치하는지 확인한 뒤 전환했습니다. 카나리 배포로 성능 개선도 검증했습니다. McPherson은 비용·성능·통제권이 중대한 문제가 되는 Shopify 규모에서는 자체 구축이 타당하지만, 대부분의 팀에는 관리형 솔루션으로 충분하다고 설명합니다.
2. egressd의 Kubernetes 네트워크 트래픽 수집
원문: egressd · GitHub
egressd는 네트워크 연결 기록에 Kubernetes 정보를 붙여 트래픽을 모니터링하는 도구입니다. 제공된 README에는 지원 중단 안내가 명시돼 있습니다. 새 기능 추가와 적극적인 유지보수는 더 이상 이뤄지지 않으며, 프로젝트는 CAST.AI 고객에게 Kvisor Netflow로의 이전을 권고합니다.
수집기는 DaemonSet으로 각 노드에 배치됩니다. 노드에서 실행 중인 Pod의 conntrack 항목을 설정된 주기마다 가져오며, 기본 주기는 5초입니다. Cilium을 사용하면 Cilium이 호스트의 /sys/fs/bpf에 만든 eBPF 맵에서 연결 기록을 읽습니다. Linux Netfilter Conntrack 모듈을 사용하는 경우에는 Netlink로 기록을 가져옵니다. 수집한 기록은 출발지 IP, 목적지 IP, 프로토콜을 기준으로 묶습니다. 여기에 출발지와 목적지의 Pod·노드·노드 영역·IP 정보를 추가하고, exporter가 HTTP나 Prometheus로 내보냅니다.
egressd 컨테이너에는 특권 실행이 필요합니다. DNS 추적기가 eBPF를 사용하고, 연결 정보를 가져오는 과정에서도 호스트 자원에 접근하기 때문입니다. Netfilter conntrack accounting을 켜고 cgroupv2를 마운트할 때는 양방향 마운트 전파를 사용합니다. Cilium 수집기는 커널 데이터를 담은 eBPF 맵을 읽습니다. README는 Prometheus 메트릭과 Grafana를 미리 구성한 데모를 제공하며, 실행 후 메트릭이 보이기까지 몇 분이 걸린다고 안내합니다.
3. Beszel의 서버 모니터링 구성과 기능
원문: Beszel · GitHub
Beszel은 서버의 과거 데이터, 컨테이너 통계, 알림을 제공하는 가벼운 모니터링 플랫폼입니다. 프로젝트는 적은 수동 설정으로 사용할 수 있는 웹 인터페이스를 제공한다고 소개합니다. 구성은 hub와 agent로 나뉩니다. hub는 PocketBase 기반 웹 애플리케이션으로, 연결된 시스템을 보고 관리하는 대시보드를 제공합니다. agent는 모니터링할 시스템마다 실행되며 시스템 메트릭을 hub에 전달합니다.
수집 범위는 호스트 자원과 컨테이너 상태를 함께 다룹니다. Docker와 Podman 컨테이너의 CPU·메모리·네트워크 사용량을 추적하고, 실행 중인 컨테이너의 상태도 표시합니다. 호스트에서는 여러 파티션과 장치의 디스크 사용량 및 I/O, 부하 평균, 온도 등을 수집합니다. 메모리 통계에는 swap과 ZFS ARC가 포함됩니다. GPU 사용량과 소비 전력은 Nvidia·AMD·Intel을 지원하며, Linux 팬 속도는 /sys/class/hwmon에서 읽습니다.
알림은 대부분의 메트릭에서 설정할 수 있으며 여러 알림 서비스를 지원합니다. 사용자는 자신의 시스템을 관리하고, 관리자는 시스템을 여러 사용자에게 공유할 수 있습니다. OAuth/OIDC 인증과 비밀번호 인증 비활성화도 지원합니다. 자동 백업은 로컬 디스크나 S3 호환 저장소에 저장하고 복원하는 방식입니다. README에 소개된 추가 모니터링 기능은 다음과 같습니다.
- 네트워크 모니터링은 agent에서 응답 시간과 연결 중단을 확인한다.
- S.M.A.R.T.는 디스크 건강 상태와 드라이브 고장 알림을 제공한다.
- 디스크 건강 정보는 지원되는 경우 eMMC 수명·마모와 Linux mdraid 배열 상태도 포함한다.
- ZFS는 풀 용량·사용량·건강 상태·I/O 처리량·scrub 상태와 데이터셋별 사용량을 수집한다.
- 배터리 잔량은 호스트 시스템과 일부 주변기기에서 수집한다.
4. Sciuro의 알림과 Kubernetes Node Condition 연결
원문: github cloudflare/sciuro · GitHub
Sciuro는 Alertmanager나 Prometheus의 알림을 Kubernetes Node Condition으로 동기화하는 브릿지입니다. Node Condition을 관찰하는 draino나 Cluster API 같은 컨트롤러와 함께 사용하도록 설계됐습니다. 요구 사항은 Alertmanager API v2 또는 Prometheus API v1과 Kubernetes 1.12 이상입니다. 배포 시에는 노드 정보를 읽고 노드 상태를 수정할 수 있는 권한을 부여합니다.
Sciuro는 알림을 직접 가져오는 pull 방식으로 동작합니다. Alertmanager를 사용할 때 README는 전용 receiver를 두고, route로 대상 알림을 연결하도록 권장합니다. receiver는 알림을 어디로도 전송하지 않는 빈 설정이어도 됩니다. 전체 알림 범위는 receiver로 거르고, 특정 노드에 연결할 알림은 CEL 표현식으로 선택합니다. 표현식에서는 알림의 labels, 노드의 전체 이름인 FullName, 첫 점 앞부분인 ShortName을 사용할 수 있습니다.
Prometheus를 입력으로 사용하면 silence와 receiver 개념이 없으므로 더 복잡한 CEL 표현식을 권장합니다. 원문 예시는 노드 이름과 notify 레이블을 함께 검사합니다. 별도 예제에서는 가동 시간이 7일을 넘은 노드에 NodeUpTooLong 알림을 만들고, 해당 노드에 AlertManager_NodeUpTooLong Condition을 추가합니다. 알림이 발생 중이면 상태는 True, 사유는 AlertIsFiring으로 표시됩니다.
설정 예시는 알림 수집과 노드 동기화의 주기를 별도로 지정합니다. 해제된 알림은 상태가 False인 Condition으로 일정 시간 남긴 뒤 삭제하며, 이 보존 시간을 0으로 설정하면 삭제하지 않습니다.
SCIURO_ALERT_CACHE_TTL은 알림을 가져오는 간격이며 예시 값은60s다.SCIURO_NODE_RESYNC는 노드와 현재 알림을 완전히 동기화하는 주기이며 예시 값은2m다.SCIURO_RECONCILE_TIMEOUT은 노드 조정 작업의 최대 시간이며 예시 값은45s다.SCIURO_LINGER_DURATION은 해제된 알림의 Condition 보존 시간이며 예시 값은96h다.SCIURO_NODE_CONDITION_PREFIX의 예시 값은AlertManager_다.
5. Thanos v0.37.0의 복제 프로토콜과 호환성 변경
원문: v0.37.0 · saswatamcode · 11월 25일
Thanos v0.37.0은 Receiver 복제 프로토콜 추가, 여러 컴포넌트의 기능 개선, Prometheus v3 관련 수정을 포함한 릴리스입니다. Receiver는 새로 Cap’n Proto 기반 복제를 지원합니다. 릴리스 노트는 이 프로토콜의 CPU와 메모리 부담이 더 작아 Receiver 자원 사용량이 줄어든다고 설명합니다. 활성화하기 전에는 모든 Receiver를 해당 복제 방식을 지원하는 버전으로 갱신해야 합니다.
조회 기능에서는 series·label names·label values 메타데이터 API에 limit 매개변수가 추가됐고, Store에도 이를 처리하는 기능이 구현됐습니다. Query의 규칙 조회 HTTP API는 rule_name, rule_group, file 조건으로 필터링할 수 있습니다. Ruler는 규칙 평가를 병렬로 수행하는 기능을 추가했습니다. Store는 hedged requests를 지원하며, Query Frontend에는 상위 querier의 쿼리 통계 수집을 강제하는 --query-frontend.force-query-stats 플래그가 생겼습니다.
수정 사항에는 Query Frontend의 응답 본문 이중 gzip 압축, 동적으로 나눈 쿼리 구간의 캐시 키, Prometheus 통계 병합 문제가 포함됩니다. Sidecar는 Prometheus v3.0.0에서 외부 레이블을 가져오는 문제를 고쳤습니다. Query와 Receive의 코루틴 누수도 수정했고, Store는 Series 호출이 끝난 뒤 청크를 풀로 반환하도록 바뀌었습니다.
릴리스 노트는 3년간 사용 중단 상태였던 Store gRPC Info 함수의 제거를 호환성을 깨는 변경으로 표시합니다. 그 밖에 Receive는 복제 계수가 rf=2일 때의 quorum 계산을 변경했고, multi-tsdb에서는 dedup proxy를 비활성화했습니다. TLS 최소 버전을 지정하는 --grpc-server-tls-min-version 플래그가 추가됐으며, 별도로 지정하지 않으면 TLS 1.3을 사용합니다. Reloader의 TolerateEnvVarExpansionErrors 옵션은 미설정 환경 변수 때문에 재로딩이 실패하지 않도록 하며, 해당 변수는 원래 표기대로 남깁니다.
6. 메트릭 수집 에이전트와 전송 프로토콜 벤치마크
원문: OpenTelemetry, Prometheus, and More: Which Is Better for Metrics Collection and Propagation? · Zhu Jiekun · 2025-02-05
VictoriaMetrics의 Zhu Jiekun은 Prometheus 형식으로 노출된 메트릭을 수집하고 원격 저장소로 보낼 때 에이전트와 프로토콜별 자원 사용량을 비교했습니다. 대상은 Agent Mode의 Prometheus 2.53.3과 3.0.1, OpenTelemetry Collector v0.115.0, vmagent v1.108.0입니다. 각 에이전트는 2 vCPU·메모리 2GB의 e2-highcpu-2에서 실행됐으며, 3개 리전에 분산된 Node exporter 1.8.2 인스턴스 1,200개를 수집했습니다. 수신기는 압축 해제와 역직렬화, 통계 기록만 수행하고 데이터를 영구 저장하지 않는 No-op receiver입니다.
저자는 수일간의 기준 측정에서 Prometheus 2.x를 3.x로 올려도 CPU와 메모리 절감은 나타나지 않았다고 설명합니다. Prometheus의 메모리 사용량이 가장 높았고, OpenTelemetry Collector는 CPU 부담이 크고 메모리 사용량도 비교적 높았습니다. 전송량에서는 Prometheus 3.x의 Remote Write 2.0이 Remote Write 1.0보다 대역폭을 40% 절약했습니다. vmagent는 Snappy 대신 zstd를 사용하는 VictoriaMetrics remote write 프로토콜로 Remote Write 2.0보다 대역폭을 46% 적게 사용했다고 보고합니다. 저자는 결론에서 vmagent가 Collector와 Prometheus 3.x보다 CPU를 각각 3.2배·1.6배, 메모리를 각각 2.7배·3.0배 적게 사용했다고 설명합니다. OTLP의 효율도 높지 않다고 평가합니다.
Collector 프로파일에서는 scrape 작업에 많은 시간이 쓰여 Prometheus receiver가 부담의 원인으로 추정됐습니다. 후속 실험에서는 별도의 helper Collector가 scrape를 맡고, 측정 대상 Collector에는 배치 없이 초당 40개 요청으로 OTLP 데이터를 보냈습니다. 저자는 이 조건에서 측정 대상의 CPU 사용량이 1.56배, 메모리 사용량이 3.23배 줄었다고 보고합니다. 또 Prometheus 3.x 소스 코드를 수정해 Remote Write 2.0에 zstd를 적용하자, 같은 부하에서 대역폭 사용량은 30% 감소하고 CPU 사용량은 4% 증가했습니다. 저자는 결론에서 zstd 압축 옵션을 켜면 Remote Write 2.0의 절감 폭이 60%까지 늘 수 있다고 설명합니다. Prometheus 2.x도 성능 패치를 받으므로 두 버전의 자원 사용 차이는 줄어들 수 있다고 덧붙입니다.
이 실험은 원격 저장소가 사용 불가능한 상황을 재현하지 않았습니다. 해당 조건에서 Collector와 vmagent는 추가 디스크를 거의 쓰지 않았지만, Prometheus는 Agent Mode에서도 WAL을 기록하고 2시간마다 정리했습니다. 저자는 많은 시계열을 생성하는 exporter들이 OTLP를 지원하기 전에는 Prometheus 형식 수집에 OpenTelemetry를 끼워 넣는 데 추가 비용이 든다고 결론 내립니다.
7. Grafana Drilldown의 이름 변경과 탐색 기능 확장
원문: Grafana Drilldown apps: the improved queryless experience formerly known as the Explore apps · Andrew Stucky · 2025-02-21
Grafana Labs는 쿼리를 직접 쓰지 않고 클릭으로 데이터를 탐색하는 Explore apps의 이름을 Grafana Drilldown으로 바꿨습니다. 기존 쿼리 인터페이스인 Explore와 이름이 같아 사용자가 쿼리 작성이 필요한 도구로 혼동했기 때문입니다. 기존 Explore는 이름과 기능을 유지합니다. Explore가 수백 개 데이터 소스를 지원하는 것과 달리, Drilldown은 Grafana Mimir·Loki·Tempo·Pyroscope 전용으로 설계됐습니다. 글은 새 이름을 Grafana Cloud UI에 이르면 게시 당일부터 반영하고, 3월 Grafana 11.6 릴리스에도 포함할 예정이라고 안내합니다.
Metrics Drilldown에는 OTel experience mode의 필터링 지원이 추가됐습니다. 레이블로 승격되지 않은 OpenTelemetry 리소스 속성을 조회할 때 필요한 레이블 조인을 자동으로 처리합니다. native histogram 지원과 전용 홈페이지도 추가했습니다. 메트릭에서 관련 로그로 이동하는 기능은 실험 기능입니다. Grafana Cloud에서는 지원 요청으로 활성화하고, OSS Grafana에서는 exploreMetricsRelatedLogs를 활성화된 feature toggle 목록에 넣습니다.
Logs Drilldown은 서비스 이름뿐 아니라 임의의 인덱싱된 레이블로 로그를 나눠 볼 수 있게 됐습니다. 쿼리 스트리밍은 전체 쿼리 완료를 기다리지 않고 처리된 결과부터 표시합니다. 이 기능도 실험 단계이며, Cloud에서는 지원 요청이 필요하고 OSS에서는 exploreLogsShardSplitting을 설정합니다. 무한 스크롤은 다음 로그 묶음을 자동으로 가져옵니다. 정규식 필터링과 특정 로그 행·시간 범위·전체 결과를 가리키는 링크 공유, URL 단축 기능도 추가됐습니다.
Traces Drilldown은 게시 시점에 아직 GA가 아니었습니다. exemplar에서 해당 트레이스로 이동하는 기능을 추가했고, 트레이스 상세 화면을 크기 조절 가능한 drawer에 표시하도록 개선했습니다. 사용자는 나머지 화면의 맥락을 유지하면서 상세 영역을 펼치거나 접을 수 있습니다. Profiles Drilldown은 GA에 도달했습니다. Grafana Labs는 지연 감소, 비용 절감, 장애 해결 시간 단축과 같은 용도에 맞춰 기능을 다듬었다고 설명합니다.
8. Prometheus Engine의 GMP 클라이언트 구성 요소
원문: Prometheus Engine · GitHub
Prometheus Engine 저장소는 Google Cloud Managed Service for Prometheus인 GMP를 클라이언트 쪽에서 사용하기 위한 바이너리와 패키지를 담고 있습니다. GMP는 Google Cloud Monitoring인 GCM 위에서 제공되는 관리형 Prometheus입니다. README는 메트릭 수집 관리, 쿼리 접근, 규칙 평가, Grafana 인증 정보 갱신, 리소스 이전을 담당하는 도구를 소개합니다. 수집 데이터를 GMP/GCM에 기록하는 완전한 Prometheus 호환 바이너리는 별도의 GoogleCloudPlatform/prometheus 저장소에서 제공됩니다.
각 도구는 명령별로 빌드할 수 있으며, make bin은 관련 Go 바이너리를 모두 빌드합니다. NO_DOCKER=1을 지정하면 호스트에서 직접 빌드합니다. make presubmit은 리소스를 다시 생성하고 모든 이미지를 빌드한 뒤 테스트를 실행합니다. CHECK=1을 추가하면 검사 후 저장소에 변경이 남아 있을 때 명령이 실패합니다. Kubernetes 종단 간 테스트는 기본적으로 격리된 Docker 컨테이너에서 kind를 내려받고 단일 노드 클러스터를 다시 만들어 실행합니다. GCM 상태까지 확인하는 테스트에는 해당 프로젝트의 GCM 읽기·쓰기 권한이 있는 서비스 계정이 필요합니다.
config-reloader는 설정 파일이 바뀌면 재로딩을 시작하는 보조 바이너리다.frontend는 GMP의 Prometheus 호환 쿼리 API에 접근 권한을 확인하는 프록시이며 쿼리 UI도 제공한다.operator는 GMP의 관리형 메트릭 수집을 담당하는 Kubernetes operator다.rule-evaluator는 GMP를 대상으로 규칙을 평가하는 Prometheus 규칙 평가 엔진이다.datasource-syncer는 Grafana의 Prometheus 데이터 소스에 OAuth2 토큰을 주기적으로 넣는 cron job이다.gmp-migrate는 Prometheus Operator 리소스를 GMP CRD로 변환하는 마이그레이션 CLI다.