Fanout은 OpenTelemetry 데이터를 한 바이너리에서 분석한다

Fanout은 OpenTelemetry 데이터를 한 바이너리에 모읍니다. 트레이스(trace)·로그(log)·메트릭(metric)을 한 바이너리와 디렉터리에 모읍니다. 데이터를 Parquet에 저장하고 DuckDB로 분석하며 외부 저장소 서비스도 따로 운영하지 않아도 됩니다. 저는 저장소까지 직접 챙기는 팀에게 이 구성이 솔깃합니다. 데이터 저장과 분석을 위해 관리할 서비스가 줄기 때문입니다.

Coroot는 7개 언어의 OpenTelemetry SDK 오버헤드를 같은 조건에서 측정했습니다. Fanout은 트레이스·로그·메트릭을 저장하고 분석하는 자체 호스팅 백엔드를 내놓았습니다. 두 기사는 OpenTelemetry를 다루지만, 하나는 SDK의 추적 비용을 비교하고 다른 하나는 데이터를 저장·분석하는 도구를 소개합니다.

Fanout은 세 종류의 텔레메트리를 Parquet에 저장하고 DuckDB로 분석합니다. 외부 저장소 없이 수집부터 분석까지 한 배포물에서 다루게 한 점이 반갑습니다.

다만 프리릴리스(pre-release)라 제품 변경 때 데이터 이전 경로가 제공되지 않을 수 있습니다. 또 단일 노드(single node)로 동작해 클러스터링(clustering)이나 복제(replication)를 지원하지 않습니다. 작은 환경에서 시험하기에는 간편하고, 확장이나 분산 복구가 필요한 서비스라면 기존 백엔드를 유지한 채 별도 환경에서 검증하는 편이 안전합니다.

테스트 데이터를 보내 미리보기 단계인 대시보드와 알림이 필요한 정보를 보여주는지 확인하십시오. 평소와 피크 수집량을 각각 적용해 디스크 사용량과 재시작 뒤 데이터 유지도 살펴보십시오. 두 상황에서 수용량과 복구가 충분히 확인되면 한 대의 노드로 운영할 수 있는 범위를 가늠할 수 있습니다.

관측 도구를 새로 고를 때, 평소 확장성과 장애 복구 가능성 중 무엇을 먼저 확인하십니까?