Elasticsearch 문제 해결

Tier: 프리미엄, 얼티밋 Offering: Self-managed, GitLab Dedicated

Elasticsearch 문제 해결에 다음 정보를 사용하세요.

Rails 콘솔에서 구성 설정

Rails 콘솔 세션 시작을 참조하세요.

속성 목록

모든 사용 가능한 속성을 나열하려면:

  1. Rails 콘솔을 엽니다 (sudo gitlab-rails console).
  2. 다음 명령을 실행합니다: 
ApplicationSetting.last.attributes

출력에는 elasticsearch_indexing, elasticsearch_url, elasticsearch_replicas, elasticsearch_pause_indexing 등 Elasticsearch 통합에서 사용 가능한 모든 설정이 포함됩니다.

속성 설정

Elasticsearch 통합 설정을 변경하려면 다음과 같은 명령을 실행합니다: 

ApplicationSetting.last.update(elasticsearch_url: '<your ES URL and port>')

#또는

ApplicationSetting.last.update(elasticsearch_indexing: false)

속성 가져오기

설정이 Elasticsearch 통합 또는 Rails 콘솔에 설정되었는지 확인하려면 다음 명령을 실행합니다: 

Gitlab::CurrentSettings.elasticsearch_url

#또는

Gitlab::CurrentSettings.elasticsearch_indexing

비밀번호 변경

Elasticsearch 비밀번호를 변경하려면 다음 명령을 실행합니다: 

es_url = Gitlab::CurrentSettings.current_application_settings

# 현재 Elasticsearch URL 확인
es_url.elasticsearch_url

# Elasticsearch URL 설정
es_url.elasticsearch_url = "http://<username>:<password>@your.es.host:<port>"

# 변경 저장
es_url.save!

로그 보기

Elasticsearch 통합을 식별하는 데 가장 유용한 도구 중 하나는 로그입니다. 이 통합에 대한 가장 관련 있는 로그는 다음과 같습니다:

  1. sidekiq.log - 모든 색인 작업이 Sidekiq에서 발생하기 때문에 Elasticsearch 통합과 관련된 중요한 로그의 대부분은 이 파일에 있습니다.
  2. elasticsearch.log - 검색, 색인 또는 마이그레이션에 관한 유용한 진단 정보가 포함될 수 있는 Elasticsearch에 특화된 추가 로그가 이 파일로 전송됩니다.

다음은 일반적인 함정과 해당 극복 방법입니다.

일반 용어

  • Lucene: Java로 작성된 전체 텍스트 검색 라이브러리.
  • 실시간에 가까운 시간(NRT): 문서를 색인한 시간부터 실제 검색 가능해지는 시간까지의 약간의 지연을 나타냅니다.
  • 클러스터: 모든 데이터를 보유하고 있으며 색인 및 검색 기능을 제공하기 위해 함께 작동하는 하나 이상의 노드의 모음.
  • 노드: 클러스터의 일부로 작동하는 단일 서버.
  • 색인: 어느 정도 유사한 특성을 갖는 문서의 모음.
  • 문서: 색인할 수 있는 기본 정보의 단위.
  • 샤드: 색인의 완전히 기능적이고 독립적인 하위 분할. 각 샤드는 사실상 Lucene 색인입니다.
  • 복제본: 인덱스를 복제하는 장애 조치 메커니즘.

GitLab 인스턴스가 Elasticsearch를 사용하는지 확인하는 방법

이를 확인하는 몇 가지 방법이 있습니다:

  • 검색을 수행할 때 검색 결과 페이지의 우측 상단에 고급 검색 사용 가능이 표시됩니다. 현재 프로젝트/네임스페이스에 Elasticsearch가 사용되는지를 정확히 식별합니다.

  • 관리 영역에서 설정 > 고급 검색에서 고급 검색 설정이 확인되어야 합니다.

    필요한 경우 동일한 설정은 필요한 경우 Rails 콘솔에서 얻을 수 있습니다: 

    ::Gitlab::CurrentSettings.elasticsearch_search?         # 검색이 Elasticsearch를 사용하는지 여부
