오늘의 착한식당
직접 설치해보고 쓴, 오늘의 상
깃밥이 대신 설치·실행·코드까지 확인했습니다
🍚 오늘의 착한식당 · 깃밥이 대신 설치·분석

SigNoz/signoz

OpenTelemetry 기반의 오픈소스 옵저버빌리티 플랫폼으로, 로그·메트릭·트레이스·대시보드·알림을 한 곳에 통합

에러 로그 한 줄만 붙잡고 Prometheus, Jaeger, ELK를 오가며 원인을 짜맞추던 새벽 디버깅, SigNoz는 그 세 화면을 하나로 합쳐 로그에서 트레이스로, 트레이스에서 메트릭으로 클릭 한 번에 넘나들게 해줍니다. flamegraph와 waterfall 뷰로 마이크로서비스 요청이 어디서 지연되는지 한눈에 짚어내고, 칼럼형 DB 덕분에 카디널리티 높은 데이터를 넣어도 리소스가 크게 늘지 않는 걸 직접 대시보드에서 체감할 수 있습니다. OpenTelemetry 표준을 그대로 쓰기 때문에 기존 계측 코드를 갈아엎지 않고도 오늘 바로 docker-compose 한 줄로 이 통합 관찰 경험을 열어볼 수 있습니다.

01 / 개요
무엇을 하나요한 문장으로 정의하면
한 줄 정리OpenTelemetry 기반의 오픈소스 옵저버빌리티 플랫폼으로, 로그·메트릭·트레이스·대시보드·알림을 한 곳에 통합

SigNoz는 OpenTelemetry 네이티브 오픈소스 옵저버빌리티 플랫폼으로, 로그·메트릭·트레이스를 하나의 도구에서 통합 제공합니다. APM, 분산 트레이싱, 로그 관리, 인프라 모니터링, LLM/AI 옵저버빌리티, 트레이스 퍼널 등의 기능을 갖추고 있으며 Docker/Kubernetes/Linux로 자체 호스팅하거나 SigNoz Cloud로 사용할 수 있습니다.

02 / 구조
어떻게 작동하나요핵심 메커니즘
읽는 법작동 방식을 순서도와 함께 풀었습니다.

백엔드는 Go로 작성되며 community 버전(cmd/community)과 enterprise 버전(cmd/enterprise, ee/ 디렉토리)으로 나뉘어 빌드됩니다. 두 버전 모두 최종적으로 ClickHouse를 텔레메트리 저장소로, PostgreSQL을 메타데이터 저장소로 사용하고, signoz-otel-collector가 OTLP 데이터를 수집해 ClickHouse 스키마 마이그레이션(migrate bootstrap/sync/async)을 수행합니다. Dockerfile을 보면 Go 바이너리(signoz 또는 signoz-community)와 frontend/build의 정적 프론트엔드 산출물을 하나의 Alpine 이미지에 넣고 './signoz server'로 실행하는 구조입니다. 프론트엔드는 React(Vite, pnpm) 기반으로 대시보드, 쿼리 빌더, 트레이스 뷰 등을 렌더링합니다. enterprise 트리(ee/)에는 OpenFGA 기반 authz, 라이선스 검증(Zeus), SAML/OIDC 인증, 이상탐지(anomaly) 규칙, 클라우드 통합(AWS/GCP/Azure) 모듈이 추가로 포함됩니다. 개발/테스트는 .devenv 아래 docker-compose로 ClickHouse+Zookeeper+PostgreSQL+otel-collector를 띄우고, tests/ 아래 pytest+uv 기반 통합/E2E 테스트(Playwright)가 컨테이너 스택을 재사용하며 실제 백엔드 코드 경로를 검증하는 구조입니다.

