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 콘솔이나 Elasticsearch 통합에 설정이 되었는지 확인하려면 다음과 같은 명령을 실행하세요: 

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:<port>"

# 변경 저장
es_url.save!

로그 보기

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

  1. sidekiq.log - 색인화는 모두 Sidekiq에서 수행되므로 Elasticsearch 통합에 대한 관련 로그의 대부분이 이 파일에 있습니다.
  2. elasticsearch.log - 여기에는 Elasticsearch에 특화된 추가 로그가 있어 검색, 인덱싱 또는 마이그레이션과 관련된 유용한 진단 정보가 포함될 수 있습니다.

다음은 일반적인 문제사항 및 해결 방법입니다.

일반 용어

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

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

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

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

  • 설정 > 고급 검색에서 Admin Area 아래에서 고급 검색 설정이 확인됩니다.

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

    ::Gitlab::CurrentSettings.elasticsearch_search?         # 검색에 Elasticsearch가 사용되는지 여부
::Gitlab::CurrentSettings.elasticsearch_indexing?       # 콘텐츠가 Elasticsearch에 색인화되는지 여부
::Gitlab::CurrentSettings.elasticsearch_limit_indexing? # 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 관리자에게 빠르게 문의해야합니다.

시작하는 가장 좋은 위치는 빈 인덱스를 만드는 문제인지 여부를 결정하는 것입니다. 그렇다면 gitlab-production (GitLab 인덱스의 이름)가 존재하는지 확인하고 있으면 Elasticsearch 측에서 매뉴얼으로 삭제하고 recreate_index Rake 작업에서 다시 만들어보세요.

여전히 문제가 있다면 Elasticsearch 인스턴스에서 인덱스를 매뉴얼으로 만들어보세요. 여기서 인덱스의 세부 정보는 중요하지 않습니다. 인덱스를 만들 수 있는지 테스트하려는 것입니다.

  • 만들 수 없으면 Elasticsearch 관리자에게 문의하세요.
  • 만들 수 있다면 이를 GitLab 지원에게 Eskalte하세요.

빈 인덱스 생성 문제가 아니라면 다음 단계는 프로젝트의 색인화 중에 오류가 있는지 확인하는 것입니다. 오류가 발생하면 다음 중 하나에서 발생합니다.

  • GitLab 측의 문제. 그것을 해결해야합니다. 익숙하지 않다면 GitLab 지원팀에게 지원을 요청하세요.
  • Elasticsearch 인스턴스 자체 내에서. 문제가 문서화되어 고칠 수 있는지 분석하세요. 그렇지 않으면 Elasticsearch 관리자에게 문의하세요.

색인 과정에 오류가 없으면 색인된 프로젝트의 상태를 확인하세요. 이를 위해 다음의 Rake 작업을 사용할 수 있습니다:

만약:

  • 모든 것이 100%를 보여주고 있다면 GitLab 지원팀에게 Eskalte하세요. 이것은 잠재적인 버그/문제일 수 있습니다.
  • 100%가 아닌 항목이 있다면 해당 프로젝트에 대해 다시 색인화를 시도하세요. 이를 위해 sudo gitlab-rake gitlab:elastic:index_projects ID_FROM=<project ID> ID_TO=<project ID>를 실행하세요.

프로젝트를 다시 색인화하면:

  • GitLab 측에서 오류가 발생하면 GitLab 지원팀에게 Esklate하세요.
  • Elasticsearch에서 오류가 발생하지 않거나 전혀 오류가 표시되지 않는 경우 Elasticsearch 관리자에게 인스턴스를 확인하도록 문의하세요.

GitLab을 업데이트한 후에 아무것도 찾을 수 없어요

우리는 계속해서 색인 전략을 업데이트하고 더 최신 버전의 Elasticsearch를 지원하도록 노력합니다. 색인 변경이 이루어지면 GitLab을 업데이트한 후 재색인이 필요할 수 있습니다.

모든 리포지터리를 색인했지만 UI에서 검색어에 대한 결과가 나오지 않아요

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

