셀프 호스팅 모델의 로그

요약

GitLab 17.6에서 GitLab Self-Managed에서 활성화됨. GitLab 17.6 이후 GitLab Duo 애드온이 필요하도록 변경됨. GitLab 17.8에서 기능 플래그 ai_custom_model 제거됨.

히스토리

GitLab 17.1에서 ai_custom_model이라는 플래그와 함께 도입됨. 기본적으로 비활성화됨.

GitLab 17.6에서 GitLab Self-Managed에서 활성화됨.
GitLab 17.6 이후 GitLab Duo 애드온이 필요하도록 변경됨.
GitLab 17.8에서 기능 플래그 ai_custom_model 제거됨.
GitLab 17.9에서 일반적으로 사용 가능해짐.
GitLab 17.9에서 UI를 통해 로깅을 켜고 끄는 기능이 추가됨.
GitLab 18.0에서 Premium을 포함하도록 변경됨.
GitLab 18.5에서 GitLab Dedicated for Government에서 활성화됨.

상세한 로깅을 통해 셀프 호스팅 모델의 성능을 모니터링하고 문제를 효과적으로 디버깅할 수 있습니다.

GitLab Duo의 데이터 수집 활성화#

사전 요구 사항:

관리자여야 합니다.

GitLab Duo의 데이터 수집은 AI Gateway 구성에 따라 다릅니다.

셀프 호스팅 AI Gateway를 사용하는 GitLab Self-Managed#

데이터 수집을 활성화하면 상세한 AI 로그(프롬프트 및 응답)가 GitLab 인스턴스와 AI Gateway의 llm.log에 로컬로 저장됩니다. 데이터는 GitLab과 공유되지 않습니다.

데이터 수집을 활성화하려면:

오른쪽 상단에서 Admin을 선택합니다.
왼쪽 사이드바에서 GitLab Duo를 선택합니다.
Change configuration을 선택합니다.
Data collection 아래에서 Collect usage data를 선택합니다.
Save changes를 선택합니다.

GitLab 관리 AI Gateway를 사용하는 GitLab Self-Managed#

Collect usage data를 활성화하면 사용 데이터가 GitLab과 공유됩니다. 이 시나리오에서는 민감한 데이터를 보호하기 위해 GitLab 관리 AI Gateway의 확장 로깅이 활성화되지 않습니다.

데이터 수집을 활성화하려면:

오른쪽 상단에서 Admin을 선택합니다.
왼쪽 사이드바에서 GitLab Duo를 선택합니다.
Change configuration을 선택합니다.
Data collection 아래에서 Collect usage data를 선택합니다.
Save changes를 선택합니다.

GitLab 설치의 로그#

로깅 설정은 시스템 작동의 투명성을 유지하면서 민감한 정보를 보호하도록 설계되어 있으며, 다음 구성 요소로 이루어져 있습니다:

GitLab 인스턴스에 대한 요청을 캡처하는 로그.
로깅 제어.
llm.log 파일.

GitLab 인스턴스에 대한 요청을 캡처하는 로그#

application.json, production_json.log, production.log 파일 등의 로깅은 GitLab 인스턴스에 대한 요청을 캡처합니다:

필터링된 요청: 이 파일들에 요청을 로깅하되 민감한 데이터(예: 입력 파라미터)는 필터링됩니다. 즉, 요청 메타데이터(예: 요청 유형, 엔드포인트, 응답 상태)는 캡처되지만 실제 입력 데이터(예: 쿼리 파라미터, 변수, 콘텐츠)는 민감한 정보 노출을 방지하기 위해 로깅되지 않습니다.
예시 1: 코드 제안 완료 요청의 경우, 로그는 민감한 정보를 필터링하면서 요청 세부 사항을 캡처합니다:

{
  "method": "POST",
  "path": "/api/graphql",
  "controller": "GraphqlController",
  "action": "execute",
  "status": 500,
  "params": [
    {"key": "query", "value": "[FILTERED]"},
    {"key": "variables", "value": "[FILTERED]"},
    {"key": "operationName", "value": "chat"}
  ],
  "exception": {
    "class": "NoMethodError",
    "message": "undefined method `id` for {:skip=>true}:Hash"
  },
  "time": "2024-08-28T14:13:50.328Z"
}

