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: '<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로 작성된 전체 텍스트 검색 라이브러리입니다.
  • Near real time (NRT): 문서를 인덱싱하는 시간과 검색할 수 있게 되는 시간 사이의 약간의 지연을 의미합니다.
  • Cluster: 모든 데이터를 보유하고 인덱싱 및 검색 기능을 제공하기 위해 함께 작동하는 하나 이상의 노드의 모음입니다.
  • Node: 클러스터의 일부로 작동하는 단일 서버입니다.
  • Index: 다소 유사한 특성을 가진 문서의 모음입니다.
  • Document: 인덱싱할 수 있는 정보의 기본 단위입니다.
  • Shards: 인덱스의 완전하고 독립적인 하위 구분입니다. 각 샤드는 사실상 Lucene 인덱스입니다.
  • Replicas: 인덱스를 중복시키는 장애 조치 메커니즘입니다.

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, 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"))

접근 문제 해결

사용자: anonymous는 다음 작업을 수행할 권한이 없습니다: es:ESHttpGet

AWS OpenSearch 또는 Elasticsearch와 함께 도메인 수준 액세스 정책을 사용할 때, AWS 역할이 올바른 GitLab 노드에 할당되지 않습니다. GitLab Rails 및 Sidekiq 노드는 검색 클러스터와 통신할 권한이 필요합니다.

사용자: anonymous는 es:ESHttpGet 작업을 수행할 권한이 없습니다. 자원 기반 정책이 es:ESHttpGet
작업을 허용하지 않기 때문입니다.

이 문제를 해결하려면, AWS 역할이 올바른 GitLab 노드에 할당되었는지 확인하세요.

자격 증명은 유효한 리전으로 제한되어야 합니다

Advanced search와 함께 AWS 권한을 사용할 때, 리전은 유효해야 합니다.

[indices:data/write/bulk] 권한 없음

IAM 역할 또는 AWS OpenSearch Dashboards를 사용하여 생성된 역할로 세밀한 액세스 제어를 사용할 때 다음 오류가 발생할 수 있습니다:

{
  "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
}

이 문제를 해결하려면 다음을 수행해야 합니다.

사용자를 역할에 매핑 AWS OpenSearch Dashboards에서.

색인화 문제 해결

색인화 문제를 해결하는 것은 어려울 수 있습니다. 매우 빠르게 GitLab 지원 또는 Elasticsearch 관리자에게 문의해야 할 수 있습니다.

시작하기 가장 좋은 방법은 빈 인덱스를 생성하는 데 문제가 있는지 확인하는 것입니다.

문제가 발생하는 경우 gitlab-production (GitLab 인덱스의 이름)이 Elasticsearch 측에 존재하는지 확인합니다.

존재하는 경우, Elasticsearch 측에서 수동으로 삭제한 후 recreate_index Rake 작업을 통해 다시 생성해 보세요.

여전히 문제가 발생하면 Elasticsearch 인스턴스에서 수동으로 인덱스를 생성해 보세요.

인덱스의 세부 정보는 여기서 중요하지 않으며, 인덱스를 생성할 수 있는지 테스트하려고 합니다.

인덱스를 생성할 수 없는 경우:

  • Elasticsearch 관리자와 대화하세요.

인덱스를 생성할 수 있는 경우, 이를 GitLab 지원팀에 전달하세요.

빈 인덱스를 생성하는 것에 문제가 없는 경우, 다음 단계는 프로젝트 색인화 중 발생하는 오류를 확인하는 것입니다.

오류가 발생하면, 이는 색인이 GitLab 측에서 발생합니다.

이를 수정해야 합니다. 익숙하지 않은 경우, GitLab 지원팀에 도움을 요청하세요.

Elasticsearch 인스턴스 내에서 발생할 수 있는 오류를 확인하세요. 오류가 문서화되고 수정 방법이 있는지 확인하세요.

그렇지 않은 경우, Elasticsearch 관리자와 대화하세요.

