promkr 뉴스레터 2025년 4월호

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

1. SQL 예제로 살펴보는 PromQL 조회와 집계

원문: Introduction to PromQL for Cloud-Native Observability and Time Series Data Analysis · Greptime · 2025-04-03

Greptime이 LinkedIn에 게시한 PromQL 소개 글을 기준으로 정리했습니다. 글은 SQL에 익숙한 독자에게 시계열 모니터링용 질의 언어가 필요한 이유를 설명합니다. 모니터링 데이터에서는 레이블로 대상을 고르고 시간 범위로 값을 모으는 작업이 반복됩니다. Greptime은 PromQL이 이런 선택·계산·분석을 간결하게 표현하도록 설계된 언어라고 소개합니다.

예제는 도시별 온도와 소음 데이터를 사용합니다. SQL의 테이블 조회에 대응하는 출발점으로 메트릭 이름을 제시하고, city_env_temp_total{city="New York"}처럼 중괄호 안에 레이블 조건을 붙입니다. 일치와 불일치는 =와 !=, 정규식 일치와 불일치는 =~와 !~로 표현합니다. 시간 범위는 선택자 뒤의 대괄호로 지정하며, city_env_temp_total{city="New York"}[30d]는 30일 범위를 지정하는 예입니다.

계산 예제에서는 avg_over_time(city_env_noise_total[30d]) > 100으로 30일간 평균 소음이 100dB를 넘는 시계열을 고릅니다. 글은 sum, min, max, avg, rate도 함께 소개합니다. 시간 단위는 밀리초부터 연도까지 지원하며, d는 24시간, w는 7일, y는 365일을 전제로 합니다. Greptime은 SQL과 PromQL의 용도가 다르므로 사용 사례에 맞춰 언어를 선택해야 한다고 설명합니다.

2. GreptimeDB의 통합 데이터 모델과 저장소

원문: GreptimeDB Open Source — One Engine for Metrics, Logs & Traces · Greptime

GreptimeDB 제품 페이지는 메트릭·로그·트레이스를 하나의 엔진에 저장하는 오픈소스 옵저버빌리티 데이터베이스를 소개합니다. 각 신호는 태그, 타임스탬프, 필드로 이루어진 공통 테이블 모델을 사용합니다. 데이터에 서비스·호스트·trace ID 같은 공통 식별자가 있으면 데이터베이스 사이의 ETL 없이 SQL로 연관 지을 수 있다는 설명입니다.

엔진은 Rust로 작성했으며 Apache Arrow와 DataFusion을 사용합니다. 역색인, 스키핑 인덱스, 전문 검색 인덱스로 카디널리티가 높은 데이터를 조회합니다. 컴퓨트 노드는 S3, GCS, Azure Blob 같은 오브젝트 스토리지의 공유 데이터를 읽고, 메모리와 로컬 디스크 캐시는 최근 데이터와 자주 조회하는 데이터를 보관합니다. Greptime은 압축과 오브젝트 스토리지를 조합해 저장 비용을 최대 50배 낮춘다고 설명합니다.

수집에는 OpenTelemetry OTLP, Prometheus Remote Write, Loki Push, Elasticsearch Bulk, InfluxDB line protocol 등을 지원합니다. 조회에는 SQL, 메트릭용 PromQL, 트레이스용 Jaeger Query API를 제공합니다. 프로토콜별 지원 범위는 서로 다릅니다. Loki는 push 수집만 지원하고 LogQL은 지원하지 않으며, Elasticsearch _bulk 수집은 삽입만 허용합니다.

클러스터 배포, 오브젝트 스토리지, 연속 집계용 Flow 엔진은 Apache-2.0 배포판에 포함됩니다. 오픈소스판에서는 재파티셔닝과 Region 이동을 수동으로 수행합니다. Enterprise는 이 작업을 자동화하고 읽기 복제본, 워크로드 격리, RBAC/LDAP, 감사 로그 등을 추가합니다. 단일 바이너리는 ARM 장치와 클라우드 클러스터에서 같은 API로 동작합니다.

