▲

ClickStack – ClickHouse와 HyperDX로 만든 오픈소스 Datadog 대체제

 (clickhouse.com)
2P by GN⁺ 1일전 | ★ favorite | 댓글 1개
  • ClickStack은 ClickHouse 와 HyperDX 기반의 오픈소스 관측 플랫폼(Observability) 으로, 로그, 메트릭, 트레이스, 세션 리플레이를 한 곳에서 통합적으로 처리함
  • 로그 및 트레이스 검색과 시각화를 ClickHouse 클러스터 상에서 쉽고 빠르게 지원하며, 어떤 스키마든 추가 작업 없이 적용 가능
  • 직관적인 검색과 이벤트 기반 알림, 대시보드 기능을 제공해 엔지니어가 신속하게 문제를 파악하고 대응할 수 있음
  • OpenTelemetry 표준을 기본 지원하며 다양한 언어 및 플랫폼 SDK 통합을 제공함
  • 기존 상용 솔루션 대비 저렴하고 설정이 간단하며, 여러 관측 도구를 번거롭게 오가지 않아도 한 플랫폼에서 전체 절차를 처리함

주요 기능

  • 로그, 메트릭, 세션 리플레이, 트레이스의 상관관계 분석과 검색을 한 곳에서 처리 가능함
  • ClickHouse의 기존 스키마를 그대로 활용하며 스키마에 구애받지 않는 구조
  • 빠른 검색 속도와 시각화 최적화 덕분에 대용량 데이터에도 적합
  • 풀텍스트, 속성 검색이 모두 지원되고 SQL 사용은 선택
  • 이벤트 변화 추이 분석 및 간편한 알림 설정, 대시보드 생성이 가능함
  • Native JSON 문자열 쿼리 지원
  • 실시간 로그, 트레이스 tail 기능으로 최신 이벤트 확인이 가능함
  • OpenTelemetry 통합 및 APM(성능 모니터링) 환경 지원

배포 및 시작 방법

  • ClickStack 패키지는 ClickHouse, HyperDX, OpenTelemetry Collector, MongoDB를 포함하여 통합 배포 가능함
  • HyperDX UI는 브라우저에서 접근 가능함
  • ClickHouse Cloud 환경과도 연동할 수 있고, 다양한 환경에 손쉽게 배포가 용이함

어플리케이션 계측 및 통합

HyperDX로 로그, 메트릭, 트레이스, 세션 리플레이 데이터를 수집하려면, 어플리케이션에서 테레메트리 데이터를 HyperDX로 전송해야 함

  • SDK 및 통합 옵션 제공: 브라우저, Node.js, Python 등 다양한 언어/환경용 SDK가 있어 쉽게 연동 가능함
  • OpenTelemetry 표준 지원: Kubernetes, JavaScript, Python, Java, Go, Ruby, PHP, .NET, Elixir, Rust 등 다양한 언어 및 런타임 호환 가능함
  • OpenTelemetry 수집기는 기본적으로 http://localhost:4318 주소에서 연결 가능함

기여 방법

  • PR 제출, 이슈 등록, 문서 개선, 오픈 이슈 투표, 새로운 사용 사례 제공 등 다양한 방식의 커뮤니티 기여를 환영함

개발 동기 및 철학

HyperDX 개발진의 목표는 모든 엔지니어가 운영 환경의 테레메트리를 활용해 빠르게 문제를 해결할 수 있도록 하는 것임

기존 주요 문제점:

  • 운영 관측 도구가 비싸고 데이터 확장에 따라 비용 증가 현상 문제가 큼
  • 설정과 사용 난이도가 높아 SRE 및 전문가가 필요함
  • 로그, 세션 리플레이, APM 등 각 기능이 분리되어 있어 정보 연계가 번거로움

이러한 한계를 극복하기 위해 ClickStack과 HyperDX를 오픈소스로 제공함

  • HyperDX 는 ClickHouse가 인수했음