::Gitlab::CurrentSettings.elasticsearch_indexing?       # 콘텐츠가 Elasticsearch에 색인되는지 여부
::Gitlab::CurrentSettings.elasticsearch_limit_indexing? # Elasticsearch가 특정 프로젝트/네임스페이스에만 제한되는지 여부

  • Elasticsearch를 사용하는 검색을 확인하려면 rails 콘솔에 액세스하고 다음을 실행합니다: 

    u = User.find_by_email('email_of_user_doing_search')
s = SearchService.new(u, {:search => 'search_term'})
pp s.search_objects.class

    마지막 명령의 출력이 여기서 중요합니다. 다음과 같이 나타나면:

    • ActiveRecord::Relation이면 사용 중이 아닙니다.
    • Kaminari::PaginatableArray이면 사용 중입니다.

  • 특정 네임스페이스에 Elasticsearch가 제한되고 특정 프로젝트 또는 네임스페이스에서 Elasticsearch를 사용하는지 알아야 하는 경우 Rails 콘솔을 사용할 수 있습니다: 

    ::Gitlab::CurrentSettings.search_using_elasticsearch?(scope: Namespace.find_by_full_path("/my-namespace"))
::Gitlab::CurrentSettings.search_using_elasticsearch?(scope: Project.find_by_full_path("/my-namespace/my-project"))

색인화 문제 해결

색인화 문제 해결은 까다로운 작업일 수 있습니다. 빠르게 GitLab 지원팀 또는 Elasticsearch 관리자에게 문의해야 할 수도 있습니다.

시작하는 가장 좋은 곳은 비어있는 색인을 생성하는 문제인지 확인하는 것입니다. 그렇다면, Elasticsearch 측에서 gitlab-production (GitLab 색인을 위한 이름)이 존재하는지 확인하세요. 존재한다면 Elasticsearch 측에서 수동으로 삭제한 다음 recreate_index Rake 작업을 사용하여 다시 만들어 보세요.

여전히 문제가 발생한다면, Elasticsearch 인스턴스에 수동으로 색인을 만들어보세요. 여기서 색인의 세부 정보는 중요하지 않습니다. 우리가 원하는 것은 색인이 가능한지 테스트하는 것입니다. 색인을 만들 수 없다면 Elasticsearch 관리자에게 문의하세요. 색인을 만들 수 있다면, 이 문제를 GitLab 지원팀에 Eskate하세요.

비어있는 색인을 생성하는 문제가 아닌 경우, 다음 단계는 프로젝트 색인 중에 오류를 확인하는 것입니다. 오류가 발생한다면, 이는 색인 중에 발생한 것입니다:

  • GitLab 측에서. 이를 수정해야 합니다. 익숙하지 않다면, GitLab 지원팀에 지원을 요청하세요.
  • Elasticsearch 인스턴스 자체 내에서. 오류가 문서화되어 있고 수정 방법이 있는지 확인하세요. 그렇지 않다면 Elasticsearch 관리자에게 문의하세요.

만일 색인화 과정에서 오류가 발생하지 않는다면, 색인 된 프로젝트의 상태를 확인하세요. 다음 Rake 작업을 통해 확인할 수 있습니다:

만일:

  • 모든 것이 100%로 표시된다면, GitLab 지원팀에 Eskate하세요. 이것은 잠재적인 버그/이슈일 수 있습니다.
  • 100%가 아닌 것을 발견한다면, 해당 프로젝트의 재색인을 시도해보세요. 이를 위해 다음과 같이 실행하세요: sudo gitlab-rake gitlab:elastic:index_projects ID_FROM=<project ID> ID_TO=<project ID>.

프로젝트의 재색인이 다음을 보여주면: - GitLab 측에서 오류가 발생한다면, 이를 GitLab 지원팀에 Eskate하세요. - Elasticsearch에서 오류가 발생하지 않거나 전혀 오류가 나타나지 않는다면, Elasticsearch 관리자에게 인스턴스를 확인해보라고 요청하세요.

