Elasticsearch 문제 해결

Tier: Premium, Ultimate 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: '<귀하의 ES URL 및 포트>')

#또는

ApplicationSetting.last.update(elasticsearch_indexing: false)

속성 가져오기

Rails 콘솔 또는 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://<사용자명>:<비밀번호>@your.es.host:<포트>"

# 변경 저장
es_url.save!

로그 보기

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

  1. sidekiq.log - 모든 색인 작업은 Sidekiq에서 수행되므로 Elasticsearch 통합에 관련된 로그 대부분은 이 파일에 있습니다.
  2. elasticsearch.log - 별도의 Elasticsearch 관련 로그가 여기에 전송되며, 검색, 색인 또는 마이그레이션에 대한 유용한 진단 정보를 포함할 수 있습니다.

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

일반 용어

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

GitLab 인스턴스가 Elasticsearch를 사용하는지 확인하는 방법은 무엇인가요?

이를 달성하는 몇 가지 방법이 있습니다:

  • 검색을 수행할 때 검색 결과 페이지의 오른쪽 상단에 고급 검색이 활성화됨이 표시됩니다. 현재 프로젝트/네임스페이스가 Elasticsearch를 사용하는지 항상 올바르게 식별합니다.

  • 관리자 영역에서 설정 > 고급 검색에서 고급 검색 설정이 확인됩니다.

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

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

  • Rails 콘솔에 액세스하여 검색이 Elasticsearch를 사용하는지 확인하려면 다음 명령을 실행하세요: 

    u = User.find_by_email('검색을 수행하는 사용자의 이메일')
s = SearchService.new(u, {:search => '검색어'})
pp s.search_objects.class

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

    • ActiveRecord::Relation이면 Elasticsearch를 사용하고 있지 않습니다.
    • Kaminari::PaginatableArray이면 Elasticsearch를 사용하고 있습니다.

  • 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 지원팀에 문의하십시오.

빈 인덱스를 만드는 문제가 아닌 경우 다음 단계는 프로젝트의 색인 중에 오류를 확인하는 것입니다. 오류가 발생하는 경우 그 원인은 다음과 같습니다:

  • GitLab 측에서 발생합니다. 이를 해결해야 합니다. 익숙하지 않은 경우 GitLab 지원팀에 문의하십시오.
  • Elasticsearch 인스턴스 자체에서 발생합니다. 오류가 문서화되어 있고 해결책이 있는지 확인하십시오. 그렇지 않으면 Elasticsearch 관리자에게 문의하십시오.

색인 프로세스에 오류가 없는 경우 색인된 프로젝트의 상태를 확인하십시오. 이를 다음 Rake 작업을 통해 수행할 수 있습니다:

다음이라면:

  • 모든 것이 100%를 표시하는 경우 GitLab 지원팀에 문의하십시오. 이는 잠재적인 버그/문제일 수 있습니다.
  • 100%가 아닌 것이 있는 경우 해당 프로젝트의 색인을 다시 생성해 보십시오. 이를 위해 sudo gitlab-rake gitlab:elastic:index_projects ID_FROM=<프로젝트 ID> ID_TO=<프로젝트 ID>를 실행하십시오.

프로젝트를 다시 색인한 결과가:

  • GitLab 측에서 오류가 발생하면 GitLab 지원팀에 문의하십시오.
  • Elasticsearch에서 오류가 발생하거나 오류가 표시되지 않는 경우 Elasticsearch 관리자에게 문의하십시오.

GitLab을 업데이트했지만 아무 것도 찾을 수 없는 경우

저희는 계속해서 인덱싱 전략을 개선하고 최신 버전의 Elasticsearch를 지원하기 위해 노력하고 있습니다. 인덱싱 변경이 이루어지면 GitLab을 업데이트한 후 재색인이 필요할 수 있습니다.

모든 리포지터리를 색인했지만 UI에서 검색 용어에 대한 결과를 얻을 수 없음

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