3. OCB를 이용한 커스텀 Collector 제작

원문: Customize Your Own OpenTelemetry Collector: An Introduction To OCB · Evan Bradley, Pablo Baeyens

CNCF-hosted Co-located Events Europe 2025의 발표 소개문을 기준으로 정리했습니다. Dynatrace의 Evan Bradley와 Datadog의 Pablo Baeyens가 OpenTelemetry Collector Builder(OCB)를 소개하는 세션입니다. 기존 배포판에 필요한 컴포넌트 조합이 없거나, 특정 용도에 맞는 자체 컴포넌트를 넣고 싶은 사용자를 대상으로 합니다.

OCB는 Collector 유지관리자들이 커스텀 Collector를 쉽게 만들도록 개발한 도구입니다. 소개문은 OCB의 기본 동작, 릴리스 파이프라인 구성, Docker 이미지 배포, 긴급한 upstream 컴포넌트 수정, 자체 컴포넌트 사용을 발표 범위로 제시합니다. 널리 쓰이는 Collector 배포판이 OCB로 릴리스하는 사례도 다룬다고 안내합니다. 세션은 2025년 4월 1일 15:20~15:45 BST에 Observability Day 중급 세션으로 편성됐습니다.

4. RoRvsWild의 Rails 성능 모니터링과 오류 추적

원문: Ruby APM & error tracking for Rails · RoRvsWild

RoRvsWild는 Ruby on Rails 개발자를 위한 성능 모니터링과 오류 추적 서비스입니다. 제품 페이지는 요청 응답 시간과 처리량을 측정해 코드 병목을 찾고, 예외와 배포 이력을 함께 살펴보는 기능을 소개합니다. 백그라운드 작업에서는 ActiveJob, Sidekiq, GoodJob, Solid Queue, Resque, DelayedJob을 지원하며 SQL 쿼리와 그 영향을 측정합니다.

새 예외는 이메일, Slack, Discord, Teams로 알릴 수 있습니다. 코드 리비전을 자동 추적하므로 배포별 성능 변화와 새 오류도 비교할 수 있습니다. 서버 모니터링 대상은 부하, RAM, swap, CPU, 디스크 공간입니다. 오픈소스 Ruby gem에는 로컬 요청 프로파일링 기능도 있어, 데이터를 rorvswild.com으로 보내지 않고 개발 중인 요청을 분석할 수 있습니다.

페이지는 Gemfile에 gem "rorvswild"를 추가하는 설정과 gem 버전 1.12.2를 표시합니다. Heroku, Scalingo를 비롯한 Ruby 호스팅과 Redis, MongoDB, Elasticsearch, 모든 SQL 데이터베이스를 지원한다고 안내합니다. 계정당 앱과 개발자 수에는 제한이 없으며, 알림은 앱별로 관리합니다.

모니터링 페이지를 Markdown으로 복사하거나 MCP 서버로 에이전트에 연결하는 기능도 제공합니다. MCP는 앱별로 사용 여부를 선택하며 Cursor, Claude Code, VS Code, Windsurf, Zed와 연동합니다. 요금은 월간 요청과 작업 수를 합산해 계산합니다. 페이지의 예시는 15M 요청·작업에 125€이며, 오픈소스 앱은 무료이고 신용카드 없이 14일간 체험할 수 있습니다.

5. Telltale의 애플리케이션 건강 모델과 알림

원문: Telltale: Netflix Application Monitoring Simplified · Netflix Technology Blog · 2020-08-14

