mongot 配置のトラブルシューティング

診断情報の収集

特定のシナリオに取り組む前に、mongot ノードの現在の状態、そのログ、および最近の Kubernetes イベントを収集します。

# Check the status and restart count of the mongot podkubectl get pods -n ${MDB_NS} --context ${K8S_CTX} | grep search
# Review the most recent mongot logskubectl logs statefulset/${MDB_RESOURCE_NAME}-search-0 \  -n ${MDB_NS} --context ${K8S_CTX} --tail=100
# Inspect the MongoDBSearch resource status and conditionskubectl describe mongodbsearch ${MDB_RESOURCE_NAME} \  -n ${MDB_NS} --context ${K8S_CTX}
# List recent events in the namespacekubectl get events -n ${MDB_NS} --context ${K8S_CTX} \  --sort-by='.lastTimestamp'

ポッドがループ内で再起動する場合は、前のコンテナインスタンスのログを表示して、再起動の原因となったエラーを捕捉します。

kubectl logs statefulset/${MDB_RESOURCE_NAME}-search-0 \  -n ${MDB_NS} --context ${K8S_CTX} --previous

リソースの状態を使用して問題をローカル化する

MongoDBSearch リソースはいくつかの独立したコンポーネントを実行します。

• 1 つ以上の mongot StatefulSets

• 任意のKubernetes OperatorマネージドEnvoyロードバランサー

• 任意の Cloud Manager または MongoDB Ops Manager メトリクスフォワーダー。

マルチクラスター配置では、これらは各ノードクラスターごとに実行されます。検索が期待どおりに動作しない場合は、Podやログを調査する前に、リソースのステータスを使用して、特定のクラスターおよびコンポーネントに問題を絞り込んでください。

ステータスを読み取るには、

kubectl get mongodbsearch ${MDB_RESOURCE_NAME} \  -n ${MDB_NS} --context ${K8S_CTX} -o yaml

最上位のフィールドから開始し、status.clustersを使用して絞り込みます。

次の例は、2 つのクラスターの配置で、2 番目のクラスターの Envoy ロード バランサーがロールアウトの途中で停滞している場合を示しています。マネージド ロード バランサーの準備状況はフェーズ全体に影響するため、両クラスターの mongot が正常であっても、リソースは Pending です。

status:  phase: Pending  message: "Waiting for managed load balancer to be ready"  clusters:    - name: member-cluster-1      index: 0      search: Running      loadBalancer: Running    - name: member-cluster-2      index: 1      search: Running      loadBalancer: Pending      loadBalancerMessage: "Load balancer deployment mdb-search-search-lb-1        rollout in progress: 1 unavailable replica(s)"

影響を受けたクラスターの name と index を使用して、対応するコンポーネントを調査します。

• Running ではない search サブフェーズの場合は、そのクラスターの mongot StatefulSet と Pod を調査します。searchMessage は通常、準備でない StatefulSet を報告します。「mongot Pod の起動に失敗します。」を参照してください。

• Running ではない loadBalancer サブフェーズの場合は、そのクラスターの Envoy Deployment を調査します。rollout in progress や unavailable replica(s) などのメッセージは、新しい Envoy Pod がスケジューリングされていないか、準備できていないことを示しています。

• Running ではない metricsForwarder サブフェーズの場合は、そのクラスターのメトリクスフォワーダー配置を調査します。

識別されたコンポーネントの Pod 状態、ログ、イベントを収集するには、診断情報の収集を参照してください。

mongot Podが起動しない

症状: mongot ポッドが Pending、ContainerCreating、Error の状態のまま Running に達しないか、MongoDBSearch リソースが Running 状態に達しない。

診断: 診断情報の収集 のコマンドを実行し、ポッド イベントと MongoDBSearch ステータスを確認します。一般的な指標としては、スケジューリングの失敗、ボリュームマウントエラー、イメージプルエラーなどがあります。

解決:

