Kibana#

Kibana를 사용하여 Elasticsearch 클러스터와 상호작용할 수 있습니다.

다운로드 안내를 참조하세요.

인덱스 상태 확인#

bundle exec rake gitlab:elastic:info

를 실행하여 클러스터의 상태와 정보를 확인할 수 있습니다.

처음부터 모든 인덱스를 생성하고 로컬 데이터로 채우기#

옵션 1: Rake task#

bundle exec rake gitlab:elastic:index

를 실행하면 Search::Elastic::TriggerIndexingWorker가 비동기로 실행됩니다.

Elastic::ProcessInitialBookkeepingService.new.execute

를 [0, 0]이 표시될 때까지 반복 실행합니다. [0, 0]은 큐에 더 이상 ref가 없음을 의미합니다.

옵션 2: 수동#

Search::Elastic::TriggerIndexingWorker의 단계를 수동으로 실행합니다.

Sidekiq이 job을 올바르게 가져오지 못하는 경우가 있어 Sidekiq을 재시작해야 할 수도 있습니다. Rails 콘솔에서 단계를 실행하려면 다음을 사용하세요:

task_executor_service = Search::RakeTaskExecutorService.new(logger: ::Gitlab::Elasticsearch::Logger.build)
task_executor_service.execute(:recreate_index)
task_executor_service.execute(:clear_index_status)
task_executor_service.execute(:clear_reindex_status)
task_executor_service.execute(:resume_indexing)
task_executor_service.execute(:index_namespaces)
task_executor_service.execute(:index_projects)
task_executor_service.execute(:index_snippets)
task_executor_service.execute(:index_users)

Elastic::ProcessInitialBookkeepingService.new.execute

를 [0, 0]이 표시될 때까지 반복 실행합니다. [0, 0]은 큐에 더 이상 ref가 없음을 의미합니다.

옵션 3: 재인덱싱 task#

먼저 기존 인덱스를 삭제한 다음, 타깃으로 지정할 인덱스에 대한 ReindexingTask를 생성합니다. 이렇게 하면 현재 구성을 기반으로 새 인덱스가 생성되고 데이터가 복사됩니다.

Search::Elastic::ReindexingTask.create!(targets: %w[MergeRequest])

ElasticClusterReindexingCronWorker.new.perform

를 실행하고 다음이 success가 될 때까지 반복합니다.

Search::Elastic::ReindexingTask.last.state

인덱스 데이터#

데이터베이스 레코드를 추가하고 인덱싱하려면 track! 메서드를 호출하고 bookkeeper를 실행합니다:

Elastic::ProcessBookkeepingService.track!(MergeRequest.first)
Elastic::ProcessBookkeepingService.track!(*MergeRequest.all)

Elastic::ProcessBookkeepingService.new.execute

종속 연관 인덱스 업데이트#

elastic_index_dependant_association을 사용하면 특정 필드가 변경될 때 인덱스의 연관 레코드를 자동으로 업데이트할 수 있습니다. 예를 들어 프로젝트의 visibility_level이 변경될 때 모든 work item을 재인덱싱하려면 다음을 사용합니다:

  elastic_index_dependant_association :work_items, on_change: :visibility_level, depends_on_finished_migration: :add_mapping_migration

depends_on_finished_migration 파라미터는 선택 사항으로, 지정된 고급 검색 마이그레이션이 완료된 후에만 업데이트가 수행되도록 합니다(예: 매핑에 필요한 필드를 추가하는 마이그레이션).

테스트#

Elasticsearch 테스트는 모든 머지 리퀘스트에서 실행되지 않습니다. Elasticsearch 및 PostgreSQL 운영 버전으로 테스트를 실행하려면 머지 리퀘스트에 ~pipeline:run-search-tests 또는 ~group::global search 라벨을 추가하세요.

고급 검색 마이그레이션#

인덱스 매핑을 변경하는 마이그레이션 테스트#

• 인덱스에 이미 변경 사항이 적용되지 않았는지 확인하세요. 마이그레이션 cron worker는 백그라운드에서 실행되므로 마이그레이션이 이미 적용되었을 수 있습니다.

선택 사항. GitLab 18.0 이상에서 마이그레이션 worker를 비활성화하려면 다음 명령을 실행합니다:

  settings = ApplicationSetting.last # 이 설정이 `nil`을 반환하지 않는지 확인하세요
  settings.elastic_migration_worker_enabled = false
  settings.save!

• 마이그레이션이 보류 중인지 확인합니다: ::Elastic::DataMigrationService.pending_migrations.

• 마이그레이션이 완료되지 않았는지 확인합니다: Elastic::DataMigrationService.pending_migrations.first.completed?.

• 매핑이 아직 적용되지 않았는지 확인합니다.

  Kibana에서 GET gitlab-development-some-index/_mapping을 확인하거나

• curl 요청을 보냅니다: curl "http://localhost:9200/gitlab-development-some-index/_mappings" | jq

• 로그 메시지를 확인하기 위해 로그를 추적합니다: tail -f log/elasticsearch.log.

• 다음 중 하나의 방법으로 마이그레이션을 실행합니다:

  Elastic::MigrationWorker.new.perform 마이그레이션 worker를 실행합니다. GitLab 18.0 이상에서는 elastic_migration_worker_enabled 애플리케이션 설정이 활성화되어 있어야 합니다.

• 보류 중인 마이그레이션 사용: ::Elastic::DataMigrationService.pending_migrations.first.migrate.

• 버전 사용: Elastic::DataMigrationService[20250220214819].migrate (버전을 마이그레이션 버전으로 교체).

• 마이그레이션 상태를 확인합니다.

  Kibana에서 마이그레이션 레코드 확인: GET gitlab-development-migrations/_doc/20250220214819 (버전 변경). 여기에는 시작 시간과 상태 등의 정보가 포함됩니다.

• Kibana에서 매핑이 변경되었는지 확인합니다: GET gitlab-development-some-index/_mapping.

쿼리 변경 분석#

개발자는 GitLab 스테이징 Rails 콘솔을 사용하여 코드 리뷰 시 변경 전후 쿼리를 비교하는 데 도움을 받을 수 있습니다.

Rails 콘솔에서 Gitlab::Search::Client를 사용하여 쿼리를 구성할 수 있습니다.

헬퍼를 사용한 예시 쿼리는 다음과 같습니다:

  Gitlab::Search::Client.new.search(
    index: 'gitlab-production-vulnerabilities',
    routing: 'group_110', # 데이터는 샤드에 분산되어 있으며 쿼리 빌더가 라우팅 정보를 전달합니다.
    body: {
      query: {
        term: { vulnerability_id: 4356 }
      }
    }
  )