프록시 로깅 (Proxy Logging)

LiteLLM 프록시가 주고받는 입력·출력·예외를 각종 로깅 시스템으로 흘려보내는 방법을 다루는 가이드예요. 프록시를 운영하다 보면 "어떤 요청이 어디로 갔는지, 얼마를 썼는지, 에러가 왜 났는지"를 뒤에서 남겨야 할 때가 생기는데요, 이 장은 그 로깅 파이프라인을 여는 출발점이 되어 줍니다. 로깅 대상 시스템은 Langfuse, OpenTelemetry, GCS·S3·Azure Blob 버킷, AWS SQS, Lunary, MLflow, LangSmith, DataDog, Azure Sentinel, DynamoDB까지 다양해요. 아래에서 프록시 로깅의 핵심 개념과 설정 흐름을 순서대로 짚어볼게요.

출처: 공식문서

LiteLLM Call ID 받아오기

LiteLLM은 요청마다 고유한 call_id를 생성해요. 이 call_id 하나로 요청이 시스템을 가로질러 이동한 경로를 추적할 수 있죠. 그래서 위에서 소개한 로깅 시스템 어딘가에서 특정 요청의 정보를 찾아야 할 때 가장 유용한 열쇠가 됩니다.

curl -i -sSL --location 'http://0.0.0.0:4000/chat/completions' \
    --header 'Authorization: Bearer ***' \
    --header 'Content-Type: application/json' \
    --data '{
      "model": "{{openai_small}}",
      "messages": [{"role": "user", "content": "what llm are you"}]
    }' | grep 'x-litellm'

위 요청의 응답 헤더는 대략 이렇게 나와요.

x-litellm-call-id: b980db26-9512-45cc-b1da-c511a363b83f
x-litellm-model-id: cb41bc03f4c33d310019bae8c5afdb1af0a8f97b36a234405a9807614988457c
x-litellm-model-api-base: https://x-example-1234.openai.azure.com
x-litellm-version: 1.40.21
x-litellm-response-cost: 2.85e-05
x-litellm-key-tpm-limit: None
x-litellm-key-rpm-limit: None

이 헤더들 중 여러 개가 문제 해결에 도움이 되지만, 시스템의 여러 컴포넌트(로깅 도구 포함)를 가로질러 요청을 추적할 때 가장 중요한 건 x-litellm-call-id예요.

메시지·응답 내용 가리기 (Redact)

민감한 데이터를 다룰 때는 프라이버시·컴플라이언스를 위해 입력 메시지와 응답 내용을 로깅에서 제외하고 싶을 수 있어요. 이때 litellm.turn_off_message_logging=True를 설정하면 메시지와 응답은 로깅 프로바이더로 전송되지 않지만, 지출(spend) 같은 요청 메타데이터는 계속 추적돼요.

1. config.yaml 설정

model_list:
  - model_name: {{openai_small}}
    litellm_params:
      model: {{openai_small}}
litellm_settings:
  success_callback: ["langfuse"]
  turn_off_message_logging: True # 👈 Key Change

2. 요청 전송

curl --location 'http://0.0.0.0:4000/chat/completions' \
    --header 'Content-Type: application/json' \
    --data '{
    "model": "{{openai_small}}",
    "messages": [
        {
        "role": "user",
        "content": "what llm are you"
        }
    ]
}'

요청 단위로만 가리고 싶다면(동적, BETA) 요청 헤더에 x-litellm-enable-message-redaction: true를 넣으면 돼요. 해당 요청의 메시지·응답만 로깅에서 제외됩니다.

모든 로깅 끄기

프라이버시가 아주 중요한 상황이라 로깅 자체를 완전히 끄고 싶다면 general_settings에서 모든 추적을 비활성화할 수 있어요. disable_spend_logs: True는 지출 로그를, disable_error_logs: True는 에러 로그를 DB에 쓰지 않게 막아요. 다만 이때도 일반적인 접근 로그(spend logs)는 disable_spend_logs를 켜지 않는 한 계속 기록된다는 점을 기억하세요.

특정 콜백 비활성화 / 조건부 로깅

프록시는 가상 키·팀에 따라 로깅 대상을 다르게 걸 수도 있어요. 예컨대 특정 팀이나 키에만 로깅을 붙이고 싶을 때 litellm_settings.callbacks로 전역 콜백을 설정해 두고, 조건부 규칙으로 특정 키·팀에게만 적용 범위를 좁히는 식이죠. 동적 로깅(dynamic logging)을 쓰면 실행 중에 콜백을 켜고 끌 수도 있어요.

Langfuse로 로깅 시작하기

litellm_settings에 success_callback: ["langfuse"]를 넣으면 성공한 LLM 호출이 전부 Langfuse로 기록돼요. 환경 변수로 LANGFUSE_PUBLIC_KEY와 LANGFUSE_SECRET_KEY를 챙겨 주는 걸 잊지 마세요.

litellm --config /path/to/config.yaml

litellm_settings:
  success_callback: ["langfuse"]

export LANGFUSE_PUBLIC_KEY="pk_kk"
export LANGFUSE_SECRET_KEY="sk_kk"

더 알아보기

커스텀 콜백으로 직접 로직을 짜려면 커스텀 콜백 가이드를 봐요.
Langfuse 상세 설정은 Langfuse 연동 문서에 있어요.
OpenTelemetry로 표준 트레이싱에 연결하고 싶으면 Observability → OpenTelemetry 통합 문서를 참고하세요.