보시다시피 오류 정보와 요청의 일반 구조는 로깅되지만, 민감한 입력 파라미터는 [FILTERED]로 표시됩니다.

예시 2: 코드 제안 완료 요청의 경우, 로그도 민감한 정보를 필터링하면서 요청 세부 사항을 캡처합니다:

{
  "method": "POST",
  "path": "/api/v4/code_suggestions/completions",
  "status": 200,
  "params": [
    {"key": "prompt_version", "value": 1},
    {"key": "current_file", "value": {"file_name": "/test.rb", "language_identifier": "ruby", "content_above_cursor": "[FILTERED]", "content_below_cursor": "[FILTERED]"}},
    {"key": "telemetry", "value": []}
  ],
  "time": "2024-10-15T06:51:09.004Z"
}

보시다시피 요청의 일반 구조는 로깅되지만, content_above_cursor 및 content_below_cursor와 같은 민감한 입력 파라미터는 [FILTERED]로 표시됩니다.

로깅 제어#

로그의 일부를 제어하려면 GitLab Duo 설정 페이지를 통해 데이터 수집을 켜고 끄면 됩니다. 데이터 수집을 끄면 특정 작업에 대한 로깅이 비활성화됩니다.

llm.log 파일#

셀프 호스팅 AI Gateway 구성에서 데이터 수집이 활성화되면 GitLab Self-Managed 인스턴스를 통해 발생하는 코드 생성 및 GitLab Duo Chat 이벤트가 llm.log 파일에 캡처됩니다. 로그 파일은 데이터 수집이 활성화되지 않은 경우에는 아무것도 캡처하지 않습니다.

코드 완성 로그는 AI Gateway에 캡처됩니다. 이 로그는 GitLab으로 전송되지 않으며, GitLab Self-Managed 인프라에서만 볼 수 있습니다.

AI Gateway 컨테이너의 로그#

AI Gateway 및 GitLab Duo Agent Platform에서 생성된 로그의 위치를 지정하려면 다음을 실행합니다:

docker run -e AIGW_GITLAB_URL=<your_gitlab_instance> \
 -e AIGW_GITLAB_API_URL=https://<your_gitlab_domain>/api/v4/ \
 -e DUO_WORKFLOW_SELF_SIGNED_JWT__SIGNING_KEY="your-signing-key" \
 -e AIGW_LOGGING__TO_FILE="aigateway.log" \
 -e DUO_WORKFLOW_LOGGING__TO_FILE="duo_agent_platform.log" \
 -v <your_aigateway_file_path>:aigateway.log \
 -v <your_duo_agent_platform_file_path>:duo_agent_platform.log \
 <image>

기본적으로 로깅 레벨은 INFO로 설정되어 있습니다. 로깅 레벨을 DEBUG로 변경하려면 다음을 실행합니다:

docker run -e AIGW_GITLAB_URL=<your_gitlab_instance> \
 -e AIGW_GITLAB_API_URL=https://<your_gitlab_domain>/api/v4/ \
 -e DUO_WORKFLOW_SELF_SIGNED_JWT__SIGNING_KEY="your-signing-key" \
 -e AIGW_LOGGING__TO_FILE="aigateway.log" \
 -e DUO_WORKFLOW_LOGGING__TO_FILE="duo_agent_platform.log" \
 -e AIGW_LOGGING__LEVEL="DEBUG" \
 -e DUO_WORKFLOW_LOGGING__LEVEL="DEBUG" \
 -v <your_aigateway_file_path>:aigateway.log \
 -v <your_duo_agent_platform_file_path>:duo_agent_platform.log \
 <image>

또한 litellm의 모든 디버그 문을 로깅하려면 다음 환경 변수를 추가합니다:

-e AIGW_LOGGING__ENABLE_LITELLM_LOGGING=true

파일 이름을 지정하지 않으면 로그가 출력으로 스트리밍되며 Docker 로그를 사용하여 관리할 수도 있습니다. 자세한 내용은 Docker Logs 문서를 참조하세요.

또한 AI Gateway 실행 출력을 사용하면 문제 디버깅에 도움이 됩니다. 출력에 접근하려면:

Docker를 사용하는 경우:

docker logs <container-id>