GitLab을 업데이트했지만 이제 아무 것도 찾을 수 없습니다

우리는 지속적으로 색인 전략을 업데이트하고 최신 버전의 Elasticsearch를 지원하려 노력합니다. 색인 변경이 이뤄진 경우, GitLab을 업데이트한 후에 재색인이 필요할 수 있습니다.

모든 저장소를 색인했지만 UI에서 검색어에 대한 결과를 찾을 수 없습니다

모든 데이터베이스 데이터를 색인화했는지 확인하세요.

UI 검색에서 결과가 나타나지 않는다면, 레일즈 콘솔(sudo gitlab-rails console)을 통해 동일한 결과를 확인하는지 확인하세요: 

u = User.find_by_username('your-username')
s = SearchService.new(u, {:search => 'search_term', :scope => 'blobs'})
pp s.search_objects.to_a

이외에도 Elasticsearch 검색 API를 통해 Elasticsearch 측에서 데이터가 표시되는지 확인하세요. 

curl --request GET <elasticsearch_server_ip>:9200/gitlab-production/_search?q=<search_term>

더 복잡한 Elasticsearch API 호출도 가능합니다.

만일 결과가:

  • 일치한다면, 지원되는 구문을 사용하는지 확인하세요. 고급 검색은 정확한 부분 문자열 일치를 지원하지 않습니다.
  • 일치하지 않는다면, 이는 프로젝트에서 생성된 문서의 문제를 나타냅니다. 이 경우에는 그 프로젝트를 재색인하는 것이 가장 좋습니다.

참고: 위 지침은 네임스페이스의 일부만을 색인화하는 시나리오에 사용되어서는 안됩니다.

특정 유형의 데이터를 검색하는 더 많은 정보는 Elasticsearch 색인 범위를 확인하세요.

모든 저장소를 색인했지만 Elasticsearch 서버를 전환한 후 이제 아무 것도 찾을 수 없습니다

데이터베이스, 저장소 및 위키를 재색인하려면 모든 Rake 작업을 다시 실행해야 합니다.

일부 프로젝트가 색인되지 않았지만 어떤 것들인지 모릅니다

sudo gitlab-rake gitlab:elastic:projects_not_indexed를 실행하여 색인되지 않은 프로젝트를 표시할 수 있습니다.

코드를 푸쉬할 때 Elasticsearch 색인에 새 데이터가 추가되지 않습니다

참고: 이 문제는 GitLab 13.2에서 수정되었으며 해당 버전보다 높은 버전에서는 Rake 작업이 사용할 수 없습니다.

블롭의 초기 색인 작업을 수행할 때 해당 프로젝트의 색인이 완료될 때까지 모든 프로젝트를 잠급니다. 처리 중에 오류가 발생하여 하나 이상의 프로젝트가 잠기게 될 수 있습니다. 이를 해제하려면 다음을 실행하세요: 

sudo gitlab-rake gitlab:elastic:clear_locked_projects

error: elastic: Error 429 (Too Many Requests)로 색인에 실패