• ポッドをスケジュールできない場合は、十分な CPU とメモリを持つ ノード が利用可能であることを確認し、StorageClass が要求された Persistent Volume Claim をバインドできることを確認します。mongotのサイズ設定の詳細については、「 検索とベクトル検索のリソース計画とサイズ設定」を参照してください。

• search-sync-source ユーザーのパスワード シークレットが見つからない場合は、作成します。MongoDBSearch リソースは ${MDB_RESOURCE_NAME}-search-sync-source-password という名前のシークレットを期待します。

• mongotコンテナイメージをプルできない場合は、イメージ名とレジストリの認証情報を確認します。kubectl get events -n ${MDB_NS} | grep -i pull を使用してイメージプルエラーを確認します。

• ソースmongodレプリカセットがRunning状態でない場合は、まずその問題を解決してください。Kubernetes 用の MongoDB Controllers 演算子は、mongotを配置する前にソース リソースを待機します。

検索クエリが到達しない mongot

症状: $search, $searchMeta、$vectorSearch、またはクエリがエラーで失敗し、mongodが検索サービスにアクセスできないことを示すエラーが表示されます。

診断: mongot ポッドが Running であり、その サービス が存在することを確認します。

kubectl get pods,svc -n ${MDB_NS} --context ${K8S_CTX} \  | grep search

接続または認証エラーについては mongot ログを、検索ホストを参照するエラーについては mongod ログを検討します。

解決:

• mongot ポッドが Running でない場合は、mongot ポッドが起動できません。に取り組んでください。

• ログに認証エラーが表示される場合は、search-sync-source ユーザーの認証情報とロールを確認します。詳細については、「検索から MongoDB への接続を保護する」を参照してください。

• ログに TLS mongodエラーが表示されている場合は、 とmongot が同じ CA を信頼していることを確認します。詳しくは、 「 MongoDBから検索への接続の保護 」を参照してください。

mongot 繰り返し再起動する

症状: mongot ポッドの再起動回数が多いか、CrashLoopBackOff が報告されます。

診断: 前のコンテナ インスタンスのログを表示して、再起動をトリガーしたエラーをキャプチャします。

kubectl logs statefulset/${MDB_RESOURCE_NAME}-search-0 \  -n ${MDB_NS} --context ${K8S_CTX} --previous

pod の最終状態と終了理由を確認します。

kubectl describe pod ${MDB_RESOURCE_NAME}-search-0-0 \  -n ${MDB_NS} --context ${K8S_CTX}

解決:

• 終了理由が OOMKilled の場合は、mongot のメモリ リソースを増やします。mongot のメモリが不足しました。を参照してください。

• ログに構成エラーまたは認証エラーが表示される場合は、設定を修正し、Kubernetes 用 MongoDB Controllers 演算子によって変更を調整させます。

• ログに mongot がインデックスデータを読み取りまたは書き込みできないことが示されている場合は、永続ボリューム請求 がバインドされていて書き込み可能であることを確認してください。「mongot Pod が起動に失敗する」を参照してください。

mongot メモリが不足しました

症状: mongot ポッドが OOMKilled の理由で終了され、再起動回数が増加します。

診断: ポッドの終了理由を確認します。

kubectl describe pod ${MDB_RESOURCE_NAME}-search-0-0 \  -n ${MDB_NS} --context ${K8S_CTX}

mongot Lucene に基づいたメモリマップワークロードです。メモリの圧力は、インデックスサイズとクエリロードに対するメモリの制限が小さすぎることによって発生することがよくあります。

解決:

• MongoDBSearch リソースの mongot に割り当てられるメモリ リソースを増加します。mongot を再起動して変更を適用します。

• 検索とベクトル検索のリソース計画とサイジングのサイジングガイダンスに対して、インデックスのサイズとクエリロードを検討します。

最初の同期が遅い、またはレプリケーションラグが増加します

症状: 新しく作成されたインデックスが長時間ビルド状態のままになるか、クエリ結果がmongodへの最近の書き込みに対して遅れる。