쿠버네티스를 사용하는 경우:

kubectl logs <container-name>

이 로그를 로깅 솔루션으로 수집하려면 로깅 공급자 문서를 참조하세요.

로그 구조#

POST 요청이 이루어지면(예: /chat/completions 엔드포인트), 서버는 다음을 로깅합니다:

페이로드
헤더
메타데이터

1. 요청 페이로드#

JSON 페이로드에는 일반적으로 다음 필드가 포함됩니다:

messages: 메시지 객체의 배열.

각 메시지 객체에는 다음이 포함됩니다:

content: 사용자의 입력 또는 쿼리를 나타내는 문자열.

role: 메시지 발신자의 역할을 나타냅니다(예: user).
model: 사용할 모델을 지정하는 문자열(예: mistral).
max_tokens: 응답에서 생성할 최대 토큰 수를 지정하는 정수.
n: 생성할 완성 수를 나타내는 정수.
stop: 생성된 텍스트의 중지 시퀀스를 나타내는 문자열 배열.
stream: 응답을 스트리밍할지 여부를 나타내는 불리언.
temperature: 출력의 무작위성을 제어하는 부동 소수점 값.

요청 예시#

{
    "messages": [
        {
            "content": "<s>[SUFFIX]None[PREFIX]# # build a hello world ruby method\n def say_goodbye\n    puts \"Goodbye, World!\"\n  end\n\ndef main\n  say_hello\n  say_goodbye\nend\n\nmain",
            "role": "user"
        }
    ],
    "model": "mistral",
    "max_tokens": 128,
    "n": 1,
    "stop": ["[INST]", "[/INST]", "[PREFIX]", "[MIDDLE]", "[SUFFIX]"],
    "stream": false,
    "temperature": 0.0
}

2. 요청 헤더#

요청 헤더는 요청을 보내는 클라이언트에 대한 추가 컨텍스트를 제공합니다. 주요 헤더에는 다음이 포함될 수 있습니다:

Authorization: API 접근을 위한 Bearer 토큰을 포함합니다.
Content-Type: 리소스의 미디어 유형을 나타냅니다(예: JSON).
User-Agent: 요청을 보내는 클라이언트 소프트웨어에 대한 정보.
X-Stainless- 헤더: 클라이언트 환경에 대한 추가 메타데이터를 제공하는 다양한 헤더.

요청 헤더 예시#

{
    "host": "0.0.0.0:4000",
    "accept-encoding": "gzip, deflate",
    "connection": "keep-alive",
    "accept": "application/json",
    "content-type": "application/json",
    "user-agent": "AsyncOpenAI/Python 1.51.0",
    "authorization": "Bearer ",
    "content-length": "364"
}

3. 요청 메타데이터#

메타데이터에는 요청의 컨텍스트를 설명하는 다양한 필드가 포함됩니다:

requester_metadata: 요청자에 대한 추가 메타데이터.
user_api_key: 요청에 사용된 API 키(익명화됨).
api_version: 사용 중인 API 버전.
request_timeout: 요청의 타임아웃 시간.
call_id: 호출에 대한 고유 식별자.

메타데이터 예시#

{
    "user_api_key": "",
    "api_version": "1.48.18",
    "request_timeout": 600,
    "call_id": "e1aaa316-221c-498c-96ce-5bc1e7cb63af"
}

응답 예시#

서버는 구조화된 모델 응답으로 응답합니다. 예를 들면:

Response: ModelResponse(
    id='chatcmpl-5d16ad41-c130-4e33-a71e-1c392741bcb9',
    choices=[
        Choices(
            finish_reason='stop',
            index=0,
            message=Message(
                content=' Here is the corrected Ruby code for your function:\n\n```ruby\ndef say_hello\n  puts "Hello, World!"\nend\n\ndef say_goodbye\n    puts "Goodbye, World!"\nend\n\ndef main\n  say_hello\n  say_goodbye\nend\n\nmain\n```\n\nIn your original code, the method names were misspelled as `say_hell` and `say_gobdye`. I corrected them to `say_hello` and `say_goodbye`. Also, there was no need for the prefix',
                role='assistant',
                tool_calls=None,
                function_call=None
            )
        )
    ],
    created=1728983827,
    model='mistral',
    object='chat.completion',
    system_fingerprint=None,
    usage=Usage(
        completion_tokens=128,
        prompt_tokens=69,
        total_tokens=197,
        completion_tokens_details=None,
        prompt_tokens_details=None
    )
)

