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
Docs Home
/ /
Implementar búsqueda y búsqueda vectorial
Docs Home
/
Gestión
/
Controladores para el Operador de Kubernetes
/
Implementar búsqueda y búsqueda vectorial
Docs Home
/
Gestión
/
Controladores para el Operador de Kubernetes
/
Implementar búsqueda y búsqueda vectorial

Solucionar problemas de implementación de mongot

El operador de controladores de MongoDB para Kubernetes implementa mongot como un proceso independiente en su propio Pod, definido por un recurso MongoDBSearch. Los clientes nunca se conectan directamente a mongot: las consultas de MongoDB Search y Vector Search se ejecutan en mongod, que las envía a mongot. mongot se vuelve a conectar a mongod para transmitir eventos de cambio y compilar sus índices en un volumen persistente dedicado.

Esta página describe cómo diagnosticar y resolver problemas comunes de tiempo de ejecución con una implementación de mongot. Para la solución de problemas específica de la creación de índices durante la configuración inicial, consulte Utilice MongoDB Search y búsqueda vectorial. Para configurar las métricas y el registro antes de investigar, consulte Supervise su implementación.

Los procedimientos de esta página asumen que ha establecido 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>"

Recopilar información de diagnóstico

Antes de trabajar en un escenario específico, recopila 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, consulte 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

Localizar un problema mediante el estado de los recursos

Un recurso MongoDBSearch ejecuta varios componentes independientes:

  • Uno o más mongot StatefulSets

  • Un balanceador de carga Envoy gestionado por el operador de Kubernetes opcional

  • Un reenviador de métricas opcional de Cloud Manager o MongoDB Ops Manager.

En una implementación de varios clústeres, cada uno de ellos se ejecuta por clúster de nodo. Cuando la búsqueda no se comporta como se espera, utilice el estado del recurso para localizar el problema en un clúster y componente específicos antes de inspeccionar los Pods o los registros.

Para leer el estado:

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

Comience con los campos de nivel superior y, a continuación, reduzca el alcance con status.clusters:

Campo
Lo que te dice

status.phase

La fase general de recursos. Esto refleja tanto la preparación de mongot StatefulSet en todos los clúster (el peor de los casos) como la preparación del balanceador de carga gestionado. El recurso se encuentra en la fase Pending si el mongot de cualquier clúster o el balanceador de carga gestionado por el operador de Kubernetes no está listo. El reenviador de métricas no afecta a esta fase.

status.loadBalancer

La fase del balanceador de carga de Envoy gestionado agregado en todos los clústeres. Esto solo se rellena cuando se establece spec.clusters[].loadBalancer.managed.

status.metricsForwarder

La fase de reenvío de métricas agregadas de MongoDB Ops Manager en todos los clústeres. Esto solo se rellena cuando el reenviador de métricas está habilitado.

status.clusters[]

Una entrada por clúster de nodo, cada una con su propio name y index y subfases independientes para search, loadBalancer y metricsForwarder. Cada subfase tiene un campo *Message coincidente (por ejemplo, searchMessage) que explica el motivo cuando la subfase no es Running.

Tip

Un recurso MongoDBSearch puede ser Pending incluso cuando la subfase search de cada clúster es Running; un recurso loadBalancer gestionado degradado en cualquier clúster puede mantener todo el recurso en la fase Pending. Lea las subfases por clúster para identificar qué clúster y componente son los responsables.

El siguiente ejemplo muestra una implementación de dos clústeres en la que el balanceador de carga Envoy del segundo clúster está atascado a mitad de la implementación. El recurso es Pending aunque mongot en ambos clústeres es correcto porque la preparación del balanceador de carga gestionado afecta a la fase general.

Ejemplo: Fase pendiente
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)"