ElasticCommitIndexerWorker Sidekiq worker가 색인 중에 이 오류로 실패하는 경우, 보통 Elasticsearch가 색인 요청의 동시성에 맞춰지지 못했음을 의미합니다. 다음 설정을 변경하여 문제를 해결할 수 있습니다:

  • 색인 처리량을 줄이려면 Bulk request concurrency를 줄일 수 있습니다(자세한 내용은 고급 검색 설정을 참조). 기본값은 10이지만 1로 낮출 수도 있어서 색인 작업의 동시성 수를 줄일 수 있습니다.
  • Bulk request concurrency를 변경해도 도움이 되지 않는 경우, routing rules 옵션을 사용하여 특정 Sidekiq 노드에만 색인 작업을 제한할 수 있습니다(elasticsearch.md#index-large-instances-with-dedicated-sidekiq-nodes-or-processes). 이렇게 하면 색인 요청 수를 줄일 수 있습니다.

색인이 매우 느리거나 rejected execution of coordinating operation 메시지로 실패하는 경우

Elasticsearch 노드에서 Reject된 대량 요청은 일반적으로 부하와 사용 가능한 메모리 부족 때문입니다. Elasticsearch 클러스터가 시스템 요구 사항을 충족하고 충분한 리소스를 갖고 있는지 확인하세요. 이러한 문제와 관련하여 “429 (Too Many Requests)” 오류도 참고하세요.

strict_dynamic_mapping_exception으로 색인이 실패

만약 모든 고급 검색 마이그레이션이 주요 업그레이드 전에 완료되지 않은 경우 색인이 실패할 수 있습니다. 이 오류와 함께 대규모 Sidekiq 백로그가 발생할 수 있습니다. 색인 실패를 수정하려면 데이터베이스, 저장소 및 위키를 새로 색인해야 합니다.

  1. Sidekiq가 따라잡을 수 있도록 색인을 일시 중지하세요: 

    sudo gitlab-rake gitlab:elastic:pause_indexing
  2. 처음부터 인덱스 다시 만들기

  3. 인덱싱 재개: 

    sudo gitlab-rake gitlab:elastic:resume_indexing

인덱스를 처음부터 다시 만드는 마지막 수단

데이터가 어떻게 되었든 색인되지 않은 경우이거나 큐에 없거나 마이그레이션이 진행되지 않는 등 인덱스가 어떤 상태에 있는 경우가 있을 수 있습니다. 문제의 근본 원인을 해결하려면 로그를 확인합니다.

최후의 수단으로 인덱스를 처음부터 다시 만들 수 있습니다. 소규모 GitLab 설치의 경우 인덱스를 처음부터 다시 만드는 것이 몇 가지 문제를 해결하는 빠른 방법일 수 있습니다. 그러나 대규모 GitLab 설치의 경우 이 방법은 매우 오랜 시간이 걸릴 수 있습니다. 색인이 완료될 때까지 인덱스가 올바른 검색 결과를 표시하지 않습니다. 색인이 진행 중인 동안 Elasticsearch로 검색 확인란을 지우고 싶을 수 있습니다.

위의 주의 사항을 읽고 이해했으며 계속 진행하려는 경우 다음 Rake 작업을 실행해 전체 인덱스를 처음부터 다시 만들어야 합니다.

Linux 패키지 (Omnibus)
# 경고: 위의 설명을 읽기 전까지 이 명령을 절대 실행하지 마십시오
sudo gitlab-rake gitlab:elastic:index
소스에서 직접 컴파일한 경우
# 경고: 위의 설명을 읽기 전까지 이 명령을 절대 실행하지 마십시오
cd /home/git/gitlab
sudo -u git -H bundle exec rake gitlab:elastic:index

성능 문제 해결

Elasticsearch의 성능 문제 해결은 어려울 수 있습니다. 세심한 조정이 가능하지만 대부분의 부담은 숙련된 Elasticsearch 관리자에게 달려 있습니다.

일반적으로 다음을 확인하세요:

  • Elasticsearch 서버가 GitLab과 같은 노드에서 실행되고 있지 않은지 확인합니다.
  • Elasticsearch 서버가 충분한 RAM과 CPU 코어를 갖고 있는지 확인합니다.
  • Sharding을 사용하고 있는지 확인합니다.

더 자세히 설명하면, Elasticsearch가 GitLab과 동일한 서버에서 실행된다면 리소스 간 격돌이 매우 가능합니다. 충분한 리소스를 필요로 하는 Elasticsearch는 이상적으로 자원이 풍부해야 하며, 이는 개별 서버에서 실행되어야 합니다(로그스태시와 키바나와 결합될 수도 있습니다).

Elasticsearch에서 RAM은 핵심 자원입니다. Elasticsearch에서는 다음을 권장합니다:

  • 비 프로덕션 인스턴스의 경우 적어도 8GB의 RAM.
  • 프로덕션 인스턴스의 경우 적어도 16GB의 RAM.
  • 이상적으로는 64GB의 RAM.

CPU의 경우 Elasticsearch에서는 적어도 2개의 CPU 코어를 권장하지만, 일반적인 설정에서는 최대 8코어까지 사용된다고 명시하고 있습니다. 서버 사양에 대한 자세한 내용은 Elasticsearch 하드웨어 가이드를 참조하세요.

명백한 부분 이외에도 Sharding이 중요합니다. Sharding은 Elasticsearch의 핵심 부분입니다. 인덱스의 수평 스케일링을 가능케 하며, 대량의 데이터를 처리할 때 유용합니다.

GitLab이 색인하는 방식에 따르면 막대한 수의 문서가 색인됩니다. Sharding을 사용함으로써 Elasticsearch가 데이터를 빠르게 찾을 수 있도록 도울 수 있습니다. 각 샤드가 루씬 인덱스이기 때문에 데이터를 찾는 능력이 향상될 수 있습니다.

Sharding을 사용하지 않으면 프로덕션 환경에서 Elasticsearch를 사용하기 시작할 때 문제가 발생할 가능성이 큽니다.

한 개의 샤드만 있는 인덱스는 스케일 요소가 없으며 빈도가 높을 때 문제가 발생할 가능성이 매우 큽니다. 용량 계획에 대한 자세한 내용은 Elasticsearch 용량 계획 설명서를 참조하세요.

Sharding을 사용하는지 여부를 확인하려면 Elasticsearch Health API의 출력을 확인하십시오:

  • 빨간색: 클러스터가 다운됨.
  • 노란색: 샤딩/복제 없이 상태가 나옴.
  • 초록색: 정상적인 상태(가동 중, 샤딩, 복제).

프로덕션에서는 항상 초록색으로 나와야 합니다.

이러한 단계 이상으로는 병합 및 캐싱과 같은 더 복잡한 사항으로 들어가게 되는데, 이러한 사항은 복잡하며 익히는 시간이 걸리기 때문에 필요할 경우 Elasticsearch 전문가와 협력/상담하는 것이 좋을 것입니다.

GitLab 지원팀에 문의하십시오. 그러나 보다 깊은 지식과 경험이 필요한 것은 Elasticsearch 관리자가 더 경험이 있을 것으로 예상됩니다.

초기 색인화 속도가 느린 경우

GitLab 인스턴스의 데이터가 많을수록 색인화에 소요되는 시간이 길어집니다. Rake 작업 sudo gitlab-rake gitlab:elastic:estimate_cluster_size로 클러스터 크기를 추정할 수 있습니다.

코드 문서의 경우

코드, 커밋, 위키를 효율적으로 색인화하기 위해 충분한 Sidekiq 노드와 프로세스를 갖고 있는지 확인하세요. 초기 색인화 속도가 느리다면 전용 Sidekiq 노드나 프로세스를 고려해보세요.

비코드 문서의 경우

초기 색인화 속도가 느리지만 Sidekiq에 충분한 노드와 프로세스가 있다면 GitLab에서 고급 검색 워커 설정을 조정할 수 있습니다. 다시 대기중인 색인화 워커의 경우 기본값은 false입니다. 비코드 색인화를 위한 샤드 수의 기본값은 2입니다. 이러한 설정은 분당 2000개의 문서로 색인화를 제한합니다.

워커 설정을 조정하려면:

  1. 왼쪽 사이드바에서 가장 아래에 관리자 영역을 선택합니다.
  2. 설정 > 고급 검색을 선택합니다.
  3. 고급 검색을 확장합니다.
  4. 다시 대기중인 색인화 워커 확인란을 선택합니다.
  5. 비코드 색인화를 위한 샤드 수 텍스트 상자에 2보다 높은 값을 입력합니다.
  6. 변경 사항 저장을 선택합니다.

마이그레이션 문제

Elasticsearch 마이그레이션에 대해 자세히 읽었는지 확인하세요.

만약 중단된 마이그레이션이 있고 elasticsearch.log 파일에 오류가 있다면, 이는 잠재적으로 버그/이슈일 수 있습니다. 마이그레이션을 다시 시도해도 성공하지 않는다면 GitLab 지원팀에 문의하세요.

no parent field has been configured 오류

GitLab 8.12 이전에 Elasticsearch를 활성화한 경우 인덱스를 다시 빌드하지 않으면 다양한 경우에 예외가 발생합니다: 

Elasticsearch::Transport::Transport::Errors::BadRequest([400] {
    "error": {
        "root_cause": [{
            "type": "illegal_argument_exception",
            "reason": "Can't specify parent if no parent field has been configured"
        }],
        "type": "illegal_argument_exception",
        "reason": "Can't specify parent if no parent field has been configured"
    },
    "status": 400
}):

이는 GitLab 8.12에서 인덱스 매핑이 변경되었기 때문에 이전 인덱스를 제거하고 다시 빌드해야 합니다. 자세한 내용은 업데이트 가이드를 참조하세요.

Elasticsearch::Transport::Transport::Errors::BadRequest

위와 같은 예외가 발생하는 경우 (실제 메시지는 다를 수 있음), 올바른 Elasticsearch 버전을 사용하고 다른 요구 사양을 충족하는지 확인하세요. sudo gitlab-rake gitlab:check 명령어로 자동으로 확인할 수도 있습니다.

Elasticsearch::Transport::Transport::Errors::RequestEntityTooLarge 

[413] {"Message":"Request size exceeded 10485760 bytes"}

이 예외는 Elasticsearch 클러스터가 일정 크기 이상의 요청을 거부하도록 구성된 경우(이 경우 10 MiB)에 발생합니다. 이는 elasticsearch.yml의 http.max_content_length 설정에 해당합니다. 이 값을 더 큰 값으로 증가시키고 Elasticsearch 클러스터를 다시 시작하세요.

AWS는 기존 인스턴스 크기에 기초하여 HTTP 요청 페이로드의 최대 크기에 대한 네트워크 제한을 설정합니다. 최대 대량 요청 크기를 10 MiB보다 작은 값으로 설정하세요.

대프록시를 사용하는 경우 Faraday::TimeoutError (execution expired) 오류

사용 중인 Elasticsearch 호스트의 IP 주소로 호출되는 no_proxy 환경 변수를 설정하세요.

싱글 노드 Elasticsearch 클러스터 상태가 노랑(yellow)에서 초록(green)으로 전환되지 않음

싱글 노드 Elasticsearch 클러스터의 작동 클러스터 상태는 노랑(yellow)입니다. (초록은 없음) 이는 기본 샤드는 할당되지만 복제본은 할당할 다른 노드가 없기 때문입니다. 또한 Amazon OpenSearch 서비스를 사용하는 경우도 해당됩니다.

주의: 0으로 복제본 수를 설정하는 것은 권장되지 않습니다 (GitLab Elasticsearch 통합 메뉴에서 허용되지 않음). Elasticsearch 노드를 추가할 계획이 있다면 (총 1개 이상의 Elasticsearch로), 복제본 수를 0보다 큰 정수 값으로 설정해야 합니다. 그렇지 않으면 무결성이 부족하게 됩니다(Elasticsearch 노드를 하나 잃으면 인덱스가 손상됨).

싱글 노드 Elasticsearch 클러스터의 상태를 초록(green)으로 설정하는 것이 절대적으로 필요하다면, 이전 단락에서 개요된 위험에 대해 이해한 후 다음 쿼리를 실행하여 복제본 수를 0으로 설정하세요(클러스터는 더 이상 복제본을 만들지 않게 됨): 

curl --request PUT localhost:9200/gitlab-production/_settings --header 'Content-Type: application/json' \
     --data '{
       "index" : {
         "number_of_replicas" : 0
       }
     }'