추론 서비스 공급자의 로그#

GitLab은 추론 서비스 공급자가 생성한 로그를 관리하지 않습니다. 해당 공급자의 로그 사용 방법은 추론 서비스 공급자의 문서를 참조하세요.

GitLab 및 AI Gateway 환경에서의 로깅 동작#

GitLab은 llm.log를 사용하여 AI 관련 활동에 대한 로깅 기능을 제공하며, 입력, 출력 및 기타 관련 정보를 캡처합니다. 그러나 로깅 동작은 GitLab 인스턴스와 AI Gateway가 셀프 호스팅인지 클라우드 연결인지에 따라 다릅니다.

기본적으로 로그에는 AI 기능 데이터의 데이터 보존 정책을 지원하기 위해 LLM 프롬프트 입력과 응답 출력이 포함되지 않습니다.

로깅 시나리오#

GitLab Self-Managed와 셀프 호스팅 AI Gateway#

이 구성에서는 GitLab과 AI Gateway 모두 고객이 호스팅합니다.

로깅 동작: 전체 로깅이 활성화되며, 모든 프롬프트, 입력 및 출력이 인스턴스의 llm.log에 로깅됩니다.
Collect usage data가 활성화되면 다음을 포함한 추가 디버깅 정보가 로깅됩니다:

전처리된 프롬프트.

최종 프롬프트.
추가 컨텍스트.
개인 정보 보호: GitLab과 AI Gateway 모두 셀프 호스팅이므로:

고객이 데이터 처리를 완전히 제어합니다.

민감한 정보의 로깅을 고객의 재량에 따라 활성화하거나 비활성화할 수 있습니다.

AI 기능이 GitLab 관리 모델을 사용하는 경우, 데이터 수집이 활성화된 경우에도 GitLab 관리 AI Gateway에서 상세 로그가 생성되지 않습니다. 이는 민감한 정보가 의도치 않게 유출되는 것을 방지합니다.

GitLab Self-Managed와 GitLab 관리 AI Gateway (클라우드 연결)#

이 시나리오에서는 고객이 GitLab을 호스팅하지만 AI 처리를 위해 GitLab 관리 AI Gateway에 의존합니다.

로깅 동작: 클라우드 연결 AI Gateway를 사용할 때 GitLab이 AI 프롬프트 및 응답 데이터를 처리하는 방법에 대한 정보는 GitLab Duo 데이터 사용을 참조하세요.
확장 로깅: Collect usage data가 활성화된 경우에도 민감한 정보의 의도치 않은 유출을 방지하기 위해 GitLab 관리 AI Gateway에서 상세 로그가 생성되지 않습니다.

이 설정에서는 로깅이 최소화되며 확장 로깅 기능은 기본적으로 비활성화됩니다.

개인 정보 보호: 이 구성은 클라우드 환경에서 민감한 데이터가 로깅되지 않도록 보장하기 위해 설계되었습니다.

클라우드 연결 AI Gateway에서의 로깅#

클라우드 연결 AI Gateway를 사용할 때 GitLab이 AI 프롬프트 및 응답 데이터를 처리하는 방법에 대한 정보는 GitLab Duo 데이터 사용을 참조하세요.

AI Gateway와 GitLab 간의 로그 교차 참조#

correlation_id 속성은 모든 요청에 할당되며, 요청에 응답하는 다양한 구성 요소에 걸쳐 전달됩니다. 자세한 내용은 상관 ID로 로그 찾기 문서를 참조하세요.

상관 ID는 AI Gateway와 GitLab 로그에서 찾을 수 있습니다. 단, 모델 공급자 로그에는 없습니다.

셀프 호스팅 모델의 로그

GitLab v19.2

Tier: Premium, Ultimate
Offering: GitLab Self-Managed, GitLab Dedicated for Government

원문 보기

번역일: 2026-06-19

요약

