Lessons from Building an OTel Normalizer for GenAI

개요

groundcover에서 GenAI SDK, 프레임워크, 프로바이더에 구애받지 않는 AI Observability 솔루션을 구축하며 겪은 OpenTelemetry (OTel) 정규화 경험을 공유합니다.

주요 내용

* OTel의 GenAI 표준화 현실: GenAI 분야에서 OpenTelemetry 표준화가 예상만큼 통일되어 있지 않으며, 실제로는 네이밍 충돌, 구조적 불일치, 프로바이더별 고유 quirks 등 복잡성이 존재합니다.
* telemetry 수집 경로:
* SDK 계측: 고객이 OTel 호환 GenAI SDK (Traceloop, LangSmith, 공식 OTel 계측 등)를 사용하여 애플리케이션을 계측하고 OTLP를 통해 스팬을 전송합니다.
* eBPF: 커널 레벨 센서가 LLM 프로바이더 (OpenAI, Anthropic, Bedrock 등)로의 HTTP 호출을 가로채 원시 API 요청/응답에서 GenAI 시맨틱을 재구성합니다.
* telemetry 정규화 복잡성: telemetry는 다음 세 가지 독립적인 축에 따라 복잡성이 발생합니다.
* 계측 SDK: 각 SDK는 서로 다른 속성 이름, 메시지 형식, 토큰 필드 명명 규칙을 사용합니다. (Traceloop, LangSmith, 공식 OTel, 수동 속성 등)
* 오케스트레이션 프레임워크: 에이전트 워크플로우 구조에 따라 스팬 트리 모양, 메타데이터 포함 여부, 메시지 내용 직렬화 방식이 달라집니다. (LangGraph, CrewAI, Pydantic AI, AutoGen, Semantic Kernel 등)
* LLM 프로바이더: 각 프로바이더는 고유한 API 형식, 토큰 의미론 (캐시 포함 여부), 메시지 구조, 도구 호출 형식, 완료 이유 어휘를 가집니다. (OpenAI, Anthropic, Bedrock, Gemini, Groq, Mistral 등)
* 네 가지 스팬 형식: 모든 GenAI 스팬은 네 가지 기본 형식 중 하나로 수신되며, 각 형식은 자체 추출 논리, 메시지 파서, 후처리 단계를 거칩니다.
* 정규화의 실제 사례:
* 모델 식별: gen_ai.request.model, LangChain 메시지 JSON의 비용 메타데이터, llm.request.model, traceloop.association.properties.ls_model_name 등 다양한 경로로 모델 정보를 식별합니다.
* 토큰 수 계산: "input tokens", "prompt\_tokens", "completion\_tokens" 등 다섯 가지 명명 규칙을 표준화된 방식으로 처리합니다.
* 비용 계산: Anthropic, OpenAI 등 프로바이더별 "input tokens"의 의미론적 차이 (캐시 토큰 포함 여부)를 인지하여 정확한 비용 계산을 수행합니다.
* 프로바이더 식별: 26가지 다양한 문자열 (대소문자, 약어, 대체 이름 포함)을 15가지 표준화된 프로바이더 이름으로 매핑합니다. (LiteLLM, Portkey, OpenRouter 등 AI 게이트웨이 및 프록시로 인한 새로운 호스트도 포함)

시사점

OTel 지원이 항상 통합되고 정확한 telemetry를 의미하는 것은 아니며, groundcover의 정규화 솔루션은 복잡성을 흡수하여 SRE가 근본 원인 분석에 집중할 수 있도록 지원합니다.