Elasticsearch 문제 해결


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

Elasticsearch 문제 해결에는 다음 정보를 사용하십시오.

레일스 콘솔에서 구성 설정

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

속성 목록

모든 사용 가능한 속성을 나열하려면 다음을 실행하십시오.

  1. 레일스 콘솔 열기 (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)

속성 가져오기

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://<username>:<password>@your.es.host:<port>"

# 변경 사항 저장
es_url.save!

로그 보기

Elasticsearch 통합 문제 해결에 가장 유용한 도구 중 하나는 로그입니다. 이 통합에 대한 가장 관련된 로그는 다음과 같습니다.

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

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

일반 용어

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

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

이를 위해 몇 가지 방법이 있습니다.

  • 검색을 수행할 때 검색 결과 페이지의 오른쪽 상단에 고급 검색이 활성화됨이 표시됩니다. 이는 현재 프로젝트/네임스페이스가 Elasticsearch를 사용하는지 항상 올바르게 식별합니다.
  • Admin 영역에서 설정 > 검색에서 고급 검색 설정을 확인하십시오.
  • 필요한 경우 레일스 콘솔에서 해당 설정을 얻을 수 있습니다: 
::Gitlab::CurrentSettings.elasticsearch_search?         # 검색에 Elasticsearch를 사용하는지 여부
::Gitlab::CurrentSettings.elasticsearch_indexing?       # 컨텐츠를 Elasticsearch에 색인하고 있는지 여부
::Gitlab::CurrentSettings.elasticsearch_limit_indexing? # Elasticsearch가 특정 프로젝트/네임스페이스에만 제한되었는지 여부
  • 레일스 콘솔에 액세스하여 검색이 Elasticsearch를 사용하는지 확인하십시오. 
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가 사용되고 있는지 확인해야 하는 경우 레일스 콘솔을 사용하십시오. 
::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"))

액세스 문제 해결

User: anonymous is not authorized to perform: es:ESHttpGet

AWS OpenSearch 또는 Elasticsearch와 도메인 수준의 액세스 정책을 사용할 때 GitLab 레일스 및 Sidekiq 노드에 AWS 역할이 할당되지 않는 경우 발생합니다. GitLab 레일스 및 Sidekiq 노드에는 검색 클러스터와 통신할 권한이 있어야 합니다. 

User: anonymous is not authorized to perform: es:ESHttpGet because no resource-based policy allows the es:ESHttpGet
action

이를 해결하려면 AWS 역할이 올바른 GitLab 노드에 할당되었는지 확인하십시오.

Credential should be scoped to a valid region

고급 검색과 함께 AWS 인증을 사용할 때 지역이 유효해야 합니다.

No permissions for [indices:data/write/bulk]

AWS OpenSearch 대시보드를 사용하여 IAM 역할이나 AWS 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
}

이를 해결하려면 AWS OpenSearch 대시보드에서 역할을 사용자에 매핑해야 합니다.

색인화 문제 해결

색인화 문제를 해결하는 것은 까다로울 수 있습니다. 그 문제는 빠르게 GitLab 지원팀이나 Elasticsearch 관리자 측으로 이어질 수 있습니다.

시작하는 가장 좋은 곳은 빈 색인을 생성하는 문제인지 여부를 확인하는 것입니다. 그렇다면, gitlab-production (GitLab 색인의 이름)이 존재하는지 여부를 결정하기 위해 Elasticsearch 측에서 확인하세요. 존재한다면 Elasticsearch 측에서 수동으로 삭제한 후, recreate_index Rake 작업을 통해 다시 만들어 보세요.

여전히 문제가 발생한다면 Elasticsearch 인스턴스에서 수동으로 색인을 만들어보세요. 여기서 색인의 세부사항은 중요하지 않습니다. 우리가 원하는 것은 색인이 만들어지는지를 테스트하는 것입니다. 색인이:

  • 만들어지지 않으면 Elasticsearch 관리자에게 문의하세요.
  • 만들어진다면, 이 문제를 GitLab 지원팀에 Esklate하세요.

빈 색인을 생성하는 문제가 아니라면, 다음 단계는 프로젝트를 색인화하는 중에 오류가 있는지 확인하는 것입니다. 만약 오류가 발생한다면, 그 오류는 다음 중 하나에서 기인합니다:

  • GitLab 측의 문제. 그것들을 정정해야 합니다. 만약 익숙치 않다면, 지도를 얻기 위해 GitLab 지원팀에 문의하세요.
  • Elasticsearch 인스턴스 자체의 문제. 그 오류가 문서화되어 있고, 해결책이 있다면 확인하세요. 그렇지 않다면, Elasticsearch 관리자에게 문의하세요.

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