GitLab 17.6에서 GitLab Self-Managed에서 활성화됨. GitLab 17.6 이후 GitLab Duo 애드온이 필요하도록 변경됨. GitLab 17.8에서 기능 플래그 ai_custom_model 제거됨.

히스토리

GitLab 17.1에서 ai_custom_model이라는 플래그와 함께 도입됨. 기본적으로 비활성화됨.

GitLab 17.6에서 GitLab Self-Managed에서 활성화됨.
GitLab 17.6 이후 GitLab Duo 애드온이 필요하도록 변경됨.
GitLab 17.8에서 기능 플래그 ai_custom_model 제거됨.
GitLab 17.9에서 일반적으로 사용 가능해짐.
GitLab 17.9에서 UI를 통해 로깅을 켜고 끄는 기능이 추가됨.
GitLab 18.0에서 Premium을 포함하도록 변경됨.
GitLab 18.5에서 GitLab Dedicated for Government에서 활성화됨.

상세한 로깅을 통해 셀프 호스팅 모델의 성능을 모니터링하고 문제를 효과적으로 디버깅할 수 있습니다.

GitLab Duo의 데이터 수집 활성화#

사전 요구 사항:

관리자여야 합니다.

GitLab Duo의 데이터 수집은 AI Gateway 구성에 따라 다릅니다.

셀프 호스팅 AI Gateway를 사용하는 GitLab Self-Managed#

데이터 수집을 활성화하려면:

오른쪽 상단에서 Admin을 선택합니다.
왼쪽 사이드바에서 GitLab Duo를 선택합니다.
Change configuration을 선택합니다.
Data collection 아래에서 Collect usage data를 선택합니다.
Save changes를 선택합니다.

GitLab 관리 AI Gateway를 사용하는 GitLab Self-Managed#

데이터 수집을 활성화하려면:

오른쪽 상단에서 Admin을 선택합니다.
왼쪽 사이드바에서 GitLab Duo를 선택합니다.
Change configuration을 선택합니다.
Data collection 아래에서 Collect usage data를 선택합니다.
Save changes를 선택합니다.

GitLab 설치의 로그#

로깅 설정은 시스템 작동의 투명성을 유지하면서 민감한 정보를 보호하도록 설계되어 있으며, 다음 구성 요소로 이루어져 있습니다:

GitLab 인스턴스에 대한 요청을 캡처하는 로그.
로깅 제어.
llm.log 파일.

GitLab 인스턴스에 대한 요청을 캡처하는 로그#

application.json, production_json.log, production.log 파일 등의 로깅은 GitLab 인스턴스에 대한 요청을 캡처합니다:

필터링된 요청: 이 파일들에 요청을 로깅하되 민감한 데이터(예: 입력 파라미터)는 필터링됩니다. 즉, 요청 메타데이터(예: 요청 유형, 엔드포인트, 응답 상태)는 캡처되지만 실제 입력 데이터(예: 쿼리 파라미터, 변수, 콘텐츠)는 민감한 정보 노출을 방지하기 위해 로깅되지 않습니다.
예시 1: 코드 제안 완료 요청의 경우, 로그는 민감한 정보를 필터링하면서 요청 세부 사항을 캡처합니다:

{
  "method": "POST",
  "path": "/api/graphql",
  "controller": "GraphqlController",
  "action": "execute",
  "status": 500,
  "params": [
    {"key": "query", "value": "[FILTERED]"},
    {"key": "variables", "value": "[FILTERED]"},
    {"key": "operationName", "value": "chat"}
  ],
  "exception": {
    "class": "NoMethodError",
    "message": "undefined method `id` for {:skip=>true}:Hash"
  },
  "time": "2024-08-28T14:13:50.328Z"
}

보시다시피 오류 정보와 요청의 일반 구조는 로깅되지만, 민감한 입력 파라미터는 [FILTERED]로 표시됩니다.

예시 2: 코드 제안 완료 요청의 경우, 로그도 민감한 정보를 필터링하면서 요청 세부 사항을 캡처합니다:

{
  "method": "POST",
  "path": "/api/v4/code_suggestions/completions",
  "status": 200,
  "params": [
    {"key": "prompt_version", "value": 1},
    {"key": "current_file", "value": {"file_name": "/test.rb", "language_identifier": "ruby", "content_above_cursor": "[FILTERED]", "content_below_cursor": "[FILTERED]"}},
    {"key": "telemetry", "value": []}
  ],
  "time": "2024-10-15T06:51:09.004Z"
}