Netflix는 잦은 알림, 많은 대시보드, 임계값 설정과 유지관리 부담을 줄이려고 Telltale을 만들었습니다. Telltale은 애플리케이션의 평소 건강 상태를 학습하고, 상태가 나빠지는 흐름을 감지합니다. 글이 발표된 시점에는 실제 서비스를 담당하는 Netflix 애플리케이션 100개 이상을 감시했습니다. 화면에는 해당 앱과 상위·하위 서비스의 관련 데이터, 지역 간 트래픽 이동, 인접한 배포 이벤트를 표시합니다.

건강 모델은 Atlas 시계열 메트릭, Mantis 실시간 스트리밍 데이터, 인프라 변경, canary 실행과 배포, 의존 서비스 상태, 클라이언트 메트릭과 QoE 변화, 기존 알림을 결합합니다. 신호마다 의미와 중요도를 달리 해석합니다. 지연 증가와 오류율 증가를 구분하고, 지역 간 트래픽 이동으로 한 지역의 트래픽이 사라지고 다른 지역의 트래픽이 두 배가 되는 상황도 고려합니다. 관리형 signal pack을 애플리케이션 프로필로 묶고 서비스 의존성을 자동 추적해 설정 부담을 줄입니다. 분석에는 통계, 규칙, 머신러닝을 함께 사용하며 장기 추세와 메모리 누수도 탐지합니다.

문제를 감지하면 Telltale은 이슈를 만들고 Slack, 이메일, PagerDuty로 알립니다. 원인이 다른 서비스에 있으면 문맥을 고려해 해당 팀으로 알림을 보내며, 팀에는 알림 하나를 전달합니다. Slack 스레드에는 비정상 신호와 판단 이유를 넣고 상황 변화와 해결 상태를 갱신합니다. 장애 스냅샷에는 관련 신호를 계속 추가하며, Application Incident Summary에서 총 중단 시간과 MTTR을 확인할 수 있습니다. Spinnaker의 점진적 배포에도 같은 건강 모델을 사용해 문제 징후가 나타나면 배포를 중단하고 롤백합니다.

Netflix는 서비스 로그와 트레이스, 더 높은 해상도의 메트릭을 건강 모델에 활용하는 방안을 당시 평가하고 있었습니다. 신규 앱 등록은 개별 지원에 의존해 규모 확장에 어려움이 있었고, 셀프서비스 UI와 원인 추정 방식도 개선 과제로 제시했습니다. 이 글은 알고리즘의 세부 구현을 설명하지 않으며, 별도 후속 글에서 다룰 예정이라고 밝힙니다.

6. OpenTelemetry와 옵저버빌리티 스타트업의 기회

원문: OpenTelemetry Opens the Door for Observability Startups · The New Stack

제공된 원문 자료에는 구독 양식만 있고 기사 본문이 없어 뉴스레터 소개만 옮깁니다. 뉴스레터는 OpenTelemetry가 텔레메트리 수집을 표준화하면서 옵저버빌리티 시장의 진입장벽을 낮추고 새 스타트업의 기회를 열었다는 글로 소개합니다.

7. Embrace의 모바일 사용자 경험과 백엔드 추적 연결

원문: Embrace: Modern mobile observability built on OpenTelemetry · Colin Contreary · 2025-03-13

Embrace는 오픈소스 SDK와 분석 대시보드를 결합한 모바일 옵저버빌리티 도구입니다. 글은 크래시·오류 중심의 모바일 모니터링과 백엔드 도구 사이에 공통 언어가 부족하다는 문제에서 출발합니다. 서버의 지연이나 실패율만으로는 사용자가 앱을 떠났는지, 재시도 후 구매를 마쳤는지 알기 어렵다는 설명입니다. Embrace는 사용자 행동과 기술적 상태를 함께 측정해 문제의 사용자·사업 영향을 판단하도록 돕습니다.

