HyperDX 실사 — 배포 방식과 Datadog 호환의 경계
HyperDX 화면에서 로그, 트레이스, 세션 리플레이를 함께 볼 수 있습니다.
그러면 Datadog을 통째로 바꿀 수 있을 것처럼 보입니다.
하지만 수집 데이터가 들어오는 것과 기존 운영 워크플로가 같은 의미로 옮겨지는 것은 다릅니다.
2026-07에 확인했던 기능 중 일부는 2026-09에 이미 바뀌었습니다.
PromQL 실험 경로가 생겼고,
공식 Terraform provider가 ClickStack 리소스를 지원하며,
Datadog receiver가 ClickStack Collector에 포함됐습니다.
기능표에는 날짜가 꼭 필요한 이유입니다.
이 글은 2026-09-15 공개 문서 기준의 실사 기록입니다.
네 컴포넌트를 따로 본다
ClickStack을 하나의 애플리케이션으로만 보면 장애 경계를 놓칩니다.
| 컴포넌트 | 역할 | 상태가 남는 곳 |
|---|---|---|
| ClickHouse | 로그·트레이스·메트릭·세션 저장과 조회 | MergeTree 계열 테이블 |
| HyperDX | UI와 API, 탐색·대시보드·알림 | MongoDB의 앱 설정과 함께 동작 |
| OTel Collector | 수신·변환·batch·export | queue 설정에 따라 메모리 또는 파일 |
| MongoDB | 사용자·source·dashboard·alert 메타데이터 | MongoDB 데이터 파일·backup |
ClickHouse만 복구하면 이벤트는 돌아올 수 있습니다.
MongoDB를 복구하지 않으면 source mapping과 대시보드, 알림이 원래대로 돌아오지 않습니다.
Collector의 queue가 휘발성이면 두 저장소 앞에서 데이터가 사라질 수 있습니다.
데이터는 어떤 테이블에 들어가나
기본 ClickStack schema는 신호별 테이블을 나눕니다.
| 신호 | 대표 테이블 | 조사할 때 중요한 필드 |
|---|---|---|
| 로그 | otel_logs | TraceId, Body, resource/log attributes |
| 트레이스 | otel_traces | TraceId, SpanId, rum.sessionId |
| 메트릭 | otel_metrics_* | metric type별 값, exemplar |
| 세션 | hyperdx_sessions | replay event와 session 식별자 |
attribute는 기본적으로 Map(LowCardinality(String), String) 형태를 사용합니다.
현재 Helm 문서 는 이 schema를 관측성 기본값으로 권장하고 JSON typed schema는 작은 고정 key-set의 평가용 Beta로 설명합니다.
ClickHouse 엔진에 JSON 타입이 있다는 사실과 ClickStack 기본 스키마가 JSON이라는 주장은 다릅니다.
세션과 트레이스가 이어지는 지점
브라우저 SDK가 trace context와 session ID를 보존하면 트레이스의 rum.sessionId로 세션을 연결할 수 있습니다.
개념적으로는 다음 쿼리입니다.
SELECT
TraceId,
SpanId,
SpanName,
SpanAttributes['rum.sessionId'] AS session_id,
Timestamp
FROM default.otel_traces
WHERE SpanAttributes['rum.sessionId'] = {session_id:String}
ORDER BY Timestamp;실제 컬럼명과 materialized field는 설치 버전의 SHOW CREATE TABLE로 확인해야 합니다.
SDK가 세션 리플레이를 보냈다는 것만으로 backend span까지 자동 연결되는 것은 아닙니다.
W3C trace context 전달과 CORS, proxy header 보존을 함께 봐야 합니다.
배포 모드는 무엇이 다른가
2026-09 공개 문서 기준으로 선택지를 운영 책임 중심으로 나눠 봅니다.
| 모드 | 잘 맞는 용도 | 직접 맡는 범위 |
|---|---|---|
| Managed ClickStack | 운영 부담을 줄인 프로덕션 | 계측·데이터 모델·비용 관리 |
| Helm v2.x | Kubernetes self-hosted | CH·Keeper·MongoDB·Collector·HyperDX |
| All-in-One | 평가·로컬 실험 | 단일 컨테이너의 데이터·업그레이드 |
| Docker Compose | 개발·소규모 검증 | 서비스별 영속성·네트워크·backup |
| HyperDX only | 기존 ClickHouse 연결 | ClickHouse와 ingestion 전체 |
| Local/embedded | 빠른 탐색 | 제한된 인증·영속성·운영 기능 |
공식 Helm v2.x는 clickstack-operators와 clickstack의 두 단계 설치입니다.
v1.x 인라인 차트에서 in-place upgrade하는 경로는 지원되지 않습니다.
배포 모드 하나를 골랐다고 production readiness가 자동으로 따라오지는 않습니다.
HA, backup, TLS, secret, queue를 별도로 확인해야 합니다.
OSS 접근통제는 Managed와 같지 않다
2026-07 조사에서는 OSS의 RBAC 부재가 큰 경계였습니다.
2026-09 현재 ClickStack에는 세밀한 RBAC 문서가 있습니다.
하지만 공식 RBAC 문서 는 Managed ClickStack only라고 명시합니다.
Managed에서는 dashboard, saved search, source, alert, webhook, notebook에 역할별 권한을 줄 수 있습니다.
이 사실을 self-hosted OSS에도 같은 RBAC가 생겼다는 뜻으로 읽으면 안 됩니다.
self-hosted에서 reverse proxy를 붙이면 외부 로그인 경계를 만들 수 있습니다.
그래도 HyperDX 내부 리소스별 권한과 MongoDB의 설정 격리가 생기는 것은 아닙니다.
ClickHouse row policy도 SELECT 범위를 제한할 뿐 dashboard와 alert 객체까지 나누지 못합니다.
여러 팀이 함께 쓰려면 다음 선택지를 비교합니다.
- Managed ClickStack의 RBAC 사용
- 팀별 self-hosted 인스턴스 분리
- 외부 인증 proxy + 네트워크 격리
- ClickHouse 계정·row policy를 조회 경계에 추가
어느 방식이든 감사로그와 운영 비용을 따로 확인해야 합니다.
2026-07에서 2026-09 사이 달라진 것
PromQL
2026-07의 “HyperDX에는 PromQL이 없다”는 문장은 더 이상 안전하지 않습니다.
ClickStack 2026년 6·7월 공식 업데이트 는 ClickHouse TimeSeries engine의 Prometheus 형식 메트릭을 조회하는 경로와 외부 Prometheus-compatible storage에 질의를 위임하는 경로를 모두 실험 기능으로 설명합니다.
다만 기존 otel_metrics_* 테이블을 그대로 PromQL로 조회한다는 뜻은 아닙니다.
저장소와 schema를 함께 확인해야 합니다.
Terraform
ClickHouse Terraform provider의 ClickStack 지원 은 v3.25부터 self-hosted와 Managed 리소스를 Beta로 관리합니다.
dashboard, alert, source, saved search, connection, webhook이 대상입니다.
Beta이므로 schema와 동작이 바뀔 수 있습니다.
UI와 Terraform이 같은 dashboard를 동시에 수정할 때 관리 주체도 정해야 합니다.
provider 글은 UI 변경이 이후 dashboard_json 적용으로 덮일 수 있는 drift 경계를 설명합니다.
알림
ClickStack alert 문서 는 saved search와 dashboard chart에서 alert를 만드는 두 경로를 설명합니다.
SQL chart에서는 이동 평균과 표준편차 같은 조건을 직접 구성할 수 있습니다.
그렇다고 Datadog의 anomaly monitor, composite monitor, Alertmanager의 inhibition이 같은 제품 기능으로 제공된다는 뜻은 아닙니다.
SQL로 표현 가능한 조건과 운영 workflow를 구분해야 합니다.
Datadog receiver
2026년 6·7월 ClickStack 변경 에는 opt-in Datadog receiver가 포함됐습니다.
ENABLE_DATADOG_RECEIVER를 켜면 Agent가 8126으로 logs, metrics, traces를 보낼 수 있습니다.
이는 기존 계측을 바로 바꾸지 않고 병렬 평가하기에 유용합니다.
수신이 된다는 사실이 Datadog의 저장 의미와 화면을 모두 보존한다는 뜻은 아닙니다.
Datadog 호환은 네 경계로 나눈다
| 경계 | 확인할 것 | 성공의 의미 |
|---|---|---|
| Agent → receiver | 세 신호가 수신되는가 | payload가 Collector에 도착 |
| 변환 → ClickHouse | 타입·속성·trace ID가 보존되는가 | 새 schema로 조회 가능 |
| browser → replay | SDK·session·trace가 연결되는가 | 새로 수집한 웹 RUM 사용 가능 |
| 설정 이관 | dashboard·monitor·report 의미가 보존되는가 | 운영 workflow 재구성 완료 |
첫 번째 경계만 통과하고 “Datadog 호환”이라고 쓰면 나머지 세 단계가 사라집니다.
특히 metric temporality와 distribution 집계,
sampling된 trace의 보정,
기존 session recording format은 별도 검증 대상입니다.
웹 RUM과 모바일 RUM
웹의 표준 경로는 @hyperdx/browser입니다.
세션 리플레이, error, Web Vitals, network와 backend trace 연결을 구성할 수 있습니다.
기존 Datadog browser payload와 과거 녹화 파일을 변환해 읽는 경로는 조사 자료에서 확인하지 못했습니다.
새 SDK로 새 데이터를 수집하는 마이그레이션으로 보는 편이 안전합니다.
모바일은 더 좁습니다.
조사 당시 @hyperdx/otel-react-native는 trace·error·network 경로를 제공하지만 native iOS·Android·Flutter session replay의 대체 범위는 확인하지 못했습니다.
GitHub issue #397 은 React Native 경로의 한계를 보여주지만 한 이슈를 전체 모바일 로드맵으로 확대하지 않습니다.
착수 전 현재 RUM 사용량을 web과 mobile로 나눠야 합니다.
기능 개수로 호환율을 만들지 않는다
기능표의 행을 세어 퍼센트를 만들면 보기에는 명확합니다.
하지만 한 행에는 browser SDK가 들어가고,
다른 한 행에는 전체 Incident Management 제품군이 들어갑니다.
부분 지원을 완전 지원과 같은 값으로 더하면 의미가 더 흐려집니다.
대신 실제 사용 질문을 기준으로 판정합니다.
| 질문 | 필요한 증거 |
|---|---|
| 오류가 난 사용자 세션을 재생할 수 있나 | 새 SDK의 replay + error 연결 |
| 브라우저에서 서버 trace까지 갈 수 있나 | trace context와 session ID 보존 |
| 기존 metric alert를 옮길 수 있나 | query 의미·window·grouping·notification 대조 |
| IaC로 재현할 수 있나 | provider apply 후 UI와 API 결과 일치 |
| 팀별로 볼 수 있는 범위를 나눌 수 있나 | 배포 모드에 맞는 실제 권한 시험 |
| 수집 중단을 감지할 수 있나 | Collector queue/exporter 별도 alert |
중요한 질문 하나가 실패하면 기능 호환율이 높아도 이관을 멈출 수 있습니다.
아직 별도 제품이 필요한 영역
2026-09 조사에서 ClickStack 공개 자료만으로 동등성을 확인하지 못한 영역입니다.
- Incident Management와 On-Call 전체 workflow
- Alertmanager 수준의 silence·inhibition·routing
- SIEM·CSPM·CIEM·runtime security 같은 보안 제품군
- Synthetics browser/API test 제품군
- native mobile session replay
- NPM·NDM 같은 network monitoring
- continuous profiler
“문서를 찾지 못했다”는 “기능이 절대 없다”는 판정과 다릅니다.
필요한 영역만 최신 문서와 실제 PoC로 다시 확인해야 합니다.
배포 전에 닫을 질문
- Helm v2.x와 애플리케이션 버전을 고정했는가
- ClickHouse와 MongoDB를 각각 복원할 수 있는가
- Collector queue는 장애 시간을 버티는가
- 실제 테이블 TTL을 확인했는가
- web/mobile 사용량을 나눴는가
- Managed 전용 기능을 OSS 기능으로 세지 않았는가
- dashboard와 alert의 관리 주체를 정했는가
- 기존 운영 질문이 새 stack에서 같은 답을 내는가
마무리
HyperDX는 ClickHouse 위에서 로그, 트레이스, 메트릭, RUM을 한 화면에 연결하는 강한 출발점을 제공합니다.
2026년 들어 Terraform, Datadog receiver, alert와 Managed RBAC도 빠르게 확장됐습니다.
그 변화가 self-hosted 운영과 Datadog 전체 제품군의 동등성을 자동으로 만들지는 않습니다.
결론 : 호환성은 기능 개수가 아니라 수신·변환·RUM·설정 네 경계를 실제 데이터로 통과했는지로 판단합니다.
확인 시점: 2026-09-15.