보시다시피 요청의 일반 구조는 로깅되지만, content_above_cursor 및 content_below_cursor와 같은 민감한 입력 파라미터는 [FILTERED]로 표시됩니다.

로깅 제어#

llm.log 파일#

코드 완성 로그는 AI Gateway에 캡처됩니다. 이 로그는 GitLab으로 전송되지 않으며, GitLab Self-Managed 인프라에서만 볼 수 있습니다.

AI Gateway 컨테이너의 로그#

AI Gateway 및 GitLab Duo Agent Platform에서 생성된 로그의 위치를 지정하려면 다음을 실행합니다:

docker run -e AIGW_GITLAB_URL=<your_gitlab_instance> \
 -e AIGW_GITLAB_API_URL=https://<your_gitlab_domain>/api/v4/ \
 -e DUO_WORKFLOW_SELF_SIGNED_JWT__SIGNING_KEY="your-signing-key" \
 -e AIGW_LOGGING__TO_FILE="aigateway.log" \
 -e DUO_WORKFLOW_LOGGING__TO_FILE="duo_agent_platform.log" \
 -v <your_aigateway_file_path>:aigateway.log \
 -v <your_duo_agent_platform_file_path>:duo_agent_platform.log \
 <image>

기본적으로 로깅 레벨은 INFO로 설정되어 있습니다. 로깅 레벨을 DEBUG로 변경하려면 다음을 실행합니다:

docker run -e AIGW_GITLAB_URL=<your_gitlab_instance> \
 -e AIGW_GITLAB_API_URL=https://<your_gitlab_domain>/api/v4/ \
 -e DUO_WORKFLOW_SELF_SIGNED_JWT__SIGNING_KEY="your-signing-key" \
 -e AIGW_LOGGING__TO_FILE="aigateway.log" \
 -e DUO_WORKFLOW_LOGGING__TO_FILE="duo_agent_platform.log" \
 -e AIGW_LOGGING__LEVEL="DEBUG" \
 -e DUO_WORKFLOW_LOGGING__LEVEL="DEBUG" \
 -v <your_aigateway_file_path>:aigateway.log \
 -v <your_duo_agent_platform_file_path>:duo_agent_platform.log \
 <image>

또한 litellm의 모든 디버그 문을 로깅하려면 다음 환경 변수를 추가합니다:

-e AIGW_LOGGING__ENABLE_LITELLM_LOGGING=true

파일 이름을 지정하지 않으면 로그가 출력으로 스트리밍되며 Docker 로그를 사용하여 관리할 수도 있습니다. 자세한 내용은 Docker Logs 문서를 참조하세요.

또한 AI Gateway 실행 출력을 사용하면 문제 디버깅에 도움이 됩니다. 출력에 접근하려면:

Docker를 사용하는 경우:

docker logs <container-id>

쿠버네티스를 사용하는 경우:

kubectl logs <container-name>

이 로그를 로깅 솔루션으로 수집하려면 로깅 공급자 문서를 참조하세요.

로그 구조#

POST 요청이 이루어지면(예: /chat/completions 엔드포인트), 서버는 다음을 로깅합니다:

페이로드
헤더
메타데이터

1. 요청 페이로드#

JSON 페이로드에는 일반적으로 다음 필드가 포함됩니다:

messages: 메시지 객체의 배열.

각 메시지 객체에는 다음이 포함됩니다:

content: 사용자의 입력 또는 쿼리를 나타내는 문자열.

role: 메시지 발신자의 역할을 나타냅니다(예: user).
model: 사용할 모델을 지정하는 문자열(예: mistral).
max_tokens: 응답에서 생성할 최대 토큰 수를 지정하는 정수.
n: 생성할 완성 수를 나타내는 정수.
stop: 생성된 텍스트의 중지 시퀀스를 나타내는 문자열 배열.
stream: 응답을 스트리밍할지 여부를 나타내는 불리언.
temperature: 출력의 무작위성을 제어하는 부동 소수점 값.

요청 예시#