診断: mongotログでレプリケーションの進捗状況とエラーを確認します。配置のモニターで設定したメトリクスを使用して、インデックス構築の進捗状況とレプリケーションラグを経時的に追跡します。

解決:

• 最初の同期が完了するまで待機します。インデックスをビルドする時間は、ソースデータのサイズに応じて増えます。

• 安定した負荷の下でも遅延が続く場合、mongot インスタンスには書き込み量に十分なリソースがない可能性があります。検索とベクトル検索のリソース計画とサイジ設定。を検討します。

• ランダム読み取りの多い Lucene ワークロードのストレージパフォーマンスが推奨事項を満たしていることを確認します。ストレージの低速化は、持続的な遅延の一般的な原因です。

mongod と mongot 間の TLS ハンドシェイクの失敗

状況: mongotログに TLS ハンドシェイクまたは証明書検証エラーが表示され、mongod はmongot への接続を確立できません。

診断: mongotログで証明書エラーを確認し、 MongoDBSearchリソースが参照する TLS シークレットが存在することを確認します。

kubectl get secrets -n ${MDB_NS} --context ${K8S_CTX} \  | grep -i tls

解決:

• とmongod mongotが同じ CA を信頼していることを確認します。

• 証明書を置き換えたり、ローテーションした後、mongotを再起動して、新しい証明書を読み込むようにします。mongot はスタートアップ時に証明書を読み取りますが、実行中に再読み込みは行いません。

• 詳しくは、 MongoDB からサーチへの接続を保護するを参照してください。

自動埋め込みの失敗

症状: 自動埋め込みを使用するインデックスのビルドに失敗するか、埋め込みリクエストが mongot ログでエラーを返します。

診断: 認証の失敗やリクエストのタイムアウトなど、埋め込みプロバイダーを参照するエラーについて mongot ログを確認します。

解決:

• Voyage AI API キーが有効であること、および、それを保持する Secret が名前空間に存在することを確認します。

• mongot が Kubernetes クラスターから埋め込みプロバイダーのエンドポイントに接続できることを確認します。

サポートの診断をキャプチャする

MongoDB サポートにお問い合わせいただく場合は、mongot ログ、MongoDBSearch リソースの説明、および最近の名前空間イベントを含めてください。

kubectl logs statefulset/${MDB_RESOURCE_NAME}-search-0 \  -n ${MDB_NS} --context ${K8S_CTX} > mongot.log
kubectl describe mongodbsearch ${MDB_RESOURCE_NAME} \  -n ${MDB_NS} --context ${K8S_CTX} > mongodbsearch-describe.txt
kubectl get events -n ${MDB_NS} --context ${K8S_CTX} \  --sort-by='.lastTimestamp' > events.txt

影響を受ける各検索ポッドからの FTDC ファイルを含めることもできます。mongot は FTDC/mongot/data/diagnostic.data/ ファイルをポッド内の に書込みます。

/mongot/data パスは、検索 StatefulSet の volumeClaimTemplate を介して Kubernetes 演算子がポッドにマウントする PersistentVolumeClaim であるため、診断データはポッドの再起動後も持続します。ポッドが置き換えられると、StatefulSet は同じ PersistentVolumeClaim を再ファイルするため、診断データは保持されます。

検索ポッドからローカルマシンに FTDC データをコピーします。シャーディングされたクラスターの場合は、シャードごとの検索ポッドからローカルマシンに FTDC データをコピーします。すべてのシャードに対して繰り返します。

kubectl cp -n ${MDB_NS} --context ${K8S_CTX} \   ${MDB_SEARCH_RESOURCE_NAME}-search-0-${MDB_EXTERNAL_SHARD_0_NAME}-0:/mongot/data/diagnostic.data \   ./mongot-diagnostic.data-${MDB_EXTERNAL_SHARD_0_NAME}

詳細

• 配置のモニタリング

• mongot 配置の制限