SDK 지원 플랫폼은 iOS, Android, React Native, Unity, Flutter입니다. Embrace는 앱이 백그라운드에 있을 때를 포함해 모든 사용자의 모든 세션을 수집한다고 설명합니다. User Timeline에는 느리거나 실패한 네트워크 호출, 주요 사용자 흐름, breadcrumbs, 장치 상태 변화를 표시합니다. 로그는 원시 데이터와 집계 화면으로 확인할 수 있고, 로그인·검색·결제 같은 동작은 스팬과 트레이스로 계측합니다. 성능 트레이스에는 그 시간에 발생한 네트워크 요청도 스팬으로 자동 포함합니다.

OpenTelemetry 기반 오픈소스 SDK에서 수집한 모바일 텔레메트리는 OTel 호환 백엔드로 보낼 수 있습니다. Embrace는 가능한 범위에서 데이터 모델을 OpenTelemetry에 맞췄습니다. 앱 라이프사이클 경계를 넘는 진행 중 스팬처럼 모바일 특성 때문에 맞추기 어려운 부분은 커뮤니티와 표준 개선을 논의하고 있다고 밝힙니다. 크래시·로그·스팬·세션·네트워크 데이터로 만든 커스텀 메트릭은 Grafana, Chronosphere, Honeycomb, New Relic 등으로 전달할 수 있습니다.

Network Span Forwarding은 클라이언트의 네트워크 요청을 가로채 trace parent를 넣습니다. 백엔드가 기록한 trace ID를 Embrace의 사용자 세션 내 요청에도 붙이므로 양쪽 팀이 같은 요청을 찾아볼 수 있습니다. 요청이 시작된 세션으로 돌아가는 링크도 제공해 백엔드 조사 화면에서 모바일 사용자의 요청 직전 상황까지 확인하도록 연결합니다.

8. Fastrace의 선택적 계측과 Rust 추적 연동

원문: Fastrace: A Modern Approach to Distributed Tracing in Rust · FastLabs · 2025-03-22

FastLabs는 Rust 라이브러리에 분산 추적을 넣을 때 생기는 성능 부담과 로깅 연동 문제를 줄이기 위해 Fastrace를 소개합니다. 저자들은 tokio-rs/tracing을 사용하며 별도 로깅 매크로, log와의 양방향 연결 설정, 서비스 경계를 넘는 문맥 전파에 어려움을 겪었다고 설명합니다. Fastrace는 분산 추적에 집중하고 기존 log 사용 방식을 유지하는 접근을 택합니다.

함수에는 #[fastrace::trace]를 붙여 스팬을 생성하고 관리합니다. 글의 라이브러리 의존성 예제는 fastrace = "0.7"이며, 라이브러리 자체에서는 enable 기능을 켜지 않습니다. 최종 애플리케이션이 이 기능을 활성화하면 라이브러리의 계측도 작동해 스팬을 수집·보고합니다. FastLabs는 활성화하지 않은 경우 계측 코드가 컴파일 과정에서 제거돼 런타임 오버헤드가 없다고 설명합니다.

문맥 전파에는 프레임워크별 보조 crate와 레이어를 사용합니다. fastrace_reqwest::traceparent_headers()는 HTTP 요청에 추적 문맥을 넣고, fastrace_tonic의 서버·클라이언트 레이어는 gRPC 요청에서 문맥을 추출하거나 주입합니다. Apache OpenDAL의 FastraceLayer는 데이터 작업을 추적하며, Poem에는 요청 문맥을 추출하는 미들웨어를 제공합니다. 원문의 예제는 이런 헤더와 레이어를 애플리케이션 코드에 연결하는 방식입니다.

로깅 조합은 표준 facade인 log, 로깅 구현인 logforth, 추적용 fastrace로 구성합니다. logforth의 FastraceDiagnostic은 로그에 trace ID를 붙이고 FastraceEvent는 로그를 스팬에 연결합니다. 글은 OpenTelemetry 지원과 Jaeger reporter 설정도 소개합니다. FastLabs는 ScopeDB가 페타바이트 규모 옵저버빌리티 데이터 작업의 추적과 디버깅에 Fastrace를 사용한다고 밝힙니다.