Sidekiq에서 health check timeout: no Elasticsearch node available 오류

색인 프로세스 중에 Sidekiq에서 health check timeout: no Elasticsearch node available 오류가 발생하는 경우: 

Gitlab::Elastic::Indexer::Error: time="2020-01-23T09:13:00Z" level=fatal msg="health check timeout: no Elasticsearch node available"

아마도 Elasticsearch 통합 메뉴의 “URL” 필드 값으로 http:// 또는 https:// 중 하나를 사용하지 않았을 것입니다. 이 필드에 http:// 또는 https:// 중 하나를 사용하고 있음을 확인하십시오. 저희가 사용 중인 Elasticsearch client for Go는 URL의 접두사가 유효한 값으로 수락되기 위해 접두사가 필요합니다. URL의 서식을 수정한 후, 색인을 삭제하고(전용 Rake 작업(https://docs.gitlab.com/ee/user/project/merge_requests/creating_merge_requests.html)) 인스턴스 내용을 다시 색인하세요.

제 Elasticsearch 클러스터에 플러그인이 있으며 통합이 작동하지 않습니다

특정 타사 플러그인들은 클러스터에 버그를 도입할 수 있거나 어떠한 이유로 우리의 통합과 호환되지 않을 수 있습니다. 문제의 원인이 플러그인인지 확인하기 위해 플러그인을 비활성화해 보아야 합니다.

