Kubernetes 演算子 用 MongoDB Controllers は、MongoDBSearch リソースで定義された個別の Pod 内の別のプロセスとして mongot を配置します。クライアントが mongot に直接接続することはありません。MongoDB Search とベクトル検索クエリは mongod で実行され、mongot にプロキシされます。mongot は mongod に接続してイベントの変更をストリームし、専用の 永続ボリューム 上にインデックスをビルドします。
このページでは、mongot 配置で発生する一般的なランタイムの問題を診断し、解決する方法について説明します。初期設定時のインデックス作成に特有のトラブルシューティングについては、 MongoDB Search とベクトル検索の使用を参照してください。調査する前にメトリクスとログを設定するには、 配置のモニターを参照してください。
このページの手順では、次の環境変数を配置に合わせて設定していることを前提としています。
export MDB_NS="<your-namespace>" export K8S_CTX="<your-kubectl-context>" export MDB_RESOURCE_NAME="<your-mongodbsearch-resource-name>"
診断情報の収集
特定のシナリオに取り組む前に、mongot ノードの現在の状態、そのログ、および最近の Kubernetes イベントを収集します。
Check the status and restart count of the mongot pod kubectl get pods -n ${MDB_NS} --context ${K8S_CTX} | grep search Review the most recent mongot logs kubectl logs statefulset/${MDB_RESOURCE_NAME}-search-0 \ -n ${MDB_NS} --context ${K8S_CTX} --tail=100 Inspect the MongoDBSearch resource status and conditions kubectl describe mongodbsearch ${MDB_RESOURCE_NAME} \ -n ${MDB_NS} --context ${K8S_CTX} List recent events in the namespace kubectl 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
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 から Search への接続を保護するを参照してください。
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 からサーチへの接続を保護するを参照してください。
自動埋め込みの失敗
注意
自動埋め込みはプレビュー機能であり、Voyage AI モデルのみと統合されます。
症状: 自動埋め込みを使用するインデックスのビルドに失敗するか、埋め込みリクエストが 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 はポッド内の /mongot/data/diagnostic.data/ に FTDC ファイルを書き込みます。
/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}