히스토리

• 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과 공유되지 않습니다.

데이터 수집을 켜려면:

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

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

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

데이터 수집을 켜려면:

1. 오른쪽 위에서 Admin을 선택합니다.
2. 왼쪽 사이드바에서 GitLab Duo를 선택합니다.
3. Change configuration을 선택합니다.
4. Data collection 아래에서 Collect usage data를 선택합니다.
5. 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 인프라에서만 확인할 수 있습니다.

• llm.log의 로그 순환, 관리, 내보내기 및 시각화.
• 로그 파일 위치 확인(예: 로그를 삭제할 수 있도록).

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

로그 집계를 위해 GitLab Duo Workflow Service 로그를 구조화된 JSON으로 남기려면 다음 환경 변수를 설정합니다:

-e DUO_WORKFLOW_LOGGING__JSON_FORMAT=true

DUO_WORKFLOW_LOGGING__JSON_FORMAT을 설정하지 않으면 형식은 DUO_WORKFLOW_SERVICE_ENVIRONMENT에서 파생됩니다. 환경이 development로 설정되어 있지 않으면 GitLab Duo Workflow Service는 JSON을 사용합니다. 그렇지 않으면 일반 텍스트를 사용합니다.

DUO_WORKFLOW_LOGGING 변수는 GitLab Duo Workflow Service만 구성하며 AI Gateway의 AIGW_LOGGING 변수와는 독립적입니다. 둘 중 하나를 설정해도 다른 하나에는 영향을 주지 않습니다. 두 서비스에서 동일하게 동작하게 하려면 두 변수를 모두 설정합니다.

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

또한 AI Gateway 실행 출력은 문제를 디버깅하는 데 도움이 됩니다. 출력에 접근하려면:

• 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 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가 모두 셀프 호스팅이므로:

  • 고객이 데이터 처리를 완전히 제어합니다.
  • 민감한 정보의 로깅은 고객의 재량으로 활성화하거나 비활성화할 수 있습니다.

  [!note] 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는 AI Gateway와 GitLab 로그에서 확인할 수 있습니다. 모델 공급자 로그에는 없습니다.

자세한 내용은 다음을 참고합니다.

• 상관 ID로 관련 로그 항목 찾기
• jq로 GitLab 로그 파싱