Elasticsearch code_analyzer는 모든 코드 케이스를 고려하지 않습니다

code_analyzer 패턴 및 필터 구성은 개선을 위해 평가 중입니다. 저희는 대부분의 예외 상황을 해결하여 예상한 검색 결과를 반환하지 않았던 대부분의 예외 사항을 해결했습니다.

code_analyzer 패턴 및 필터의 개선은 epic 3621에서 논의 중입니다.

일부 이진 파일은 이름으로 검색할 수 없을 수 있습니다

GitLab 13.9에서 이진 파일 이름이 색인화되도록 변경되었습니다. 그러나 GitLab 13.9 릴리스 이후에 추가되거나 업데이트된 이진 파일만 검색 가능하며, 모든 프로젝트 데이터를 처음부터 색인화하지 않는 이상 이진 파일만 검색 가능합니다.

고급 검색이 비공개 프로젝트를 다루는 방법

고급 검색은 모든 프로젝트를 동일한 Elasticsearch 색인에 저장하지만, 사용자가 볼 수 있는 결과만 표시하도록 필터링합니다. 고급 검색은 검색 시 사용자가 액세스할 수 없는 프로젝트를 필터링하여 응용 프로그램 내의 모든 권한 확인을 존중합니다.

AWS Elasticsearch 또는 OpenSearch에서 세분화된 액세스 제어를 사용하는 경우의 역할 매핑

