셀프 호스팅 모델의 로그

요약

상세 로깅으로 셀프 호스팅 모델 성능을 모니터링하고 문제를 더 효과적으로 디버깅하세요. GitLab Duo의 데이터 수집은 AI Gateway 구성에 따라 다릅니다. 데이터 수집을 활성화하면 상세 AI 로그(프롬프트 및 응답)가 GitLab 인스턴스와 AI Gateway의 llm.log에 로컬로 저장됩니다.

히스토리

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 Duo의 데이터 수집 활성화#

사전 요구 사항:

관리자여야 합니다.

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

자체 호스팅 AI Gateway가 있는 GitLab Self-Managed#

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

데이터 수집을 켜려면:

오른쪽 상단에서 관리자를 선택하세요.
왼쪽 사이드바에서 GitLab Duo를 선택하세요.
구성 변경을 선택하세요.
데이터 수집 아래에서 사용 데이터 수집을 선택하세요.
변경 사항 저장을 선택하세요.

GitLab 관리 AI Gateway가 있는 GitLab Self-Managed#

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

데이터 수집을 켜려면:

오른쪽 상단에서 관리자를 선택합니다.
왼쪽 사이드바에서 GitLab Duo를 선택합니다.
구성 변경을 선택합니다.
데이터 수집 아래에서 사용 데이터 수집을 선택합니다.
변경 사항 저장을 선택합니다.

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 게이트웨이 컨테이너의 로그#

AI 게이트웨이 및 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 로그 문서를 참조하세요.

또한 AI 게이트웨이 실행의 출력은 문제 디버깅에 도움이 될 수 있습니다. 접근 방법:

Docker 사용 시:
```
docker logs <container-id>
```
Kubernetes 사용 시:
```
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 게이트웨이 환경에서의 로깅 동작#

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

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

로깅 시나리오#

GitLab Self-Managed 및 셀프 호스팅 AI 게이트웨이#

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

로깅 동작: 전체 로깅이 활성화되고 모든 프롬프트, 입력 및 출력이 인스턴스의 llm.log에 로깅됩니다.
사용 데이터 수집이 활성화되면 다음을 포함한 추가 디버깅 정보가 로깅됩니다:
- 전처리된 프롬프트.
- 최종 프롬프트.
- 추가 컨텍스트.
개인 정보 보호: GitLab과 AI 게이트웨이 모두 셀프 호스팅이므로:
- 고객이 데이터 처리를 완전히 제어합니다.
- 민감한 정보의 로깅을 고객의 재량으로 활성화하거나 비활성화할 수 있습니다.
[!note] AI 기능이 GitLab 관리 모델을 사용할 때 사용 데이터 수집이 활성화된 경우에도 GitLab 관리 AI 게이트웨이에서는 상세 로그가 생성되지 않습니다. 이는 민감한 정보의 의도하지 않은 유출을 방지합니다.

GitLab Self-Managed 및 GitLab 관리 AI 게이트웨이(클라우드 연결)#

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

로깅 동작: 클라우드 연결 AI 게이트웨이를 사용할 때 GitLab이 AI 프롬프트 및 응답 데이터를 처리하는 방법에 대한 정보는 GitLab Duo 데이터 사용을 참조하세요.
확장 로깅: 사용 데이터 수집이 활성화된 경우에도 민감한 정보의 의도하지 않은 유출을 방지하기 위해 GitLab 관리 AI 게이트웨이에서는 상세 로그가 생성되지 않습니다.
- 이 설정에서 로깅은 최소한으로 유지되며 확장 로깅 기능은 기본적으로 비활성화됩니다.
개인 정보 보호: 이 구성은 클라우드 환경에서 민감한 데이터가 로깅되지 않도록 설계되었습니다.

클라우드 연결 AI 게이트웨이의 로깅#

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

AI 게이트웨이와 GitLab 간 로그 상호 참조#

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

상관 관계 ID는 AI 게이트웨이와 GitLab 로그에서 찾을 수 있습니다. 그러나 모델 제공업체 로그에는 없습니다.

셀프 호스팅 모델의 로그

Tier: Premium, Ultimate
Offering: GitLab Self-Managed

원문 보기

번역일: 2026-05-22

요약

히스토리

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 Duo의 데이터 수집 활성화#

사전 요구 사항:

관리자여야 합니다.

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

자체 호스팅 AI Gateway가 있는 GitLab Self-Managed#

데이터 수집을 켜려면:

오른쪽 상단에서 관리자를 선택하세요.
왼쪽 사이드바에서 GitLab Duo를 선택하세요.
구성 변경을 선택하세요.
데이터 수집 아래에서 사용 데이터 수집을 선택하세요.
변경 사항 저장을 선택하세요.

GitLab 관리 AI Gateway가 있는 GitLab Self-Managed#

데이터 수집을 켜려면:

오른쪽 상단에서 관리자를 선택합니다.
왼쪽 사이드바에서 GitLab Duo를 선택합니다.
구성 변경을 선택합니다.
데이터 수집 아래에서 사용 데이터 수집을 선택합니다.
변경 사항 저장을 선택합니다.

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 게이트웨이 컨테이너의 로그#

AI 게이트웨이 및 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

또한 AI 게이트웨이 실행의 출력은 문제 디버깅에 도움이 될 수 있습니다. 접근 방법:

Docker 사용 시:
```
docker logs <container-id>
```
Kubernetes 사용 시:
```
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 게이트웨이 환경에서의 로깅 동작#

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