UI 검색 결과 (히트)가 없는 경우, Rails 콘솔(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 쪽에서 데이터가 표시되는지 확인하기 위해 Elasticsearch Search API를 통해 확인하세요: 

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

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

만약:

note
상기 지침은 네임스페이스의 하위 집합을 색인화하는 시나리오에만 사용하지 않는 것입니다.

특정 유형의 데이터를 검색하는 데 더 많은 정보는 Elasticsearch Index Scopes를 참조하세요.

모든 리포지터리를 색인화했지만 Elasticsearch 서버를 전환했으며 이제 아무것도 찾을 수 없음

데이터베이스, 리포지터리 및 위키를 다시 색인화하려면 모든 Rake 작업을 다시 실행해야 합니다.

색인화되지 않은 일부 프로젝트가 있지만 어떤 프로젝트인지 모름

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

코드를 푸시할 때 Elasticsearch 인덱스에 새 데이터가 추가되지 않음

note
GitLab 13.2 이상에서는 수정되었으며 Rake 작업은 사용할 수 없습니다.

블롭의 초기 색인화를 수행할 때 모든 프로젝트를 잠그고, 프로젝트가 모두 색인화를 완료할 때까지 잠길 수 있습니다. 이 과정 중에 오류가 발생하여 하나 이상의 프로젝트가 계속 잠기는 경우가 있을 수 있습니다. 그러한 프로젝트를 잠금해제하려면 다음을 실행하세요: 

sudo gitlab-rake gitlab:elastic:clear_locked_projects

색인화가 error: elastic: Error 429 (Too Many Requests)와 실패함

색인화 중 ElasticCommitIndexerWorker Sidekiq 워커가 이 오류로 실패하는 경우, 일반적으로 Elasticsearch가 색인화 요청의 동시성에 따라 따라잡지 못하고 있음을 의미합니다. 이를 해결하기 위해 다음 설정을 변경하세요:

  • 색인화 처리량을 감소시키려면 Bulk request concurrency를 감소시킬 수 있습니다(자세한 내용은 고급 검색 설정을 참조). 기본값은 10으로 설정되어 있지만, 동시 색인화 작업 수를 줄이기 위해 1로 설정할 수 있습니다.
  • Bulk request concurrency 변경이 도움이 되지 않는 경우, 라우팅 규칙 옵션을 사용하여 특정 Sidekiq 노드에만 색인화 작업을 제한할 수 있습니다. 이를 통해 색인화 요청 수를 줄일 수 있습니다.

색인화가 매우 느리거나 rejected execution of coordinating operation 메시지로 실패함

Elasticsearch 노드가 대규모 요청을 처리하지 못하고 있거나 충분한 메모리가 없어서 대규모 요청이 거부되는 경우가 있습니다. 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

인덱스를 처음부터 다시 생성하는 마지막 수단

데이터가 색인화되지 않았거나 큐에 없거나 인덱스가 마이그레이션을 진행하지 못하는 상태일 수 있는 경우가 있습니다. 문제의 근본 원인을 해결하려면 로그를 확인하여 문제를 해결하는 것이 가장 좋습니다.

마지막 수단으로, 인덱스를 처음부터 다시 생성할 수 있습니다. small GitLab 인스턴스의 경우 잠재적으로 문제를 해결하는 빠른 방법일 수 있지만, large 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 코어가 있는지 확인하십시오.
  • 샤딩을 사용하고 있는지 확인하십시오.

Elasticsearch가 GitLab과 동일한 서버에서 실행되는 경우, 자원 경합이 매우 발생할 가능성이 매우 높습니다. 대량의 리소스를 필요로 하는 Elasticsearch는 적절한 리소스를 갖춘 자체 서버(가능하다면 Logstash 및 Kibana와 결합)에서 실행되어야 합니다.

Elasticsearch에서 RAM은 핵심 자원입니다. Elasticsearch 자체에서는 비 프로덕션 환경에는 적어도 8GB의 RAM이, 프로덕션 환경에는 적어도 16GB의 RAM이 필요하다고 권장하고 있습니다. 이상적으로는 64GB의 RAM을 권장합니다.

CPU의 경우, Elasticsearch는 최소 2개의 CPU 코어를 권장하고 있지만 공통 설정은 최대 8코어를 사용한다고 명시하고 있습니다. 서버 사양에 대한 자세한 내용은 Elasticsearch 하드웨어 가이드를 확인하십시오.

단순한 것으로 가면 샤딩이 있습니다. 샤딩은 Elasticsearch의 핵심 부분입니다. 이는 인덱스의 수평 확장을 허용하며 많은 양의 데이터를 다룰 때 유용합니다.

GitLab의 색인화 방식에 따라 색인화되는 문서가 매우 많습니다. 샤딩을 사용하면 각 샤드가 Lucene 인덱스이기 때문에 Elasticsearch가 데이터를 빠르게 찾을 수 있는 능력을 높일 수 있습니다.

샤딩을 사용하지 않는 경우, 프로덕션 환경에서 Elasticsearch를 사용하기 시작할 때 문제가 발생할 가능성이 높습니다.

한 개의 샤드만 있는 인덱스는 확장률 요소가 없으며 빈도가 높은 요청에도 반응하기 어려울 수 있습니다. Elasticsearch용 용량 계획을 확인하십시오.

쉽게 확인할 수 있는 방법으로는 샤딩이 사용되고 있는지를 확인하는 것입니다. 명시하지 않고 호출하면 쉽게 확인할 수 있습니다. Elasticsearch Health API의 출력:

  • 빨간색은 클러스터가 다운된 상태를 나타냅니다.
  • 노란색은 샤딩/복제되지 않은 상태를 나타냅니다.
  • 녹색은 건강한 상태를 나타냅니다(접속, 샤딩, 복제 중).

프로덕션 환경에서는 항상 녹색일 것입니다.

이외에도 복잡한 단계들로, Merge과 캐싱과 같은 일부 복잡한 점들이 있습니다. 이러한 내용은 복잡하며 시간이 오래 걸리고 체험해야 합니다.

GitLab 지원팀에 문의하세요. 하지만 이는 숙련된 Elasticsearch 관리자가 더 많은 경험을 가지고 있을 것입니다.

초기 인덱싱이 느린 경우

GitLab 인스턴스의 데이터가 많을수록 인덱싱에 걸리는 시간이 더 오래 걸립니다. sudo gitlab-rake gitlab:elastic:estimate_cluster_size 명령을 사용하여 클러스터 크기를 추정할 수 있습니다.

코드 문서의 경우

코드, 커밋 및 위키를 효율적으로 인덱싱하기 위해 충분한 Sidekiq 노드 및 프로세스가 있는지 확인하세요. 초기 인덱싱이 느린 경우, 전용 Sidekiq 노드 또는 프로세스를 고려해보세요.

코드가 아닌 문서의 경우

초기 인덱싱이 느린 경우에도 충분한 Sidekiq 노드 및 프로세스가 있는 경우 GitLab에서 고급 검색 워커 설정을 조정할 수 있습니다. 재큐 인덱싱 워커의 기본 값은 false입니다. 코드가 아닌 문서 인덱싱에 대한 샤드 수의 기본 값은 2입니다. 이러한 설정은 분당 2000개의 문서 인덱싱을 제한합니다.

워커 설정 조정 방법:

  1. 왼쪽 사이드바에서 맨 아래에서 관리 영역을 선택합니다.
  2. 설정 > Advanced Search를 선택합니다.
  3. 고급 검색을 확장합니다.
  4. 재큐 인덱싱 워커 확인란을 선택합니다.
  5. 코드가 아닌 문서 인덱싱용 샤드 수 텍스트 상자에 2보다 높은 값을 입력합니다.
  6. 변경 사항 저장을 선택합니다.

마이그레이션 문제

Elasticsearch 마이그레이션에 대해 읽어보세요.

마이그레이션이 중단되었고 elasticsearch.log 파일에 오류가 포함되어 있으면 이는 잠재적으로 버그/이슈일 수 있습니다. 마이그레이션을 다시 시도해도 성공하지 않는 경우 GitLab 지원팀에 에스컬레이션하세요.

parent 필드가 구성되지 않았으면 parent를 지정할 수 없습니다 오류

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 주소로 호출된 연결없이 사용자 정의 gitlab_rails['env'] 환경 변수를 설정하세요. no_proxy를 사용하세요.

내 단일 노드 Elasticsearch 클러스터 상태가 모든 것이 제대로 실행되는 것처럼 yellow에서 green으로 변경되지 않습니다

단일 노드 Elasticsearch 클러스터의 기능적 클러스터 상태는 yellow입니다 (green이 아님) - 주요 샤드는 할당되지만 다른 노드가 없어 복제본을 할당할 수 없는 경우입니다. Amazon OpenSearch 서비스를 사용하는 경우도 해당됩니다.

caution
0으로 복제본 수를 설정하는 것은 권장되지 않습니다 (GitLab Elasticsearch 통합 메뉴에서 허용되지 않음). Elasticsearch 노드를 추가할 계획이 있다면 복제본 수를 0보다 큰 정수 값으로 설정해야 합니다. 이것을 하지 않으면 장애 발생 시 (노드 하나를 잃는 경우) 이중성이 부족해집니다.

단일 노드 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"

“URL” 필드 값에 http:// 또는 https:// 중 하나를 사용하지 않은 것으로 보입니다. 사용하는 URL에 http:// 또는 https:// 중 하나를 사용하는지 확인하세요(Elasticsearch client for Go가 유효한 URL의 접두어로 사용되어야 함).

URL의 형식을 수정한 후에는 인덱스를 삭제(전용 Rake 작업을 통해)하고 인스턴스 콘텐츠를 재인덱싱하세요.

내 Elasticsearch 클러스터에 플러그인이 있고 통합이 작동하지 않는 경우

특정 타사 플러그인은 클러스터에 버그를 도입하거나 다른 이유로 인해 통합과 호환되지 않을 수 있습니다. 문제가 플러그인을 사용하는 경우를 제외하도록 플러그인을 비활성화해보세요.

Elasticsearch code_analyzer가 모든 코드 사례를 고려하지 않음

code_analyzer 패턴 및 필터 구성은 개선을 위해 평가 중입니다. 패턴 및 필터 구성 때문에 예상된 검색 결과를 반환하지 못했던 대부분의 극단적 사례는 수정되었습니다.

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

일부 이진 파일은 이름으로 검색될 수 없음

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

고급 검색은 비공개 프로젝트를 어떻게 처리하나요?

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

AWS Elasticsearch 또는 OpenSearch를 사용하여 세밀한 접근 제어를 사용할 때 역할 매핑

AWS Elasticsearch 또는 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 logs에서 워커 수를 계산하기 위해 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 사용량이 나타날 수 있습니다.

다시 색인 시 Couldn't load task status 오류

다시 색인할 때 Couldn't load task status 오류가 발생할 수 있습니다. sliceId must be greater than 0 but was [-1] 오류도 Elasticsearch 호스트에서 나타날 수 있습니다. 해결책으로 scratch에서 다시 색인하거나 GitLab 16.3으로 업그레이드를 고려해 보세요.

더 많은 정보는 issue 422938을 참조하세요.

GitLab 15.11에서 Migration 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에서 색인을 수행하는 대량 cron 워커에 대한 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>을 로그의 실제 항목으로 교체합니다.