OpenTelemetry Collector의 개요
OpenTelemetry Collector는 애플리케이션과 텔레메트리 목적지 사이에 놓이는 서비스입니다. 애플리케이션은 트레이스, 메트릭, 로그를 보통 OpenTelemetry 자체 프로토콜인 OTLP로 보냅니다. Collector는 이를 묶고, 지정한 것을 버리거나 고쳐 쓴 뒤, 하나 이상의 백엔드로 사본을 전달합니다. 모든 설정은 receiver(입력), processor(필터링, 샘플링, 마스킹), exporter(출력), connector(파이프라인 연결)로 이루어진 YAML 파이프라인에서 합니다.
에이전트 팀에게 이곳은 플래너, 도구 워커 세 개, 모델 제공사 두 곳을 거치는 트레이스가 다시 하나로 모이는 곳이며, 엔드투엔드 지연이 어디서 생겼는지 답이 나오는 곳입니다. LLM 스팬은 OpenTelemetry의 GenAI 시맨틱 규약을 따릅니다. gen_ai.request.model, gen_ai.usage.input_tokens 같은 공통 이름 모음이며, 덕분에 Collector는 같은 스팬을 LLM 디버깅용으로 Langfuse나 Arize Phoenix에, 나머지 스택용으로 Grafana나 Datadog에 보낼 수 있습니다.
코어 저장소에는 프레임워크와 소수의 컴포넌트가 있고, receiver, processor, exporter 대부분은 opentelemetry-collector-contrib에 있습니다. 둘 다 Apache 2.0의 CNCF 프로젝트입니다. 공식 배포판은 다섯 가지로 코어, contrib, Kubernetes 빌드 등이 있으며, Collector Builder(ocb)로 필요한 컴포넌트만 넣은 자체 빌드를 만들 수 있습니다.
OpenTelemetry Collector, 쓸 만한 가치가 있습니까?
Collector는 에이전트 시스템의 트레이싱을 이식 가능하게 유지해 줍니다. OpenTelemetry로 한 번 계측하고 모든 서비스가 Collector를 바라보게 하면, 트레이스를 Langfuse, Phoenix, Datadog 중 어디로, 혹은 셋 모두로 보낼지는 코드가 아니라 YAML 변경으로 정해집니다. 관측성 분야에서 이만큼 널리 쓰이는 것은 없습니다. 코어 저장소의 GitHub 스타는 약 7,700개, contrib는 약 5,000개이며, 릴리스는 몇 주마다 나오고 버전 0.165.0이 2026년 11월 6일에 나왔습니다.
LLM 백엔드가 할 수 없는 일도 합니다. redaction이나 transform processor는 프롬프트 속성에서 고객 데이터를 네트워크 밖으로 나가기 전에 지울 수 있습니다. GenAI 규약은 입력과 출력 메시지 전체를 스팬 속성에 넣고 개인정보가 포함될 수 있다고 경고하므로 이 점이 중요합니다. 샘플링은 비용을 줄입니다. 말이 많은 에이전트의 트레이스를 모두 보관하면 비싸지만, tail sampling은 느리거나 실패한 것만 남길 수 있습니다. Langfuse 문서도 Collector가 OTLP를 gRPC로 받아 HTTP로 전달하는 예를 보여 주는데, Langfuse가 아직 gRPC를 받지 않기 때문입니다.
GenAI 계층은 아직 변하고 있습니다. GenAI 규약 중 Stable에 이른 것은 없고, 2026년에 별도 저장소로 옮겨졌으며, 속성 이름도 이미 바뀌었습니다(gen_ai.system이 gen_ai.provider.name이 됨). 백엔드는 사양을 뒤따라가는 중이어서 Langfuse는 여전히 폐기된 gen_ai.prompt와 gen_ai.completion을 매핑합니다. 계측 버전을 고정하고 백엔드가 무엇을 읽는지 확인하는 것도 일의 일부입니다. 필터링에도 주의가 필요합니다. Langfuse는 트레이스의 루트 스팬이 있어야 하며, 이를 버리면 트레이스가 불완전해집니다.
나머지는 버전 번호가 솔직하게 말해 줍니다. 바이너리는 아직 0.x이고, 안정성은 컴포넌트마다 다르며, 호환되지 않는 변경이 릴리스 노트에 실립니다. 0.165.0에서는 폐기된 HTTP 설정 네 개가 제거되었습니다. 보안 위험은 대부분 contrib에 있으며, 2026년 권고에는 Azure 인증 확장의 인증 우회와 설정된 인증을 무시하던 GitHub receiver가 포함됩니다. 에이전트 서비스 하나와 백엔드 하나뿐인 팀은 얻을 것이 적습니다. 문서도 작은 구성에서는 직접 보내도 된다고 합니다. 쓸모는 두 번째 서비스나 두 번째 목적지부터 생깁니다.
제 역할을 하는 곳
서비스 여섯 개에 걸친 지원 에이전트를 운영하는 핀테크의 플랫폼 팀
느린 답변을 처음부터 끝까지 추적하면서 계좌번호가 트레이스 저장소에 남지 않게 하기
각 서비스가 OTLP를 Collector 게이트웨이로 보내고, redaction processor가 gen_ai.input.messages 안의 계좌번호 패턴을 가린 뒤 셀프 호스팅 Langfuse로 내보냅니다. Collector 자체 비용은 실행 중인 파드뿐입니다.
수집한 스팬 단위로 Datadog에 비용을 내는 유통업체의 SRE
에이전트의 모든 단계에 돈을 내지 않으면서 LLM 디버깅용 세부 정 보 유지하기
AI 팀을 위해 모든 스팬은 Phoenix나 Langfuse로 보내고, Datadog에는 tail sampling으로 고른 느리거나 실패한 트레이스만 보냅니다. tail sampling은 한 트레이스의 모든 스팬이 같은 Collector에 모여야 하므로 로드 밸런싱 계층을 먼저 둡니다.
LLM 관측성 벤더를 고르는 15명 규모 스타트업의 CTO
처음 고른 트레이싱 도구에 묶이지 않기
처음부터 OpenTelemetry로 계측하고 Collector를 거치게 합니다. 두 번째 백엔드를 시험하려면 exporter 하나를 추가하고 한 달 동안 둘을 나란히 돌리면 되며, SDK를 바꿀 필요가 없습니다.
도입 전 확인할 점
- 설정
- otelcol-contrib Docker 이미지나 바이너리를 receiver, processor, exporter를 나열한 YAML 설정으로 실행합니다. Langfuse는 전달용 예시 설정을 바로 쓸 수 있게 공개합니다. Kubernetes용 전용 배포판이 있고, ocb로 군살을 뺀 바이너리를 만들 수 있습니다.
- 연동
- 입력은 gRPC와 HTTP OTLP이며, contrib를 통해 대부분의 관측성 백엔드용 exporter가 있습니다. Langfuse는 /api/public/otel에서 HTTP OTLP만 받습니다. Phoenix와 OpenLLMetry는 OpenTelemetry 스팬을 내보내고 읽습니다.
- 데이터와 개인정보
- 셀프 호스팅입니다. 따로 설정하지 않으면 메모리 버퍼 외에는 아무것도 저장하지 않으며, 지정한 exporter에만 데이터를 보냅니다. GenAI 스팬에는 프롬프트와 출력 전문이 담길 수 있으므로 마스킹은 여기서 해야 합니다. Apache 2.0입니다. 보안 권고는 코어 저장소에 2건, contrib에는 2026년에 여러 건이 있습니다.
- 대규모 사용 시 비용
- 라이선스도 유료 에디션도 없습니다. 비용은 에이전트나 게이트웨이로 돌리는 Collector의 컴퓨팅과 백엔드의 수집 요금입니다. LLM 워크로드용 용량 산정 수치는 공개되어 있지 않습니다.
- 제한
- 0.x 릴리스에는 호환되지 않는 변경이 있습니다. GenAI 규약은 Development 상태입니다. tail sampling에는 로드 밸런싱 계층이 필요합니다. 루트 스팬을 버리면 Langfuse에서 트레이스가 깨집니다. 열린 이슈와 풀 리퀘스트는 코어 약 690건, contrib 1,060건입니다.
좋은 점
- 벤더 중립이라 애플리케이션 코드를 건드리지 않고 백엔드를 바꾸거나 추가 가능
- 데이터가 네트워크를 떠나기 전에 마스킹, 필터링, tail sampling 가능
- 프로토콜을 이어 줌, 예컨대 gRPC로 받고 HTTP로 Langfuse에 전송
- ocb로 만든 자체 빌드로 바이너리를 작게 유지
아쉬운 점
- 아직 0.x이며 릴리스 노트에 호환되지 않는 변경이 있음
- GenAI 규약은 아직 Stable이 아니고 이름 변경이 계속됨
- contrib 컴포넌트는 성숙도가 제각각이고 권고 대부분을 차지함
- 운영하고 용량을 잡고 모니터링해야 할 서비스가 하나 더 늘어남
추천 대상
서비스가 여럿이거나 텔레메트리 백엔드가 둘 이상이면서, 코드를 바꾸지 않고 LLM 트레이스를 마스킹하고 샘플링하고 다시 라우팅하려는 에이전트 팀.
OpenTelemetry Collector 대안
OpenTelemetry Collector: 자주 묻는 질문
- OpenTelemetry Collector, 쓸 만한 가치가 있습니까?
- 서비스나 백엔드가 둘 이상 얽히는 순간부터 에이전트 트레이스를 모으고 정리하고 보내는 표준 자리이며, 그 전까지는 움직이는 부품 하나가 더 늘 뿐입니다. 평점은 5점 만점에 4.4점입니다.
- OpenTelemetry Collector의 가격은 얼마입니까?
- Apache 2.0의 무료 오픈소스이며 프로젝트가 제공하는 유료 에디션은 없습니다. 비용은 실행하는 머신과 데이터를 보내는 백엔드에서 생기며, 상용 배포판은 관측성 벤더가 제공합니다.
- OpenTelemetry Collector의 단점은 무엇입니까?
- 아직 0.x이며 릴리스 노트에 호환되지 않는 변경이 있음; GenAI 규약은 아직 Stable이 아니고 이름 변경이 계속됨; contrib 컴포넌트는 성숙도가 제각각이고 권고 대부분을 차지함; 운영하고 용량을 잡고 모니터링해야 할 서비스가 하나 더 늘어남.
- OpenTelemetry Collector에 적합한 사람은 누구입니까?
- 서비스가 여럿이거나 텔레메트리 백엔드가 둘 이상이면서, 코드를 바꾸지 않고 LLM 트레이스를 마스킹하고 샘플링하고 다시 라우팅하려는 에이전트 팀.
- 팀이나 프로덕션 환경에서 OpenTelemetry Collector의 비용은 얼마입니까?
- 라이선스도 유료 에디션도 없습니다. 비용은 에이전트나 게이트웨이로 돌리는 Collector의 컴퓨팅과 백엔드의 수집 요금입니다. LLM 워크로드용 용량 산정 수치는 공개되어 있지 않습니다.
- OpenTelemetry Collector에 회사 데이터를 맡겨도 안전합니까?
- 셀프 호스팅입니다. 따로 설정하지 않으면 메모리 버퍼 외에는 아무것도 저장하지 않으며, 지정한 exporter에만 데이터를 보냅니다. GenAI 스팬에는 프롬프트와 출력 전문이 담길 수 있으므로 마스킹은 여기서 해야 합니다. Apache 2.0입니다. 보안 권고는 코어 저장소에 2건, contrib에는 2026년에 여러 건이 있습니다.
- OpenTelemetry Collector의 가장 좋은 대안은 무엇입니까?
- 저희가 리뷰한 것 중 가장 가까운 대안은 OpenLLMetry입니다.
답변 확인일: 2026년 11월 9일.
OpenTelemetry Collector 개발사입니까? 이 평점을 사이트에 표시하십시오