색인화 프로세스에서 오류가 발생하지 않으면 색인이 생성된 프로젝트의 상태를 확인하세요.

다음 Rake 작업을 통해 확인할 수 있습니다:

다음과 같은 경우:

  • 모든 것이 100%로 표시되면, GitLab 지원팀에 전달하세요. 이는 잠재적 버그/문제일 수 있습니다.
  • 100%가 아닌 항목이 보이면 해당 프로젝트를 재색인하려고 시도하세요. 이렇게 하려면, sudo gitlab-rake gitlab:elastic:index_projects ID_FROM=<project ID> ID_TO=<project 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 Search API를 통해 Elasticsearch 측에서 데이터가 나타나는지 확인하십시오:

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

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

결과가:

참고: 위 지침은 네임스페이스의 하위 집합만 인덱싱하는 시나리오에 사용되지 않습니다.

특정 유형의 데이터를 검색하는 방법에 대한 자세한 내용은 Elasticsearch Index Scopes를 참조하십시오.

모든 리포지토리가 인덱싱되었지만 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 작업자가 이 오류로 실패한다면, 일반적으로 Elasticsearch가 인덱싱 요청의 동시성을 따라잡지 못하고 있음을 의미합니다. 다음 설정을 변경하여 해결할 수 있습니다:

  • 인덱싱 처리량을 줄이려면 Bulk request concurrency를 줄일 수 있습니다 (자세한 내용은 고급 검색 설정을 참조하십시오). 기본값은 10으로 설정되어 있지만, 동시에 인덱싱 작업 수를 줄이기 위해 1로 변경할 수 있습니다.
  • Bulk request concurrency를 변경해도 효과가 없으면, 루팅 규칙 옵션을 사용하여 인덱싱 작업을 특정 Sidekiq 노드로만 제한하십시오(elasticsearch.md#index-large-instances-with-dedicated-sidekiq-nodes-or-processes). 이는 인덱싱 요청 수를 줄이는 데 도움이 됩니다.

인덱싱이 매우 느리거나 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

elasticsearch_pause_indexing 설정이 활성화되어 있음으로 인해 인덱싱이 계속 일시 중지됩니다

검색을 실행할 때 새 데이터가 감지되지 않는 것을 알 수 있습니다.

이 오류는 새 데이터가 제대로 인덱싱되지 않을 때 발생합니다.

이 오류를 해결하려면 데이터를 재인덱싱하세요.

그러나 재인덱싱할 때 인덱싱 과정이 계속 일시 중지되며 Elasticsearch 로그에 다음과 같은 메시지가 표시될 수 있습니다:

"message":"elasticsearch_pause_indexing setting is enabled. Job was added to the waiting queue"

재인덱싱이 이 문제를 해결하지 못하고 인덱싱 프로세스를 수동으로 일시 중지하지 않았다면, 이 오류는 두 GitLab 인스턴스가 하나의 Elasticsearch 클러스터를 공유하기 때문에 발생할 수 있습니다.

이 오류를 해결하려면, Elasticsearch 클러스터의 사용을 위해 하나의 GitLab 인스턴스를 연결 해제하세요.

자세한 내용은 문제 3421을 참조하세요.

인덱스를 재생성하는 최후의 수단

어쩌면 데이터가 인덱싱되지 않거나 대기열에 없거나 인덱스가 마이그레이션이 진행될 수 없는 상태일 수 있는 경우가 있습니다.

문제의 근본 원인을 찾아보는 것이 가장 좋습니다 로그보기.

최후의 수단으로, 인덱스를 처음부터 재생성할 수 있습니다.

소규모 GitLab 설치의 경우 인덱스를 재생성하는 것이 일부 문제를 해결할 수 있는 빠른 방법일 수 있습니다.

그러나 대규모 GitLab 설치의 경우 이 방법은 매우 오랜 시간이 걸릴 수 있습니다. 인덱싱이 완료될 때까지 인덱스는 올바른 검색 결과를 표시하지 않습니다.

인덱싱이 진행되는 동안 Elasticsearch 사용하기 체크박스를 지우는 것이 좋습니다.

위의 주의 사항을 모두 읽었고 진행하기로 결정했다면, 다음 Rake 작업을 실행하여 인덱스를 처음부터 다시 생성해야 합니다.

리눅스 패키지 (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 자체에서 권장하는 사항은 다음과 같습니다:

  • 비생산 인스턴스의 경우 최소 8 GB의 RAM.
  • 생산 인스턴스의 경우 최소 16 GB의 RAM.
  • 이상적으로는 64 GB의 RAM.

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

분명한 것 외에도, 샤딩이 작용합니다. 샤딩은 Elasticsearch의 핵심 부분입니다. 이는 인덱스의 수평 확장을 가능하게 하며, 많은 양의 데이터를 처리할 때 유용합니다.

GitLab이 인덱싱하는 방식으로 인해 엄청난 양의 문서가 인덱싱되고 있습니다. 샤딩을 사용하면 각 샤드가 Lucene 인덱스이기 때문에 Elasticsearch가 데이터를 찾는 속도를 높일 수 있습니다.

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

단일 샤드만 있는 인덱스는 확장성 요소가 없으며 정기적으로 호출될 때 문제가 발생할 가능성이 높습니다. Elasticsearch의 용량 계획 문서를 참조하십시오.

샤딩이 사용되고 있는지 확인하는 가장 쉬운 방법은 Elasticsearch Health API의 출력을 확인하는 것입니다:

  • 빨간색은 클러스터가 다운된 상태입니다.
  • 노란색은 샤딩/복제가 없는 상태에서 실행 중입니다.
  • 초록색은 건강한 상태(실행 중, 샤딩, 복제 중)입니다.

생산 용도로는 항상 초록색이어야 합니다.

이 단계 외에도, 병합 및 캐싱과 같은 좀 더 복잡한 점검 사항으로 넘어가게 됩니다. 이러한 사항은 복잡해질 수 있으며 배워야 할 시간이 필요하므로, 더 깊이 파고들 필요가 있는 경우 Elasticsearch 전문가에게 에스컬레이션/페어링하는 것이 좋습니다.

GitLab 지원팀에 문의해도 좋지만, 이러한 문제는 숙련된 Elasticsearch 관리자가 더 많은 경험을 가지고 있을 가능성이 큽니다.

느린 초기 인덱싱

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

코드 문서의 경우

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

코드가 아닌 문서에 대한 정보

초기 인덱싱이 느리지만 Sidekiq에 충분한 노드와 프로세스가 있는 경우,
GitLab에서 고급 검색 작업자 설정을 조정할 수 있습니다.
Requeue indexing workers의 기본 값은 false입니다.
Number of shards for non-code indexing의 기본 값은 2입니다.
이 설정은 분당 2000개의 문서로 인덱싱을 제한합니다.

작업자 설정을 조정하려면:

  1. 왼쪽 사이드바의 맨 아래에서 Admin을 선택합니다.
  2. Settings > Search를 선택합니다.
  3. Advanced Search를 확장합니다.
  4. Requeue indexing workers 체크박스를 선택합니다.
  5. Number of shards for non-code indexing 텍스트 상자에 2보다 큰 값을 입력합니다.
  6. Save changes를 선택합니다.

마이그레이션 관련 문제

Elasticsearch Migrations에 대해 읽었는지 확인하세요.

마이그레이션이 중단되었고 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 클러스터 상태가 yellow에서 green으로 변경되지 않음

단일 노드 Elasticsearch 클러스터의 기능적 클러스터 건강 상태는 yellow입니다 (결코 green이 아님) 왜냐하면 기본 샤드는 할당되지만 복제본은 할당할 다른 노드가 없기 때문에 할당될 수 없습니다. 이는 Amazon OpenSearch 서비스를 사용하는 경우에도 적용됩니다.

경고:

복제본 수를 0으로 설정하는 것은 권장되지 않습니다(이는 GitLab Elasticsearch 통합 메뉴에서 허용되지 않습니다). 총 1개 이상의 Elasticsearch 노드를 추가할 계획이라면 복제본 수는 0보다 큰 정수 값으로 설정해야 합니다. 그렇게 하지 않으면 불필요성이 발생하여(노드 1개가 손실되면 인덱스가 손상됨) 문제를 발생시킵니다.

단일 노드 Elasticsearch 클러스터에 대한 녹색 상태가 꼭 필요하다면, 이전 단락에서 설명된 위험을 이해한 후 아래 쿼리를 실행하여 복제본 수를 0으로 설정하세요(클러스터는 더 이상 샤드 복제본을 생성하려고 시도하지 않습니다):

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

오류: 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://를 사용하지 않았을 것입니다. 이 필드에서 Elasticsearch Go 클라이언트가 유효한 것으로 수락될 URL의 접두사가 필요합니다.

URL 형식을 수정한 후, 인덱스를 삭제하고( 전용 Rake 작업을 통해) 인스턴스의 내용을 다시 인덱싱하세요.

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

일부 3rd 파티 플러그인은 클러스터에 버그를 유발하거나 다양한 이유로 우리의 통합과 호환되지 않을 수 있습니다. 플러그인이 문제를 유발하고 있다는 가능성을 배제할 수 있도록 플러그인을 비활성화해 보세요.

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

code_analyzer 패턴 및 필터 구성은 개선을 위해 평가되고 있습니다. 우리는 패턴 및 필터 구성으로 인해 예상된 검색 결과를 반환하지 않았던 대부분의 엣지 케이스를 수정했습니다.

code_analyzer의 패턴 및 필터 개선에 대해 에픽 3621에서 논의하고 있습니다.

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

GitLab 13.9에서 이진 파일 이름이 인덱싱되는 변경이 있었습니다. 그러나 모든 프로젝트의 데이터를 처음부터 인덱싱하지 않으면, GitLab 13.9 릴리즈 이후에 추가되거나 업데이트된 이진 파일만 검색할 수 있습니다.

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

고급 검색은 모든 프로젝트를 같은 Elasticsearch 인덱스에 저장하지만,

검색 결과는 사용자에게 볼 수 있는 결과만 표시합니다.

고급 검색은 검색 시점에 사용자가 접근할 수 없는 프로젝트를 필터링하여 애플리케이션의 모든 권한 체크를 존중합니다.

Elasticsearch 작업자가 Sidekiq를 과부하 시킵니다

일부 경우 Elasticsearch는 다음과 같은 이유로 GitLab에 더 이상 연결할 수 없습니다:

  • 한쪽에서만 Elasticsearch 비밀번호가 업데이트되었습니다 (Unauthorized [401] ... 사용자 인증 실패 오류).
  • 방화벽 또는 네트워크 문제로 인해 연결이 손상되었습니다 (<ip>:9200에서 TCP 연결을 열 수 없음 오류).

이 오류는 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는 이전 작업이 실패할 경우 자주 재인덱싱을 시도하기 때문입니다.

fast-stats 또는 jq를 사용하여 Sidekiq 로그에서 작업자 수를 계산할 수 있습니다:

$ 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 사용량을 보여줄 것입니다.

오류: 작업 상태를 불러올 수 없습니다

재인덱싱을 수행하면 작업 상태를 불러올 수 없습니다 오류가 발생할 수 있습니다. sliceId는 0보다 커야 하지만 [-1] 오류가 Elasticsearch 호스트에서 발생할 수도 있습니다. 해결 방법으로 처음부터 재인덱싱을 고려하거나 GitLab 16.3으로 업그레이드하세요.

자세한 내용은 이슈 422938를 참조하세요.

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

GitLab 15.11에서, BackfillProjectPermissionsInBlobs 마이그레이션이 다음 오류 메시지로 중단될 수 있습니다:

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>를 로그에 있는 실제 항목으로 교체하세요.