로깅 시나리오#

GitLab Self-Managed 및 셀프 호스팅 AI 게이트웨이#

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

로깅 동작: 전체 로깅이 활성화되고 모든 프롬프트, 입력 및 출력이 인스턴스의 llm.log에 로깅됩니다.
사용 데이터 수집이 활성화되면 다음을 포함한 추가 디버깅 정보가 로깅됩니다:
- 전처리된 프롬프트.
- 최종 프롬프트.
- 추가 컨텍스트.
개인 정보 보호: GitLab과 AI 게이트웨이 모두 셀프 호스팅이므로:
- 고객이 데이터 처리를 완전히 제어합니다.
- 민감한 정보의 로깅을 고객의 재량으로 활성화하거나 비활성화할 수 있습니다.
[!note] AI 기능이 GitLab 관리 모델을 사용할 때 사용 데이터 수집이 활성화된 경우에도 GitLab 관리 AI 게이트웨이에서는 상세 로그가 생성되지 않습니다. 이는 민감한 정보의 의도하지 않은 유출을 방지합니다.

GitLab Self-Managed 및 GitLab 관리 AI 게이트웨이(클라우드 연결)#

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

로깅 동작: 클라우드 연결 AI 게이트웨이를 사용할 때 GitLab이 AI 프롬프트 및 응답 데이터를 처리하는 방법에 대한 정보는 GitLab Duo 데이터 사용을 참조하세요.
확장 로깅: 사용 데이터 수집이 활성화된 경우에도 민감한 정보의 의도하지 않은 유출을 방지하기 위해 GitLab 관리 AI 게이트웨이에서는 상세 로그가 생성되지 않습니다.
- 이 설정에서 로깅은 최소한으로 유지되며 확장 로깅 기능은 기본적으로 비활성화됩니다.
개인 정보 보호: 이 구성은 클라우드 환경에서 민감한 데이터가 로깅되지 않도록 설계되었습니다.

클라우드 연결 AI 게이트웨이의 로깅#

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

AI 게이트웨이와 GitLab 간 로그 상호 참조#

상관 관계 ID는 AI 게이트웨이와 GitLab 로그에서 찾을 수 있습니다. 그러나 모델 제공업체 로그에는 없습니다.

셀프 호스팅 모델의 로그

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

자체 호스팅 AI Gateway가 있는 GitLab Self-Managed#

GitLab 관리 AI Gateway가 있는 GitLab Self-Managed#

GitLab 설치의 로그#

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

로깅 제어#

llm.log 파일#

AI 게이트웨이 컨테이너의 로그#

로그 구조#

1. 요청 페이로드#

요청 예시#

2. 요청 헤더#

요청 헤더 예시#

3. 요청 메타데이터#

메타데이터 예시#

응답 예시#

추론 서비스 제공업체의 로그#

GitLab 및 AI 게이트웨이 환경에서의 로깅 동작#

로깅 시나리오#

GitLab Self-Managed 및 셀프 호스팅 AI 게이트웨이#

GitLab Self-Managed 및 GitLab 관리 AI 게이트웨이(클라우드 연결)#

클라우드 연결 AI 게이트웨이의 로깅#

AI 게이트웨이와 GitLab 간 로그 상호 참조#

관련 항목#

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

자체 호스팅 AI Gateway가 있는 GitLab Self-Managed#

GitLab 관리 AI Gateway가 있는 GitLab Self-Managed#

GitLab 설치의 로그#

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

로깅 제어#

llm.log 파일#

AI 게이트웨이 컨테이너의 로그#

로그 구조#

1. 요청 페이로드#

요청 예시#

2. 요청 헤더#

요청 헤더 예시#

3. 요청 메타데이터#

메타데이터 예시#

응답 예시#

추론 서비스 제공업체의 로그#

GitLab 및 AI 게이트웨이 환경에서의 로깅 동작#

로깅 시나리오#

GitLab Self-Managed 및 셀프 호스팅 AI 게이트웨이#

GitLab Self-Managed 및 GitLab 관리 AI 게이트웨이(클라우드 연결)#

클라우드 연결 AI 게이트웨이의 로깅#

AI 게이트웨이와 GitLab 간 로그 상호 참조#

관련 항목#

`llm.log` 파일#

`llm.log` 파일#