正式なドキュメントは英語版であり、この日本語訳はAI支援翻訳により作成された参考用のものです。日本語訳の一部の内容は人間によるレビューがまだ行われていないため、翻訳のタイミングにより英語版との間に差異が生じることがあります。最新かつ正確な情報については、英語版をご参照ください。

Elasticsearchの移行のトラブルシューティング

  • プラン: Premium、Ultimate
  • 提供形態: GitLab Self-Managed、GitLab Dedicated

Elasticsearchの移行の作業時に、以下のイシューが発生する可能性があります。

elasticsearch.logにエラーが含まれており、失敗した移行を再試行しても機能しない場合は、GitLabサポートにお問い合わせください。詳細については、高度な検索の移行を参照してください。

エラー: Elasticsearch::Transport::Transport::Errors::BadRequest

同様の例外が発生した場合は、正しいElasticsearchのバージョンがあり、システム要件を満たしていることを確認してください。sudo gitlab-rake gitlab:checkコマンドを使用して、バージョンを自動的に確認することもできます。

エラー: Faraday::TimeoutError (execution expired)

プロキシを使用する場合は、ElasticsearchホストのIPアドレスを使用して、gitlab_rails['env']環境変数no_proxyという名前のカスタムを設定します。

シングルノードElasticsearchクラスターのステータスが黄色から緑に変わらない

シングルノードElasticsearchクラスターの場合、機能クラスターのヘルスステータスは黄色です(緑にはなりません)。その理由は、プライマリシャードが割り当てられていますが、Elasticsearchがレプリカを割り当てることができる他のノードが存在しないため、レプリカを割り当てることができないためです。これは、Amazon OpenSearchサービスを使用している場合にも当てはまります。

レプリカの数を0に設定することはお勧めしません(これはGitLab Elasticsearchインテグレーションメニューでは許可されていません)。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://を使用していない可能性があります。使用しているGo用ElasticsearchクライアントURLのプレフィックスが有効として受け入れられる必要があるため、このフィールドでhttp://またはhttps://のいずれかを使用していることを確認してください。URLの書式を修正したら、インデックスを削除して、インスタンスのコンテンツをインデックス作成し直してください。

Elasticsearchは一部のサードパーティ製プラグインでは機能しません

特定のサードパーティ製プラグインは、クラスターにバグを導入したり、インテグレーションと互換性がない可能性があります。

Elasticsearchクラスターにサードパーティ製プラグインがあり、インテグレーションが機能しない場合は、プラグインを無効にしてみてください。

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が頻繁にインデックス作成を再試行するため、はるかに頻繁に表示される可能性があります。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使用量を示します。

エラー: Couldn't load task status

インデックス作成し直すと、Couldn't load task statusエラーが発生する可能性があります。sliceId must be greater than 0 but was [-1]エラーもElasticsearchホストに表示される場合があります。回避策として、インデックスをゼロから再作成するか、GitLab 16.3にアップグレードすることを検討してください。

詳細については、issue 422938を参照してください。

エラー: migration has failed with NoMethodError:undefined method

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>をログの実際のエントリに置き換えます。