Utilice el name y el index del clúster afectado para inspeccionar el componente correspondiente:

  • Para una subfase search que no sea Running, inspeccione el StatefulSet y los Pods mongot de ese clúster. El searchMessage normalmente informa qué StatefulSet no está listo. Consulte El Pod mongot no se inicia.

  • Para una subfase de loadBalancer que no sea Running, inspeccione la implementación de Envoy de ese clúster. Mensajes como rollout in progress o unavailable replica(s) indican que los nuevos pods de Envoy no se están programando ni están listos.

  • Para una subfase metricsForwarder que no sea Running, inspeccione la implementación del reenviador de métricas de ese clúster.

Para recopilar el estado, los registros y los eventos del Pod para el componente identificado, consulte Recopilar información de diagnóstico.

El pod mongot no se inicia

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

Diagnosticar: ejecute los comandos en Recopilar información de diagnóstico y revise los eventos del pod y el estado MongoDBSearch. Los indicadores comunes incluyen errores de cronograma, errores de montaje de volumen y errores de extracción de imágenes.

Resolver:

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

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

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

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

Las consultas de búsqueda no se realizan mongot

Síntomas: $search, $searchMeta o $vectorSearch queries fallan con un error que indica que mongod no puede llegar al servicio de búsqueda.

Diagnosticar: Confirme que el pod mongot es Running y que su servicio existe:

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

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

Resolver:

mongot Se reinicia repetidamente

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

Diagnosticar: vea los registros de la instancia de contenedor anterior para capturar el error que activó el reinicio:

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

Compruebe 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 es OOMKilled, aumenta los recursos de memoria para mongot. Consulta mongot se queda sin memoria.

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

  • Si los registros muestran que mongot no puede leer ni guardar sus datos de índice, confirme que la reclamación de volumen persistente está vinculada y se puede guardar. Consulte El pod mongot no se inicia.

mongot Se queda sin memoria

Síntomas: El pod mongot se termina con un motivo OOMKilled y el recuento de reinicios aumenta.

Diagnosticar: 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 es una carga de trabajo asignada a la memoria basada en Lucene. La presión de la memoria suele deberse a límites de memoria insuficientes en relación con el tamaño del índice y la carga de queries.

Resolver:

La sincronización inicial es lenta o el atraso de la replicación aumenta

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

Diagnosticar: revise los registros de mongot para ver el progreso de la replicación y los errores. Utilice las métricas que configuró en Supervisar su implementación para rastrear el progreso de la creación de índices y el atraso de la replicación a lo largo del tiempo.

Resolver:

  • Permita que se complete la sincronización inicial. El tiempo para compilar un índice se escala con el tamaño de los datos de origen.

  • Si el retraso persiste bajo una carga constante, es posible que la instancia mongot no tenga recursos suficientes para el volumen de guardado. Revisa Planificación y dimensionamiento de recursos de búsqueda y búsqueda vectorial.

  • Confirme que el rendimiento del almacenamiento cumple con las recomendaciones para una carga de trabajo de Lucene con muchas lecturas aleatorias. El almacenamiento lento es una causa común de retraso sostenido.

Errores de protocolo de enlace TLS entre mongod y mongot

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

Diagnosticar: revise los registros de mongot en busca de errores de certificado y confirme que existen los secretos TLS a los que hace referencia el recurso MongoDBSearch:

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

Resolver:

  • Confirme que mongod y mongot confían 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 iniciar y no los vuelve a cargar mientras se ejecuta.

  • Para obtener más información, consulte Proteja la conexión de MongoDB a Search.

Error en la incrustación automatizada

Nota

La incrustación automatizada es una funcionalidad de vista previa y solo se integra con los modelos de Voyage AI.

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

Diagnosticar: revise los registros de mongot en busca de errores que hagan referencia al proveedor de incrustación, como fallas de autenticación o tiempos de espera de solicitudes.

Resolver:

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

  • Confirme que mongot puede llegar al punto de conexión del proveedor de incrustación desde su clúster de Kubernetes.

Captura de diagnósticos para soporte

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

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 guarda 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 en los 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 en su máquina local. Para los clústeres particionados, copie los datos FTDC de cada pod de búsqueda por partición en su máquina local. Repita para cada partición:

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}

Obtén más información

Volver

Limitaciones conocidas

Next

Preguntas frecuentes

En esta página