UI 검색에서 결과가 나오지 않는 경우, rails console(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 호출도 가능합니다.

만약 결과가:

  • 일치한다면, 지원되는 구문을 사용하는지 확인하세요. 고급 검색은 정확한 부분 문자열 일치을 지원하지 않습니다.
  • 일치하지 않는다면, 프로젝트에서 생성된 문서에 문제가 있음을 나타냅니다. 해당 프로젝트를 재색인하는 것이 가장 좋습니다.
note
위 지침은 특정 네임스페이스의 하위 집합만 색인화하는 경우에는 사용하지 마십시오.

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

모든 리포지터리를 색인했지만 Elasticsearch 서버를 변경한 후에 아무것도 찾을 수 없어요

데이터베이스, 리포지터리 및 위키를 모두 재색인하려면 모든 레이크 작업을 다시 실행해아합ㄴ디ㅏ.

색인화되지 않은 프로젝트가 있지만 어떤 것인지 모르겠어요

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

코드를 푸시할 때 Elasticsearch 색인에 새 데이터가 추가되지 않아요

note
이 문제는 GitLab 13.2보다 높은 버전에서 사용할 수 있는 레이크 작업이 수정되었습니다.

블롭의 초기 색인화를 수행할 때 모든 프로젝트를 잠그고 색인화가 완료될 때까지 기다립니다. 프로세스 중에 오류로 인해 하나 이상의 프로젝트가 여전히 잠겨 있는 경우가 있을 수 있습니다. 이를 해제하려면 다음과 같이 실행하세요: 

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

인덱스를 처음부터 재생성하는 최후 수단

데이터가 인덱싱되지 않은 경우나 대기열에 없거나 마이그레이션 작업이 진행되지 않는 상태일 수 있습니다. 문제의 원인을 해결하기 위해 로그를 보는 것이 가장 좋습니다.

최후의 수단으로 인덱스를 처음부터 다시 만들 수 있습니다. 소규모 GitLab 설치의 경우 인덱스 다시 생성은 일부 문제를 해결하는 빠른 방법일 수 있습니다. 그러나 대규모 GitLab 설치의 경우 이 방법은 매우 긴 시간이 걸릴 수 있습니다. 색인화가 완료될 때까지 올바른 검색 결과가 표시되지 않습니다. 색인화 중에는 색인화가 실행 중인 검색 결과가 정확하지 않음을 나타내는 Elasticsearch 사용으로 검색 확인란을 지워 둘 수 있습니다.

위 주의사항을 확실히 읽고 진행하려면 다음 레이크 작업을 실행해야 합니다.

Linux package (Omnibus)
# 경고: 위 설명을 읽기 전까지 실행하지 마십시오
sudo gitlab-rake gitlab:elastic:index
Self-compiled (source)
# 경고: 위 설명을 읽기 전까지 실행하지 마십시오
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가 별도의 서버에서 실행되어야 합니다 (Logstash 및 Kibana와 결합할 수도 있음).

Elasticsearch에서 RAM은 핵심 리소스입니다. Elasticsearch에서는 다음을 권장합니다:

  • 비 프로덕션 인스턴스에는 적어도 8GB의 RAM 필요
  • 프로덕션 인스턴스에는 적어도 16GB의 RAM 필요
  • 이상적으로는 64GB의 RAM이 필요

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

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

GitLab이 인덱싱하는 방식으로 보면 막대한 양의 문서가 인덱싱됩니다. Sharding을 사용함으로써 각 샤드가 Lucene 인덱스인 채로 데이터를 찾는 속도를 높일 수 있습니다.

만약 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입니다. 이러한 설정으로 1분당 2000개의 문서만 인덱싱됩니다.

워커 설정을 조정하려면:

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

마이그레이션 문제

Elasticsearch 마이그레이션에 대해 읽어보십시오.

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

Can't specify parent if 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 주소를 사용하여 사용자 지정 gitlab_rails['env'] 환경 변수를 설정하고 no_proxy로 호출합니다.

단일 노드 Elasticsearch 클러스터 상태가 노란색에서 초록색으로 전환되지 않음

단일 노드 Elasticsearch 클러스터의 상태는 주 섀드는 할당되지만 복제본은 다른 노드가 없어 Elasticsearch가 복제본을 할당할 수 없기 때문에 노란색으로 표시됩니다. Amazon OpenSearch 서비스를 사용하는 경우도 마찬가지입니다.

caution
복제본 수를 0으로 설정하는 것은 권장되지 않습니다 (GitLab Elasticsearch 통합 메뉴에서 허용되지 않음). Elasticsearch 노드를 추가할 계획이라면 (Elasticsearch를 1개 이상 사용하는 경우) 복제본 수는 0보다 큰 정수 값으로 설정해야 합니다. 그렇지 않으면 장애가 발생했을 때 신뢰성이 부족합니다 (노드 하나를 잃으면 인덱스가 손상됩니다).

단일 노드 Elasticsearch 클러스터의 상태를 초록색으로 설정하는 것이 절대적으로 필요한 경우, 이전 단락에서 설명한 위험 사항을 이해하고 나서 다음 조회를 실행하여 복제본 수를 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://를 사용하지 않은 것 같습니다. 사용 중인 Elasticsearch 클라이언트 for Go는 유효한 URL의 접두사로 사용되어야만합니다. URL 형식을 올바르게 수정한 후, 인덱스를 삭제(via 전용 Rake 작업)하고 인스턴스의 콘텐츠를 다시 인덱싱하십시오.

Elasticsearch 클러스터에 플러그인이 있고 통합이 작동하지 않음

특정 3rd party 플러그인은 클러스터에 버그를 도입하거나 통합과 호환되지 않을 수 있습니다. 문제가 플러그인에 의해 발생하는지 확인하려면 플러그인을 비활성화해 보세요.

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 사용량이 표시됩니다.

reindexing 시 작업 상태를 로드할 수 없음 오류

reindexing을 할 때 작업 상태를 로드할 수 없음 오류가 발생할 수 있습니다. 또한 Elasticsearch 호스트에서 sliceId must be greater than 0 but was [-1] 오류가 발생할 수도 있습니다. 이 문제를 해결하기 위해서는 처음부터 다시 reindexing을 고려하거나 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>"
duplicate_key = "resque:gitlab:#{idempotency_key}:cookie:v2"
Gitlab::Redis::Queues.with { |c| c.del(duplicate_key) }

  2. <로그 항목에서 가져온 idempotency_key>를 실제 로그 항목으로 대체합니다.