만약:

  • 모든 것이 100%로 표시된다면, GitLab 지원팀에 Esklate하세요. 이것은 잠재적인 버그/문제일 수 있습니다.
  • 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 검색 결과에서 결과가 없다면, 레일즈 콘솔 (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 검색 API를 통해 확인하세요: 

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 노드에서의 색인화 작업만 제한하는 것이 가능합니다. 이로써 색인화 요청의 수를 줄일 수 있습니다.

coordinating operation 메시지로 인해 색인화가 매우 느리거나 실패하는 경우

Elasticsearch 노드에서 거부된 bulk 요청은 부하 및 충분한 메모리 부족으로 인해 발생할 수 있습니다. 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 setting is enabled과 함께 색인화가 일시 중단되는 경우

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

이 에러는 새로운 데이터가 올바르게 색인화되지 않을 때 발생합니다.

이 에러를 해결하려면 데이터를 다시 색인화하십시오.

그러나 색인화를 다시 시도하면 색인화 프로세스가 일시 중단되고 Elasticsearch 로그에 다음 내용이 표시됩니다: 

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

색인화가 이 문제를 해결하지 못하고 색인화 프로세스를 수동으로 일시 중단하지 않은 경우, 이 에러가 발생할 수 있습니다. 이 에러를 해결하려면 두 개의 GitLab 인스턴스가 동일한 Elasticsearch 클러스터를 공유하는 경우입니다.

이 에러를 해결하려면 한 GitLab 인스턴스를 Elasticsearch 클러스터 사용에서 분리하십시오.

추가 정보는 issue 3421를 참조하십시오.

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

어떤 경우엔 데이터가 어떤 이유로 색인화되지 않고 대기열에 없거나, 마이그레이션에 진행이 안되는 상태일 수 있습니다. 문제의 근본 원인을 해결하기 위해 로그를 확인하는 것이 항상 가장 좋습니다.

최후의 수단으로, 인덱스를 처음부터 다시 만들 수 있습니다. 작은 GitLab 설치의 경우, 인덱스를 다시 만드는 것은 일부 문제를 빠르게 해결할 수 있는 방법입니다. 그러나 대규모 GitLab 설치의 경우, 이 방법은 매우 오랜 시간이 걸릴 수 있습니다. 색인화가 완료될 때까지 인덱스는 올바른 검색 결과를 표시하지 않습니다. 색인화가 진행 중일 때 Search with Elasticsearch enabled 체크 상자를 해제할 수 있습니다.

위의 주의 사항을 확실히 숙지하고 진행하고자 하는 경우, 다음 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 hardware guide를 참조하십시오.

명백한 것 이상으로, 샤딩이 중요합니다. 샤딩은 Elasticsearch의 핵심 부분이며 인덱스의 수평 스케일링을 가능하게 합니다. 이것은 대량의 데이터를 처리할 때 유용합니다.

GitLab이 색인화를 수행하는 방식으로 보아, 많은 문서가 색인화됩니다. 샤딩을 사용하면 각 샤드가 Lucene 인덱스이기 때문에 Elasticsearch가 데이터를 빠르게 찾도록 도울 수 있습니다.

샤딩을 사용하지 않으면, 프로덕션 환경에서 Elasticsearch를 사용하기 시작할 때 문제가 발생할 수 있습니다.

한 개의 샤드만 있는 인덱스는 **스케일 요소가 없으며, 정기적으로 호출될 때 문제가 발생할 가능성이 높습니다. 용량 계획을 확인하십시오.

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

  • Red는 클러스터가 중단됨을 의미합니다.
  • Yellow는 샤딩/복제를 사용하지 않고 사용 가능함을 의미합니다.
  • Green은 건강한 상태임을 의미합니다 (가동 중, 샤딩, 복제).

프로덕션 환경에서는 항상 Green 상태이어야 합니다.

이러한 단계 이상으로, 병합 및 캐싱과 같은 보다 복잡한 사항이 나오게 됩니다. 이 부분들은 복잡해지며 학습에 시간이 소요되므로, 더 심층적으로 파악해야 할 필요가 있다면 Elasticsearch 전문가와 함께 역량을 공유하는 것이 좋습니다.

GitLab 지원팀에 문의하십시오. 그러나 Elasticsearch 관리자가 더 많은 경험을 가지고 있을 것으로 예상됩니다.

초기 인덱싱 지연

GitLab 인스턴스에 데이터가 많을수록 인덱싱에 걸리는 시간이 길어집니다. 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 지원팀에 문의하세요.

오류: 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 (실행 만료)

프록시를 사용하는 경우, 자체의 no_proxy라는 gitlab_rails['env'] 환경 변수를 설정하세요.

내 단일 노드 Elasticsearch 클러스터 상태가 노랑에서 녹색으로 전환이 되지 않습니다.

단일 노드 Elasticsearch 클러스터의 기능적인 클러스터 상태는 노랑입니다(녹색이 아님) - 기본 샤드는 할당되었지만 복제본은 할당할 노드가 없기 때문입니다. 이것은 Amazon OpenSearch 서비스를 사용하는 경우도 적용됩니다.

경고: 복제본 수를 0으로 설정하는 것은 권장되지 않습니다(GitLab Elasticsearch 통합 메뉴에서 허용되지 않음). Elasticsearch 노드를 더 추가할 계획이라면(총 1개 이상의 Elasticsearch에), 복제본 수를 0보다 큰 정수 값으로 설정해야 합니다. 이를 수행하지 않으면 장애가 발생했을 때 비중복성이 발생합니다(노드 하나를 잃으면 인덱스가 손상됩니다).

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

“URL” 필드 값에 http:// 또는 https:// 중 하나를 사용하지 않은 것일 가능성이 높습니다. 사용하는 URL에 http:// 또는 https:// 중 하나를 사용하는지 확인하세요(Elasticsearch client for Go는 유효한 URL인 것으로 인식하기 위해 URL에 접두사가 필요합니다). URL의 형식을 올바르게 수정한 후에 인덱스를 삭제(전용 라켓 테스크를 통해)하고 인스턴스의 내용을 다시 색인하세요.

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

특정 3rd party 플러그인은 귀하의 클러스터에 버그를 발생시킬 수 있거나
무엇인가의 이유로 통합과 호환되지 않을 수 있습니다. 플러그인이 문제를
일으키고 있는 가능성을 제외하기 위해 플러그인을 비활성화해 보아야 합니다.

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

code_analyzer 패턴 및 필터 구성이 개선을 위해 평가 중에 있습니다.
패턴 및 필터 구성으로 인해 예상된 검색 결과를 반환하지 않았던
대부분의 특이 케이스를 수정했습니다(most edge cases).

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

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

GitLab 13.9에서 이진 파일 이름이 색인 되도록 변경되었습니다.
그러나 GitLab 13.9 릴리스 이후에 추가되거나 업데이트된 이진 파일만이 검색 가능합니다.

고급 검색이 개인 프로젝트를 처리하는 방법

고급 검색은 모든 프로젝트를 동일한 Elasticsearch 인덱스에 저장하지만,
사용자가 볼 수 있는 결과만 표시하도록 필터링하여 응용 프로그램의 모든 권한 확인을 본격적으로
따르게 됩니다.

Elasticsearch 워커가 Sidekiq을 과부하시킵니다

일부 경우에 Elasticsearch가 더 이상 GitLab에 연결할 수 없어서 발생하는
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가 자주 재색인을 시도하므로 더 자주 발생합니다.
Sidkiq 로그에서 워커를 계산하려면
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 사용량을 표시할 것입니다.

오류: 작업 상태를 불러올 수 없음

재색인을 할 때 작업 상태를 불러올 수 없음 오류가 발생할 수 있습니다.
Elasticsearch 호스트에서는 sliceId must be greater than 0 but was [-1] 오류가 나타날 수 있습니다.
해결책으로는 scratch에서 재색인할 것을 고려하거나
GitLab 16.3로 업그레이드해야 합니다.

자세한 내용은 issue 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 작업이 deduplication에 걸렸습니다

GitLab 16.5 및 이전 버전에서 ElasticIndexInitialBulkCronWorker 및 ElasticIndexBulkCronWorker
작업이 deduplication에 걸릴 수 있습니다.
새로운 인덱스를 만든 후에도 이 문제가 계속될 수 있으며, 이로 인해 고급 검색이 문서를 적절하게 색인하지 못할 수 있습니다.
GitLab 16.6에서 idempotent!가 삭제되었습니다(removed).

Sidekiq 로그에는 다음과 같은 항목이 포함될 수 있습니다: shell {"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. 레일즈 콘솔 세션에서
    다음 명령을 실행하십시오: 

    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>을 대체하십시오.