9. GitHub Receiver의 저장소 메트릭과 Actions 트레이스

원문: GitHub Receiver · open-telemetry/opentelemetry-collector-contrib

GitHub Receiver README는 GitHub 데이터를 OpenTelemetry 메트릭과 트레이스로 바꾸는 경로를 설명합니다. GraphQL·REST API로 저장소와 조직의 버전 관리 메트릭을 수집하고, webhook endpoint로 받은 GitHub Actions 이벤트를 트레이스로 변환합니다. 문서에 표시된 안정성은 메트릭과 트레이스 모두 alpha이며, Semantic Conventions 버전은 1.43.0입니다. 메트릭은 DORA 메트릭의 선행 지표로 활용할 수 있다고 소개합니다.

메트릭 수집에는 github_org가 필수이며 search_query로 저장소 범위를 좁힙니다. 기본 수집 간격은 30초이고 설정 예제의 권장값은 300초입니다. concurrency_limit 기본값은 GitHub의 동시 요청 제한 100개보다 낮은 50이며, 병합된 PR 조회 범위는 기본 30일입니다. PAT에 대상 저장소 읽기 권한이 없으면 저장소 수만 얻을 수 있습니다. 기본 브랜치에서 생성된 뒤 변경이 없는 브랜치는 메트릭을 내보내지 않으며, rebase로 커밋 타임스탬프가 바뀌면 브랜치 시간 메트릭도 달라질 수 있습니다.

트레이스는 workflow_run과 workflow_job 이벤트로 워크플로·작업·단계의 스팬을 구성해 실행 시간과 성공·실패율을 관찰합니다. 결정적으로 생성하는 ID를 단계 내부에서도 재현하면 별도 명령의 텔레메트리를 연결할 수 있습니다. UseCheckRunID가 켜진 방식에서는 작업·단계·대기열 ID에 check_run_id를 사용하고, 단계 ID에는 원시 name: 값도 포함합니다. 같은 작업 안에서 단계 이름이 중복되면 span ID가 충돌합니다. 문서는 이 기능 게이트가 v0.151.0부터 기본 활성화라고 설명합니다.

webhook 설정의 service_name은 모든 트레이스에 사용할 service.name을 지정합니다. 값이 없으면 저장소 Custom Properties의 service_name, 저장소 이름 순으로 유도합니다. include_span_events를 켜면 원시 webhook JSON도 스팬 이벤트에 넣습니다. 기본값은 false이며, 문서는 보통 5~50KB인 payload가 저장소와 성능에 미칠 영향을 고려하라고 안내합니다. webhook endpoint에는 secret과 WAF 또는 다른 보안 수단을 적용하도록 명시합니다.

10. Deno v2.2.5의 OpenTelemetry 이벤트 기록

원문: v2.2.5 · GitHub · 2025-03-21

Deno v2.2.5 릴리스 노트는 OpenTelemetry의 기본 이벤트 기록 기능을 unstable 변경으로 추가했다고 명시합니다. 관련 항목은 feat(unstable): basic otel event recording이며 PR 번호는 #28552입니다. OpenTelemetry 수정으로는 ArrayPrototypeSplit을 StringPrototypeSplit으로 교체한 #28538도 포함됩니다. 노트에는 이벤트 기록 API의 사용법이나 세부 지원 범위가 나오지 않습니다.

다른 변경으로는 로컬 npm 패키지 사본 사용 지원이 unstable 기능으로 추가됐고, deno_core와 V8 13.5를 갱신했습니다. Node 호환 영역에서는 util.getCallSites 추가, run()의 statement 즉시 초기화, ATTACH DATABASE 문 제한이 포함됩니다. 자신이나 상위 namespace를 내보낼 때 문서 생성 중 발생하는 스택 오버플로도 수정했습니다. 타입 정의에는 ErrorConstructor의 stackTraceLimit을 추가하고 ErrorWithStackTraceLimit 인터페이스를 제거했습니다.