Para agentes de IA: hay un índice de documentación disponible en https://www.mongodb.com/es/docs/llms.txt — versiones en markdown de todas las páginas están disponibles agregando .md a cualquier ruta URL.
Docs Menu

mongot Solución de problemas Implementación

El operador de controladores de MongoDB para Kubernetes implementa mongot como un proceso separado en su propio Pod, definido por un MongoDBSearch recurso. Los clientes nunca se conectan mongot directamente a: las consultas de búsqueda de MongoDB y búsqueda vectorial se ejecutan mongod en, que las redirige mongot a. mongot se conecta de nuevo a mongod para transmitir eventos de cambio y crear sus índices en un volumen persistente dedicado.

Esta página describe cómo diagnosticar y resolver problemas comunes de ejecución en una implementación.mongot Para solucionar problemas específicos relacionados con la creación de índices durante la configuración inicial, consulte Uso de MongoDB Search y Vector Search. Para configurar métricas y registros antes de investigar, consulte Supervisar su implementación.

Los procedimientos de esta página presuponen que usted ha configurado las siguientes variables de entorno para que coincidan con su implementación:

export MDB_NS="<your-namespace>"
export K8S_CTX="<your-kubectl-context>"
export MDB_RESOURCE_NAME="<your-mongodbsearch-resource-name>"

Antes de trabajar en un escenario específico, recopile el estado actual del pod mongot, sus registros y los eventos recientes de 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'

Si el pod se reinicia en un bucle, revise los registros de la instancia de contenedor anterior para capturar el error que provocó el reinicio:

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

Síntomas: El mongot pod permanece Pending en, ContainerCreating o Error y nunca llega Running a, o el MongoDBSearch recurso no llega al Running estado.

Diagnóstico: Ejecute los comandos en Recopilar información de diagnóstico y revise los eventos del pod y el MongoDBSearch estado. Los indicadores comunes incluyen fallas de programación, errores de montaje de volumen y errores de descarga de imágenes.

Resolver:

  • Si no se puede programar el pod, confirme que hay un nodo con suficiente CPU y memoria disponible y que su StorageClass puede vincular la solicitud de volumen persistente solicitada. Para obtener más información sobre el mongot dimensionamiento, consulte Planificación y dimensionamiento de recursos de búsqueda y búsqueda vectorial.

  • Si falta la contraseña Secret para el usuario search-sync-source, créela. El recurso MongoDBSearch espera una contraseña Secret llamada ${MDB_RESOURCE_NAME}-search-sync-source-password.

  • Si no se puede descargar la imagen del contenedor mongot, verifique el nombre de la imagen y sus credenciales de registro. Compruebe si hay errores de descarga de imágenes con kubectl get events -n ${MDB_NS} | grep -i pull.

  • Si el conjunto de réplicas de origen mongod no está en el estado Running, resuelva primero ese problema. El operador de controladores de MongoDB para Kubernetes espera el recurso de origen antes de implementar mongot.

Síntomas: $searchLas consultas $searchMeta o $vectorSearch fallan con un error que indica que mongod no puede acceder al servicio de búsqueda.

Diagnóstico: Confirme que el mongot pod es Running y que su servicio existe:

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

Revise los registros mongot para detectar errores de conexión o autenticación, y revise los registros mongod para detectar errores que hagan referencia al host de búsqueda.

Resolver:

Síntomas: El mongot pod muestra un alto número de reinicios o CrashLoopBackOff informa.

Diagnóstico: Consulte los registros de la instancia de contenedor anterior para identificar el error que provocó el reinicio:

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

Verifique el último estado del pod y el motivo de salida:

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

Resolver:

  • Si el motivo de salida OOMKilled es, aumente los recursos de memoria mongot para.Consulte mongot Runs Out Memory.

  • Si los registros muestran un error de configuración o autenticación, corrija la configuración y deje que el operador de controladores de MongoDB para Kubernetes aplique el cambio.

  • Si los registros muestran que mongot no puede leer ni escribir sus datos de índice, confirme que la solicitud de volumen persistente esté vinculada y sea escribible. Consulte El pod de mongot no se inicia.