IAM 역할이나 OpenSearch 대시보드를 사용하여 생성된 역할을 사용할 때 세분화된 액세스 제어를 사용할 경우 다음과 같은 오류가 발생할 수 있습니다. 

{"error":{"root_cause":[{"type":"security_exception","reason":"no permissions for [indices:data/write/bulk] and User [name=arn:aws:iam::xxx:role/INSERT_ROLE_NAME_HERE, backend_roles=[arn:aws:iam::xxx:role/INSERT_ROLE_NAME_HERE], requestedTenant=null]"}],"type":"security_exception","reason":"no permissions for [indices:data/write/bulk] and User [name=arn:aws:iam::xxx:role/INSERT_ROLE_NAME_HERE, backend_roles=[arn:aws:iam::xxx:role/INSERT_ROLE_NAME_HERE], requestedTenant=null]"},"status":403}

이를 해결하려면 Kibana에서 사용자에게 역할 매핑을 수행해야 합니다.

Elasticsearch 워커가 Sidekiq에 과부하를 일으킴

일부 경우에는 Elasticsearch가 GitLab에 더 이상 연결할 수 없게 되어 발생할 수 있습니다:

  • Elasticsearch 암호가 한쪽에서만 업데이트된 경우(Unauthorized [401] ... unable to authenticate user 오류).
  • 방화벽 또는 네트워크 문제로 연결이 손상된 경우(Failed to open TCP connection to <ip>:9200 오류).

이러한 오류는 gitlab-rails/elasticsearch.log에 로그됩니다. 오류를 검색하려면 jq를 사용하십시오: 

$ jq --raw-output 'select(.severity == "ERROR") | [.error_class, .error_message] | @tsv' \
    gitlab-rails/elasticsearch.log |
  sort | uniq -c