▲
GN⁺ 1일전  [-]
Hacker News 의견

  • 왜 이미 존재하는 Grafana 대신에 커스텀 프론트엔드를 만들었는지 궁금증

  • DataDog 가격이 비싸서 HyperDX가 정말 매력적으로 느껴지는 상황 공유, 본인이 운영하는 LogLayer(https://loglayer.dev)는 TypeScript용 구조화 로거로 여러 종류의 로거와 클라우드 서비스(DataDog 등)로 로그를 전송할 수 있는 기능 지원, HyperDX용 통합 기능을 개발해서 곧 릴리즈할 예정 의견 공유, HyperDX와 LogLayer 연동 방법에 대한 문서 링크를 본인 사이트 "integrations" 섹션에 추가하고 싶다는 바람 전달, 관련 PR 링크(https://github.com/hyperdxio/hyperdx-js/pull/184) 공유

    • VictoriaLogs로 로그를 전송할 수 있는 기능도 추가해 달라는 요청, 다양한 데이터 인제스쳔 프로토콜 문서 링크(https://docs.victoriametrics.com/victorialogs/data-ingestion/)와 함께 제안
    • LogLayer와 HyperDX 연동 기능이 멋지게 보여서 직접 확인해 보겠다는 긍정적인 피드백

  • HyperDX를 실제 프로덕션에서 사용 중이고 Clickhouse와의 통합 및 비용 효율성에 큰 만족감, HyperDX에서 ClickStack으로 마이그레이션 준비가 필요한지 궁금증

    • 프로덕션 유저의 피드백에 항상 기대가 크다는 반가움 전달, HyperDX는 절대 없어지지 않고 마케팅 페이지에서도 여전히 스택의 핵심으로 강조되고 있음 설명, 앞으로 HyperDX v2와 ClickStack 패턴에 더 집중할 계획이지만 HyperDX 자체는 계속해서 엔드 유저 경험에 중점을 둘 예정 안내, ClickHouse 기반 코어의 유연성과 성능을 더 많이 활용하려는 것이 ClickStack의 목표라는 추가 설명, 오픈소스와 클라우드 양쪽에서 모두 스무스하게 변화할 수 있도록 엔지니어링에 집중 중임 공유, 사족으로 최근 와이파이가 불안정해 답변이 늦어진 상황 언급

  • Otel의 트레이스와 로깅은 괜찮지만, Otel metrics 기능은 너무 복잡하게 설계됐다고 느끼는 점 공유, ClickStack에서 statsd 데이터(특히 Datadog의 태깅 확장 포함)를 인제스트할 수 있는지, 트레이스/로그/메트릭의 통합 서비스 태깅과 연결 기능 여부, UI에서 관련 데이터 링크 기능 여부, Elixir SDK가 왜 hyperdx 라이브러리를 쓰는지 궁금, Notebooks 기능이 로드맵에 있는지 질문

    • 좋은 질문이라는 호응과 함께 Otel metrics 표준이 워낙 다양해진 이유 및 아쉬운 점 공감, OTel collector가 statsd 등 다양한 포맷 수집 및 ClickHouse로 바로 기록할 수 있어 statsd 활용 가능하다는 안내(statsdreceiver 문서 링크), 로그/트레이스는 trace/span id와 resource attributes로 연결 가능하고, k8s workload에서는 메트릭까지 관련성 제공 중임 언급, 아직 metrics correlation에 exemplars 기능은 미지원이지만 향후 계획 언급, Elixir SDK는 유저 환경에 맞게 지원하려는 방향에서 선택, 라이브러리가 독립적으로 진화해왔고 앞으로 공식 OTel SDK로 전환할지 고민 중임, Deno용 OTel integration을 직접 빠르게 도입한 사례 공유, Notebooks는 곧 실험적 상태로 공개될 예정이고 다양한 워크플로우를 활성화할 예정, 더 많은 유저 피드백에 관심 있다는 의사 전달
    • Otel metrics가 복잡하다고 느끼는 이유를 묻는 질문과 함께 statsd나 DD agent 등 기존 메트릭 파이프라인을 쉽게 대체하지 않아도 된다는 장점 안내

  • Signoz처럼 클릭하우스 기반이고 오픈소스 및 클라우드 버전을 제공하는 것이 HyperDX와 유사해 보인다는 의견 및 차이점에 대한 궁금증, UI도 비슷하다는 관찰 공유

    • Signoz와의 직접 비교를 더 듣고 싶다는 추가 궁금증

  • Kibana를 대체할 새로운 로깅 솔루션 탐색 중이며 ClickHouse 경험이 좋아서 HyperDX의 UI에 관심, 현재 로그 파이프라인이 Kubernetes 위 Vector이고 Vector가 OTel sink(베타) 지원 중이어서 데이터가 JSON인 상황에서 가장 좋은 로그 전송 방식 고민 공유, TB 단위의 대용량, 고성능 트래픽 환경임 강조

    • ClickHouse는 대용량 처리와 높은 스루풋에 특화, Vector에서 ClickHouse 직접 기록을 사용하는 사례(예: Anthropic 발표) 언급, 실제로 시도해 보고 의견 남겨주면 도움 주겠다는 제안
    • 데이터 전송 포맷을 otel로 표준화하는 것이 미래를 위해 전략적으로 좋은 선택이라는 의견, 두 가지 고민이 줄어든 느낌 공유

  • Signoz와 HyperDX(혹은 ClickHouse)와의 차이점이 궁금, 둘 다 YC 출신이며 클릭하우스를 활용하는 관찰

    • 아래에서 언급된 내용과 같이 가장 큰 차별점은 ClickHouse 팀에서 공식적으로 개발하는 1st-party 상품이라는 것, 거의 모든 클릭하우스 인스턴스에서 유연하게 동작하고 커스텀 스키마도 지원, 이는 고성능 튜닝이나 특정 대규모 환경(예: Anthropic)에서 중요, 이미 클릭하우스 데이터를 가진 경우 도입이 매우 쉽다는 장점 있음, otel을 무조건 강요하지 않으며 Vector, Cribl, S3, 커스텀 스크립트 등도 네이티브로 지원, Telemetry wrangling(고카디널리티 이벤트 델타, ML 기반 자동 로그/스팬 클러스터링 등) 기능도 있어 데이터 탐색이 쉽게 가능, session replay 기능으로 클릭부터 인프라 메트릭까지 전방위 통합 지원, 내부 ClickHouse Cloud 모니터링에서 100PB+ 스케일로 운용 및 특정 유저 이슈까지 end-to-end로 파악 가능한 유연성, 철학적으로 일반적인 "3 pillars"(logs/metrics/traces) 분리보다는 단일화/중앙화된 단서 탐색 도구를 만드는 것이 오히려 실무 디버깅에 적합하다고 믿음 공유
    • “You”가 ClickHouse임을 명확히 함

  • 회원가입 후 UI에서 "Was this search result helpful?" 위젯이 검색 전부터 나와 있어 UX가 혼란스러웠던 경험 공유, Hide 버튼을 누르면 피드백 버튼 → 다시 피드백 누르면 원상복귀되는 버그 발견, 전반적으로 폰트가 모노스페이스인데다 글씨도 작고, 굵은 흰색 및 밝은 초록색이 어두운 배경과 조화가 나쁘다고 평가, 시스템 폰트로 바꿔도 크게 개선되지 않아 전통적인 UI 스타일을 권장, 읽기 힘든 디자인 때문에 사용을 망설이게 하는 점 피드백

  • Clickhouse가 이 스택의 유일한 stateful 요소인지 궁금, Rust 기반 OTEL collector인 Rotel(https://github.com/streamfold/rotel)과의 호환성에 관심, Datadog은 자체 개발한 더 뛰어난 퍼포먼스의 OTEL collector 대체재가 있음 언급

    • Rotel은 lambda 등 경량 환경에 OTel 연동에 적합하다고 판단, HyperDX의 OTel 인제스트 엔드포인트가 이미 표준이기에 바로 호환 가능할 것이라 생각, Rotel 개발자들과도 소통했으며 Clickhouse 지원이 최근 추가되어 전체 스토리가 탄탄해진 점 강조
답변달기