Síntomas: El mongot pod se termina con una OOMKilled razón y el contador de reinicios aumenta.

Diagnóstico: Confirme el motivo de la terminación del pod:

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

mongot Se trata de una carga de trabajo basada en Lucene y mapeada en memoria. La presión sobre la memoria suele deberse a límites de memoria insuficientes en relación con el tamaño del índice y la carga de consultas.

Resolver:

Síntomas: Los índices recién creados permanecen en estado de construcción durante mucho tiempo, o los resultados de las consultas se retrasan con respecto a las escrituras recientes mongod en.

Diagnóstico: Revise los mongot registros para ver el progreso de la replicación y los errores. Utilice las métricas que configuró en Supervisar su implementación para realizar un seguimiento del progreso de la creación del índice y el retraso de la replicación a lo largo del tiempo.

Resolver:

  • Permita que finalice la sincronización inicial. El tiempo necesario para crear un índice depende del tamaño de los datos de origen.

  • Si el retraso persiste bajo una carga constante,mongot es posible que la instancia no disponga de recursos suficientes para el volumen de escritura. Consulte la sección sobre planificación y dimensionamiento de recursos para búsqueda y búsqueda vectorial.

  • Confirme que el rendimiento del almacenamiento cumple con las recomendaciones para una carga de trabajo de Lucene con un uso intensivo de lecturas aleatorias. Un almacenamiento lento es una causa común de retrasos persistentes.

Síntomas: Los mongot registros muestran errores de handshake TLS o de validación de certificados, y mongod no puede establecer una conexión mongot con.

Diagnóstico: Revise los mongot registros en busca de errores de certificado y confirme que MongoDBSearch existen los secretos TLS a los que hace referencia el recurso:

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

Resolver:

  • Confirma que y confían mongod mongot en la misma CA.

  • Después de reemplazar o rotar un certificado, reinicie mongot para que lea el nuevo certificado. mongot lee los certificados al inicio y no los vuelve a cargar mientras se ejecuta.

  • Para obtener más información, consulte Cómo proteger la conexión de MongoDB a la búsqueda.

Nota

La integración automatizada es una función en vista previa y solo se integra con los modelos de Voyage AI.

Síntomas: Los mongot índices que utilizan la incrustación automatizada no se construyen o las solicitudes de incrustación devuelven errores en los registros.

Diagnóstico: Revise los mongot registros en busca de errores que hagan referencia al proveedor de incrustación, como fallas de autenticación o tiempos de espera de solicitud.

Resolver:

  • Verifique que su clave API de Voyage AI sea válida y que el secreto que la contiene exista en el espacio de nombres.

  • Confirma que mongot puede alcanzar el punto final del proveedor de incrustación desde tu clúster de Kubernetes.

Si se pone en contacto con el soporte de MongoDB, incluya los mongot registros, la MongoDBSearch descripción del recurso y los eventos recientes del espacio de nombres:

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

También puede incluir archivos FTDC de cada pod de búsqueda afectado. mongot escribe archivos FTDC en /mongot/data/diagnostic.data/ dentro del pod.

La ruta /mongot/data es un PersistentVolumeClaim que el operador de Kubernetes monta en el pod a través de un volumeClaimTemplate en el StatefulSet de búsqueda, por lo que los datos de diagnóstico persisten entre reinicios del pod. Cuando se reemplaza un pod, el StatefulSet vuelve a adjuntar el mismo PersistentVolumeClaim, por lo que se conservan los datos de diagnóstico.

Copie los datos FTDC del pod de búsqueda a su máquina local. Para clústeres fragmentados, copie los datos FTDC de cada pod de búsqueda por fragmento a su máquina local. Repita el proceso para cada fragmento:

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}