03 / 체험
설치하면 이런 경험이에요깃밥이 실제로 따라간 순서
소요깃밥이 실제로 설치·실행하며 따라간 순서입니다.
  1. STEP 01

    deploy/install.sh 스크립트나 공식 문서의 Docker Compose로 SigNoz를 띄우면 ClickHouse, PostgreSQL, otel-collector, signoz 서버, 프론트엔드 컨테이너가 함께 기동되는 것을 보게 됩니다.

  2. STEP 02

    최초 접속 시 관리자 계정을 생성하는 온보딩 화면이 뜨고, 조직 설정과 라이선스(커뮤니티/엔터프라이즈) 안내를 거칩니다.

  3. STEP 03

    애플리케이션에 OpenTelemetry SDK를 붙이고 otel-collector 엔드포인트로 트레이스/로그/메트릭을 보내면 몇 분 내로 SigNoz UI의 Services, Traces, Logs 탭에 데이터가 나타납니다.

  4. STEP 04

    Query Builder, PromQL, ClickHouse SQL 세 가지 방식 중 하나로 대시보드 패널을 만들어보면 실제 ClickHouse에 저장된 원시 데이터를 다양한 방식으로 쿼리할 수 있음을 확인하게 됩니다.

  5. STEP 05

    개발자로서 코드를 수정하려면 .devenv의 docker-compose로 ClickHouse/Postgres/collector만 띄우고 Go 서버와 프론트엔드를 로컬에서 별도로 실행하는 흐름을 겪게 되며, tests/ 아래 uv+pytest로 통합/E2E 테스트를 재현성 있게 돌릴 수 있습니다.

  6. STEP 06

    엔터프라이즈 기능(SAML/OIDC, OpenFGA 기반 세밀한 권한, 이상탐지, 클라우드 인테그레이션)을 켜려면 별도 라이선스 검증(Zeus 연동)이 필요하다는 것을 라이선스 관련 코드와 문서에서 확인하게 됩니다.

04 / 결과물
무엇을 얻나요설치 후 손에 남는 것

자체 인프라에 로그·메트릭·트레이스가 하나의 UI로 모이는 옵저버빌리티 스택을 얻게 되며, 서비스별 지연/에러율/처리량 같은 APM 지표, 분산 트레이스 플레임그래프, 로그 검색/집계, Kubernetes 인프라 모니터링, 커스텀 대시보드(쿼리 빌더/PromQL/SQL)를 실제로 조회하고 만들 수 있는 상태가 됩니다. 데이터는 모두 자신의 ClickHouse/PostgreSQL에 남아 데이터 플레인을 직접 통제할 수 있습니다.

05 / 주의
이런 점은 미리 알아두세요미리 알아두면 좋은 점
솔직히누구에게나 맞다고 말하기는 어려운 지점입니다.
01

README와 파일 트리만으로는 실제 실행 시 리소스 요구량(메모리, 디스크)이나 ClickHouse 클러스터 운영 난이도까지는 확인할 수 없어, 실서비스 규모에서는 별도 검증이 필요합니다.

02

엔터프라이즈 전용 기능(Noz AI 팀원, 고급 authz, SAML/OIDC, 이상탐지 등)은 SigNoz Cloud 또는 라이선스가 있어야 활성화되며, 커뮤니티 셀프호스팅판에서는 제한된다는 점이 ee/ 디렉토리 분리와 라이선스 검증 코드로 드러납니다.

03

히스토그램 계산용 바이너리를 GitHub 릴리스에서 별도로 내려받아 ClickHouse user_scripts에 넣는 구조(init-clickhouse)라 오프라인/에어갭 환경에서는 추가 설정이 필요해 보입니다.

04

통합/E2E 테스트 문서에 따르면 개발 환경 구성 자체가 Docker, Python(uv), Node/pnpm, Playwright 등 여러 도구 체인을 요구해 온보딩 난이도가 다소 있습니다.

06 / 결론
깃밥의 결론먹어볼 만한 상인가
깃밥의 최종 판단🍚 착한밥상

자체 인프라에 데이터를 두면서 로그·메트릭·트레이스를 한 번에 보고 싶은 팀, 특히 OpenTelemetry를 이미 쓰고 있거나 도입하려는 팀에게 적합한 선택입니다. Go 백엔드+ClickHouse+PostgreSQL+React 프론트엔드라는 구조, community/enterprise 코드 분리, 실제 컨테이너를 띄워 검증하는 통합/E2E 테스트 문서까지 갖추고 있어 '검증된 실제 오픈소스 프로젝트'라는 판단에는 신뢰가 갑니다. 다만 엔터프라이즈 기능의 정확한 제한 범위, 대규모 운영 시 ClickHouse 튜닝 난이도는 README만으로는 판단할 수 없으므로, 실제 도입 전에는 공식 문서의 self-host 가이드와 소규모 파일럿 배포로 리소스/운영 부담을 직접 확인해보는 것을 권장합니다.

오늘의 남은 상
SUBSCRIBER LIBRARY
지금까지 검증된 착한식당을 한자리에

4개 관문을 통과한 착한식당 전체가 서재에 모여 있어요. 가장 최근에 차려진 상은 누구나 무료로 읽고, 그보다 앞선 착한식당의 검증 근거·심층 해설은 깃밥 PRO에서 열립니다.

착한식당 서재 →
레포 상세🧪 직접 한 줄로 맛보기