Elastic 워커 및 Sidekiq 작업은 이전 작업이 실패한 경우 Elasticsearch가 자주 다시 색인하려고 하기 때문에 훨씬 더 자주 나타날 수도 있습니다. Sidekiq 로그에서 워커 수를 계산하려면 fast-stats 또는 jq를 사용할 수 있습니다: 

$ fast-stats --print-fields=count,score sidekiq/current
WORKER                            COUNT   SCORE
ElasticIndexBulkCronWorker          234  123456
ElasticIndexInitialBulkCronWorker   345   12345
Some::OtherWorker                    12     123
...

$ jq '.class' sidekiq/current | sort | uniq -c | sort -nr
 234 "ElasticIndexInitialBulkCronWorker"
 345 "ElasticIndexBulkCronWorker"
  12 "Some::OtherWorker"
...

이 경우에는 과부하된 GitLab 노드에서 free -m을 사용하면 예기치 않은 높은 buff/cache 사용률이 표시됩니다.

reindex 시 작업 상태를 로드할 수 없음 오류 발생

다시 색인 작업을 수행할 때 작업 상태를 로드할 수 없음 오류가 발생할 수 있습니다. 또한 Elasticsearch 호스트에서 sliceId must be greater than 0 but was [-1] 오류가 나타날 수도 있습니다. 임시 방편으로 처음부터 다시 색인하거나 GitLab 16.3으로 업그레이드하는 것을 고려해 보세요.

자세한 정보는 이슈 422938를 참조하세요.

GitLab 15.11에서 마이그레이션 BackfillProjectPermissionsInBlobs가 중지되었습니다

GitLab 15.11에서 BackfillProjectPermissionsInBlobs 마이그레이션이 elasticsearch.log에 다음과 같은 오류 메시지와 함께 중지될 수 있습니다: 

migration has failed with NoMethodError:undefined method `<<' for nil:NilClass, no retries left

만약 BackfillProjectPermissionsInBlobs가 유일하게 중지된 마이그레이션이라면, 해당 수정이 포함된 GitLab 16.0의 최신 패치 버전으로 업그레이드할 수 있습니다. 그렇지 않다면, 이 오류를 무시해도 고급 검색의 현재 기능에는 영향을 미치지 않을 것입니다.

ElasticIndexInitialBulkCronWorker 및 ElasticIndexBulkCronWorker 작업이 중복 제거에서 멈춤

GitLab 16.5 및 이전 버전에서 ElasticIndexInitialBulkCronWorker 및 ElasticIndexBulkCronWorker 작업이 중복 제거에서 멈추는 경우가 발생할 수 있습니다. 이 문제는 새로운 색인을 생성한 후에도 고급 검색이 문서를 올바르게 색인화하는 것을 방해할 수 있습니다. GitLab 16.6에서 색인을 수행하는 벌크 크론 워커에 대한 idempotent!가 제거되었습니다.

Sidekiq 로그에는 다음과 같은 항목이 포함될 수 있습니다: 

{"severity":"INFO","time":"2023-10-31T10:33:06.998Z","retry":0,"queue":"default","version":0,"queue_namespace":"cronjob","args":[],"class":"ElasticIndexInitialBulkCronWorker",
...
"idempotency_key":"resque:gitlab:duplicate:default:<value>","duplicate-of":"91e8673347d4dc84fbad5319","job_size_bytes":2,"pid":12047,"job_status":"deduplicated","message":"ElasticIndexInitialBulkCronWorker JID-5e1af9180d6e8f991fc773c6: deduplicated: until executing","deduplication.type":"until executing"}

이 문제를 해결하려면:

  1. Rails 콘솔 세션에서 다음 명령을 실행하세요: 

    idempotency_key = "<idempotency_key_from_log_entry>"
duplicate_key = "resque:gitlab:#{idempotency_key}:cookie:v2"
Gitlab::Redis::Queues.with { |c| c.del(duplicate_key) }

  2. <idempotency_key_from_log_entry>를 로그의 실제 항목으로 교체하세요.