{
    "messages": [
        {
            "content": "<s>[SUFFIX]None[PREFIX]# # build a hello world ruby method\n def say_goodbye\n    puts \"Goodbye, World!\"\n  end\n\ndef main\n  say_hello\n  say_goodbye\nend\n\nmain",
            "role": "user"
        }
    ],
    "model": "mistral",
    "max_tokens": 128,
    "n": 1,
    "stop": ["[INST]", "[/INST]", "[PREFIX]", "[MIDDLE]", "[SUFFIX]"],
    "stream": false,
    "temperature": 0.0
}

2. 요청 헤더#

요청 헤더는 요청을 보내는 클라이언트에 대한 추가 컨텍스트를 제공합니다. 주요 헤더에는 다음이 포함될 수 있습니다:

Authorization: API 접근을 위한 Bearer 토큰을 포함합니다.
Content-Type: 리소스의 미디어 유형을 나타냅니다(예: JSON).
User-Agent: 요청을 보내는 클라이언트 소프트웨어에 대한 정보.
X-Stainless- 헤더: 클라이언트 환경에 대한 추가 메타데이터를 제공하는 다양한 헤더.

요청 헤더 예시#

{
    "host": "0.0.0.0:4000",
    "accept-encoding": "gzip, deflate",
    "connection": "keep-alive",
    "accept": "application/json",
    "content-type": "application/json",
    "user-agent": "AsyncOpenAI/Python 1.51.0",
    "authorization": "Bearer ",
    "content-length": "364"
}

3. 요청 메타데이터#

메타데이터에는 요청의 컨텍스트를 설명하는 다양한 필드가 포함됩니다:

requester_metadata: 요청자에 대한 추가 메타데이터.
user_api_key: 요청에 사용된 API 키(익명화됨).
api_version: 사용 중인 API 버전.
request_timeout: 요청의 타임아웃 시간.
call_id: 호출에 대한 고유 식별자.

메타데이터 예시#

{
    "user_api_key": "",
    "api_version": "1.48.18",
    "request_timeout": 600,
    "call_id": "e1aaa316-221c-498c-96ce-5bc1e7cb63af"
}

응답 예시#

서버는 구조화된 모델 응답으로 응답합니다. 예를 들면:

Response: ModelResponse(
    id='chatcmpl-5d16ad41-c130-4e33-a71e-1c392741bcb9',
    choices=[
        Choices(
            finish_reason='stop',
            index=0,
            message=Message(
                content=' Here is the corrected Ruby code for your function:\n\n```ruby\ndef say_hello\n  puts "Hello, World!"\nend\n\ndef say_goodbye\n    puts "Goodbye, World!"\nend\n\ndef main\n  say_hello\n  say_goodbye\nend\n\nmain\n```\n\nIn your original code, the method names were misspelled as `say_hell` and `say_gobdye`. I corrected them to `say_hello` and `say_goodbye`. Also, there was no need for the prefix',
                role='assistant',
                tool_calls=None,
                function_call=None
            )
        )
    ],
    created=1728983827,
    model='mistral',
    object='chat.completion',
    system_fingerprint=None,
    usage=Usage(
        completion_tokens=128,
        prompt_tokens=69,
        total_tokens=197,
        completion_tokens_details=None,
        prompt_tokens_details=None
    )
)

추론 서비스 공급자의 로그#

GitLab은 추론 서비스 공급자가 생성한 로그를 관리하지 않습니다. 해당 공급자의 로그 사용 방법은 추론 서비스 공급자의 문서를 참조하세요.

GitLab 및 AI Gateway 환경에서의 로깅 동작#

기본적으로 로그에는 AI 기능 데이터의 데이터 보존 정책을 지원하기 위해 LLM 프롬프트 입력과 응답 출력이 포함되지 않습니다.

로깅 시나리오#

GitLab Self-Managed와 셀프 호스팅 AI Gateway#

이 구성에서는 GitLab과 AI Gateway 모두 고객이 호스팅합니다.

로깅 동작: 전체 로깅이 활성화되며, 모든 프롬프트, 입력 및 출력이 인스턴스의 llm.log에 로깅됩니다.
Collect usage data가 활성화되면 다음을 포함한 추가 디버깅 정보가 로깅됩니다:

전처리된 프롬프트.

최종 프롬프트.
추가 컨텍스트.
개인 정보 보호: GitLab과 AI Gateway 모두 셀프 호스팅이므로:

고객이 데이터 처리를 완전히 제어합니다.

민감한 정보의 로깅을 고객의 재량에 따라 활성화하거나 비활성화할 수 있습니다.

AI 기능이 GitLab 관리 모델을 사용하는 경우, 데이터 수집이 활성화된 경우에도 GitLab 관리 AI Gateway에서 상세 로그가 생성되지 않습니다. 이는 민감한 정보가 의도치 않게 유출되는 것을 방지합니다.

GitLab Self-Managed와 GitLab 관리 AI Gateway (클라우드 연결)#

이 시나리오에서는 고객이 GitLab을 호스팅하지만 AI 처리를 위해 GitLab 관리 AI Gateway에 의존합니다.

로깅 동작: 클라우드 연결 AI Gateway를 사용할 때 GitLab이 AI 프롬프트 및 응답 데이터를 처리하는 방법에 대한 정보는 GitLab Duo 데이터 사용을 참조하세요.
확장 로깅: Collect usage data가 활성화된 경우에도 민감한 정보의 의도치 않은 유출을 방지하기 위해 GitLab 관리 AI Gateway에서 상세 로그가 생성되지 않습니다.

이 설정에서는 로깅이 최소화되며 확장 로깅 기능은 기본적으로 비활성화됩니다.

개인 정보 보호: 이 구성은 클라우드 환경에서 민감한 데이터가 로깅되지 않도록 보장하기 위해 설계되었습니다.

클라우드 연결 AI Gateway에서의 로깅#

클라우드 연결 AI Gateway를 사용할 때 GitLab이 AI 프롬프트 및 응답 데이터를 처리하는 방법에 대한 정보는 GitLab Duo 데이터 사용을 참조하세요.

AI Gateway와 GitLab 간의 로그 교차 참조#

상관 ID는 AI Gateway와 GitLab 로그에서 찾을 수 있습니다. 단, 모델 공급자 로그에는 없습니다.

셀프 호스팅 모델의 로그

GitLab Duo의 데이터 수집 활성화#

셀프 호스팅 AI Gateway를 사용하는 GitLab Self-Managed#

GitLab 관리 AI Gateway를 사용하는 GitLab Self-Managed#

GitLab 설치의 로그#

GitLab 인스턴스에 대한 요청을 캡처하는 로그#

로깅 제어#

llm.log 파일#

AI Gateway 컨테이너의 로그#

로그 구조#

1. 요청 페이로드#

요청 예시#

2. 요청 헤더#

요청 헤더 예시#

3. 요청 메타데이터#

메타데이터 예시#

응답 예시#

추론 서비스 공급자의 로그#

GitLab 및 AI Gateway 환경에서의 로깅 동작#

로깅 시나리오#

GitLab Self-Managed와 셀프 호스팅 AI Gateway#

GitLab Self-Managed와 GitLab 관리 AI Gateway (클라우드 연결)#

클라우드 연결 AI Gateway에서의 로깅#

AI Gateway와 GitLab 간의 로그 교차 참조#

관련 항목#

셀프 호스팅 모델의 로그

GitLab Duo의 데이터 수집 활성화#

셀프 호스팅 AI Gateway를 사용하는 GitLab Self-Managed#

GitLab 관리 AI Gateway를 사용하는 GitLab Self-Managed#

GitLab 설치의 로그#

GitLab 인스턴스에 대한 요청을 캡처하는 로그#

로깅 제어#

llm.log 파일#

AI Gateway 컨테이너의 로그#

로그 구조#

1. 요청 페이로드#

요청 예시#

2. 요청 헤더#

요청 헤더 예시#

3. 요청 메타데이터#

메타데이터 예시#

응답 예시#

추론 서비스 공급자의 로그#

GitLab 및 AI Gateway 환경에서의 로깅 동작#

로깅 시나리오#

GitLab Self-Managed와 셀프 호스팅 AI Gateway#

GitLab Self-Managed와 GitLab 관리 AI Gateway (클라우드 연결)#

클라우드 연결 AI Gateway에서의 로깅#

AI Gateway와 GitLab 간의 로그 교차 참조#

관련 항목#