Solucionar problemas de implementaciones de mongot autogestionadas

Antes de comenzar

Antes de trabajar en un escenario, confirme dónde se encuentra su implementación:

• Si tiene una anomalía métrica pero aún no sabe qué está mal, comience con las definiciones de métricas en Referencia de métricas para mongot y los umbrales en Alertas recomendadas para mongot.

• Si ha completado recientemente una implementación o un cambio de configuración, comience con Verificar su conexión mongot.

Si su síntoma no coincide con ningún escenario, capture los artefactos como se describe en Capturar diagnósticos para soporte y abra un caso de soporte.

mongot No se inicia

El proceso mongot no se inicia después de iniciarlo.

Síntomas

• El proceso finaliza a los pocos segundos de iniciarse.

• En un contenedor, el proceso se reinicia en un bucle.

• No aparece ningún mensaje de registro "listo".

Causas comunes

En orden de prioridad:

1. El archivo de configuración está mal formado o faltan campos obligatorios.

2. La autenticación en mongod falla al iniciar.

3. mongot no puede llegar a mongod en la dirección configurada.

4. Se produce un error de configuración de TLS.

5. El puerto configurado ya está en uso.

6. La ruta de datos no se puede escribir.

Diagnosticar

Revise las líneas de registro de inicio más recientes. El mensaje de error identifica el subsistema que falla.

contenedor

Linux

Entrada de registro

docker logs --tail 100 <container-id>

journalctl -u mongot --no-pager | tail -n 200

tail -n 200 /var/log/mongot/mongot.log

Busque los siguientes patrones:

• Failed to parse config file indica YAML no válido.

• Authentication failed o Unauthorized indica un problema de confianza de credenciales o x.509.

• Connection refused o unable to connect to host indica un host o puerto incorrecto, o que mongod no se está ejecutando.

• SSL handshake failed indica una confianza de CA o una falta de coincidencia de SAN de certificado.

• Address already in use indica que otro proceso está vinculado al mismo puerto.

• Cannot write to <dataPath> indica un problema de permisos o de ruta.

Resolver

• Configuración: corrija el YAML. Para obtener información sobre la configuración válida, consulte Configurar mongot.

• Autenticación: Verifique que el usuario exista en mongod con el rol requerido. Consulte Configurar la autenticación y la autorización para mongot.

• Accesibilidad: ejecute nc -zv <mongod-host> <mongod-port> desde el host mongot. Compruebe los firewalls, el DNS y la configuración mongod bindIp.

• TLS: Verifique que tanto mongot como mongod confían en la misma autoridad de certificación (CA) para que la cadena de certificados de cada lado se conecte a una CA de confianza. Verifique también que el SAN del certificado coincida con el nombre de host que utiliza mongot. Consulte Configurar el cifrado TLS para mongot.

• Puerto en uso: Identifique el proceso en conflicto con ss -lntp o lsof -i :<port>. Cambie el puerto mongot o detenga el otro proceso.

• Ruta de datos: Verifique que el directorio exista y que el usuario del proceso mongot pueda escribir en él. Actualice la propiedad y los permisos según sea necesario.

La query falla con un error de conexión

Una query falla porque mongod no puede llegar a mongot.

Síntomas

• Una query de $search, $searchMeta o $vectorSearch devuelve un error de conexión como Error connecting to <host>:<port> :: Connection refused.

• O la query devuelve Error connecting to Search Index Management service.

Causas comunes

1. mongot no se está ejecutando en el host al que mongod intenta llegar.

2. La configuración de host o puerto mongod para mongot es incorrecta y no coincide con el agente de escucha mongot.

3. mongot se está ejecutando, pero se bloqueó o se está reiniciando.

4. TLS no coincide. El mongod está configurado para TLS, pero el mongot no, o viceversa.

Diagnosticar

Desde el host mongod, pruebe la conectividad con mongot:

nc -zv <mongot-host> <mongot-port>

Desde el host mongot, confirme que el proceso se está ejecutando y escuchando:

ps aux | grep '[m]ongot'
ss -lntp | grep <mongot-port>

Inspeccione el registro mongod para ver el error coincidente y el host mongot configurado:

grep -E 'mongotHost|searchIndexManagementHostAndPort' \
  /var/log/mongodb/mongod.log

Resolver

• Si mongot no se está ejecutando, reinícielo. Si no se inicia, siga mongot no se inicia.

• Si la configuración del host mongot es incorrecta, corrija el parámetro mongod y reinicie mongod.

• Si TLS no coincide, concilie la configuración de TLS en ambos lados. Consulte Configurar el cifrado TLS para mongot.

mongot Sigue resincronizando

Un índice se descarta repetidamente del estado estable y comienza una sincronización inicial.

Síntomas

• Los registros repiten Initial sync starting seguido de excepciones.

• En estado estable, los registros muestran Exception requiring resync occurred during steady state replication.

• El estado del administrador de índices vuelve a INITIAL_SYNC.

• Search devuelve resultados obsoletos durante la ventana de resincronización.

Causas comunes

1. El oplog mongod se transfirió antes de que mongot pudiera ponerse al día, normalmente porque mongot era demasiado lento o estaba inactivo, o porque el oplog es demasiado pequeño.

2. Un problema transitorio, como una interrupción de la red o un breve reinicio de mongod, provocó una excepción de estado estable. Una sola ocurrencia es recuperable, pero las ocurrencias repetidas no lo son.

3. Una explosión de asignación de documentos llena repetidamente el montón mongot, lo que activa un error de falta de memoria y una resincronización.

4. Los datos del índice están dañados.

5. Un número muy grande de índices, asignaciones dinámicas o elecciones de campos costosas impulsan un atraso de la replicación.

Diagnosticar

Revise las siguientes métricas:

• mongot_replication_mongodb_indexManagerState ciclos entre INITIAL_SYNC y STEADY_STATE.

• mongot_index_stats_numLuceneMaxDocs es cíclico o está atascado.

• mongot_index_stats_indexing_replicationLagMs sigue subiendo.

• mongot_jvm_memory_used_bytes y mongot_jvm_gc_pause_seconds_sum aumentan bajo presión de memoria.

Busque en el registro mongot el error que precede a la resincronización y, a continuación, compruebe la oplog window y el montón:

grep -E 'SteadyStateException|CappedPositionLost|OutOfMemoryError' \
  mongot.log

En mongosh, compruebe el tamaño del oplog mongod con db.getReplicationInfo().

Resolver

• Si el oplog es demasiado pequeño para la tasa de aplicar mongot, aumente el tamaño del oplog mongod o cierre la brecha con más capacidad mongot o menos índices simultáneos.

• Si se repiten las excepciones de estado estable, capture FTDC y abra un caso de soporte.

• Para una explosión de asignación de documentos, busque el índice infractor, generalmente uno con una asignación dynamic: true que ingiere documentos con claves arbitrarias. Cambie a una asignación estática o restrinja el conjunto de campos, luego reinicie mongot para borrar el estado del montón.

• Para la corrupción de índices, que es poco frecuente, captura FTDC y, a continuación, descarta y vuelve a crear el índice afectado. No borres archivos de la ruta de datos manualmente.

Error de OutOfMemory o mongot eliminado por el sistema operativo

mongot sale porque se queda sin memoria.

Síntomas

• mongot sale inesperadamente y el recuento de reinicios del contenedor aumenta.

• Los registros terminan con OutOfMemoryError: Java heap space, un error de memoria insuficiente del lado de JVM.

• Los registros del sistema de dmesg o journalctl muestran que el eliminador de OOM terminó el proceso, un error de memoria insuficiente del lado del host.

Causas comunes

1. El montón es demasiado pequeño para la carga de trabajo, especialmente durante una sincronización inicial o una fusión grandes.

2. Una explosión de mapeo de documentos consume el montón. Consulte mongot sigue sincronizándose.

3. El límite de memoria del contenedor es demasiado bajo. Incluso con un montón de tamaño correcto, los gastos en general sin montón de la JVM pueden superar el límite.

4. Las definiciones de índice deficientes, como demasiados índices o definiciones costosas, aumentan la presión de la memoria.

5. Se produce una pérdida de memoria, lo cual es raro pero posible en las compilaciones preliminares.

Diagnosticar

Revise las siguientes métricas:

• mongot_jvm_memory_used_bytes aumenta con las consultas que consumen mucha memoria y las definiciones de índices.

• mongot_jvm_gc_pause_seconds_sum muestra el tiempo acumulado dedicado a las pausas de recolección de basura.

• machine_swap_bytes permanece cerca de cero en una implementación saludable. El uso de intercambio indica una presión de memoria grave.

Compruebe el registro mongot para ver el seguimiento de la pila sin memoria y el tamaño de montón configurado:

grep -E 'OutOfMemoryError|Java heap space' mongot.log
ps -ef | grep '[m]ongot' | grep -oE '\-Xmx[0-9a-zA-Z]+'

Para un contenedor, compruebe el límite de memoria configurado:

docker inspect <container> | grep -i memory

Resolver

• Aumente -Xmx si el host tiene espacio libre de memoria.

• En un contenedor, establezca el límite de memoria notablemente mayor que -Xmx para acomodar los gastos en general que no son de montón. Como punto de partida, establezca el límite del contenedor en al menos el valor -Xmx más el 30%.

• Si el montón es lo suficientemente grande pero aún se queda sin memoria, busque patrones de indexación que causen la explosión. El registro mongot identifica el índice.

• Reduzca la cantidad de índices o simplifique las definiciones de índices costosas si son la fuente de presión de la memoria.

• Si sospechas de una fuga de memoria, captura FTDC y un vaciado de memoria para obtener soporte.

La sincronización inicial es lenta o está atascada

Un nuevo índice tarda mucho tiempo en completar su sincronización inicial.

Síntomas

• El estado del índice permanece en INITIAL_SYNC durante mucho tiempo.

• En algunos casos, el administrador de replicación ingresa INITIAL_SYNC_BACKOFF antes de reintentar la sincronización inicial.

• mongot_index_stats_numLuceneMaxDocs crece solo lentamente.

• El índice no se puede consultar mientras se ejecuta la sincronización inicial.

Causas comunes

1. El host de origen mongod está subaprovisionado y no puede alimentar la sincronización inicial lo suficientemente rápido.

2. La presión del disco, la CPU o la memoria en otros lugares ralentiza la compilación.

3. Un gran rellenado inicial supera la capacidad actual del hardware.

Diagnosticar

Observe mongot_replication_mongodb_indexManagerState y mongot_index_stats_numLuceneMaxDocs para el crecimiento de documentos.

No trate mongot_index_stats_indexing_replicationLagMs como autoritativo durante la sincronización inicial. Esta métrica no se rellena de forma significativa durante la sincronización inicial. En su lugar, revise las métricas de estado del sistema para confirmar que el sistema tiene recursos suficientes.

Resolver

• Escale el host de origen mongod si es el cuello de botella.

• Añada CPU o memoria donde el sistema tenga recursos limitados.

• Vuelve a comprobar el espacio libre en disco antes de reintentar una compilación inicial grande.

Índices atascados en estado PENDING o BUILDING

Un índice no progresa más allá del estado PENDING o BUILDING.

Síntomas

• Un índice permanece en PENDING o BUILDING durante más de unos minutos en una colección que no es grande.

• El registro mongot no muestra fallos, solo una falta de progreso.

Causas comunes

1. mongot no está progresando en sincronizar. Consulte Atraso de la replicación grande.

2. El punto final de incrustación está fallando para los índices de incrustación automatizada.

3. El grupo de ejecutores de indexación está saturado por otros índices que se están creando simultáneamente.

4. mongot se reinició recientemente y los índices se están poniendo al día.

5. La presión del disco detuvo una nueva compilación o recompilación a pesar de que se aceptó la definición.

Diagnosticar

Revise mongot_replication_mongodb_indexManagerState y mongot_index_stats_numLuceneMaxDocs para ver el progreso.

En mongosh, compruebe el estado del índice y cualquier campo de error:

db.<collection>.getSearchIndexes()

Confirme que el rendimiento de la indexación está aumentando:

rate(mongot_index_stats_indexing_insert_total[5m])

Para los índices de incrustación automatizada, compruebe si los contadores de reintentos de incrustación son mayores que cero:

rate(mongot_indexing_steadyStateChangeStream_rescheduledEmbeddingGetMores_total[5m])
rate(mongot_initialsync_queue_requeuedEmbeddingInitialSyncs_total[5m])

Resolver

• Si el rendimiento de la indexación es plano, revise el registro mongot para ver el nombre del índice y las excepciones.

• Si los reintentos de incrustación son mayores que cero, corrija la ruta de incrustación. Consulte Configurar mongot para la incrustación automatizada de búsqueda vectorial de MongoDB.

• Si el grupo de ejecutores está saturado, reduce la creación de índices simultáneos o escala mongot.

• Si el disco es el bloqueador, agregue espacio libre o mueva la compilación a un nodo más grande.

Las query devuelven resultados vacíos

Una query no devuelve resultados aunque existan documentos coincidentes.

Síntomas

• Puede ejecutar findOne() en un documento que espera encontrar en el índice de búsqueda.

• Una query $search en el mismo campo no devuelve nada o menos resultados de los esperados.

Causas comunes

1. El índice no ha terminado de crearse para los documentos que espera que coincidan.

2. El atraso de la replicación significa que mongot aún no ha recibido los documentos.

3. La definición del índice no cubre el campo en el que se realiza la búsqueda.

4. La query expression es incorrecta, como una expresión numérica en un campo indexado como una string.

5. La indexación falló en los documentos específicos.

Diagnosticar

En mongosh, compruebe el estado del índice y confirme si el índice ha visto el documento:

db.<collection>.getSearchIndexes()

Luego, revise mongot_index_stats_indexing_replicationLagMs para verificar el atraso de la replicación.

Resolver

• Espere a que el índice alcance el estado listo.

• Espere a que se borre el atraso de la replicación.

• Ajuste la definición del índice o la query.

• Si la indexación falla en documentos específicos, el registro de mongot identifica el motivo de la falla. Corrija o filtre esos documentos.

Saturación o limitación de la CPU

La presión sostenida de la CPU degrada el rendimiento de las queries y la replicación.

Síntomas

• La latencia de query aumenta bajo una presión sostenida de la CPU.

• El atraso de la replicación aumenta porque el trabajo de query y el trabajo de indexación compiten por la CPU.

• En casos graves, las verificación de estado fallan y el proceso se reinicia.

Causas comunes

1. El host mongot está subaprovisionado para la combinación actual de trabajo de query e indexación.

2. Demasiado trabajo de indexación concurrente compite con la ejecución de query.

3. La carga de trabajo necesita descarga de carga o escalado de capacidad.

Diagnosticar

Revise las siguientes métricas:

• mongot_command_searchCommandTotalLatency_seconds_max

• mongot_index_stats_indexing_replicationLagMs

• Métricas de carga y CPU del host, que aumentan bajo saturación.

Ningún mensaje de registro explícito indica que el host tiene la CPU limitada.

Resolver

• Escalar CPU en el host mongot.

• Reduzca la carga mediante prácticas de descarga de carga si están disponibles.

• Simplifique el trabajo de indexación si la actividad de replicación compite con las query.

Presión del disco o ruta de datos casi llena

La ruta de datos de mongot se queda sin espacio libre.

Síntomas

• El espacio libre en la ruta de datos mongot se reduce a cero.

• Los índices existentes acumulan atraso de la replicación una vez que el uso del disco es alto.

• Un índice nuevo o reconstruido puede permanecer en INITIAL_SYNC cuando la presión del disco es grave.

• Las query continúan realizándose correctamente incluso mientras la replicación está en pausa para la protección del disco.

Causas comunes

1. El host no tiene suficiente espacio libre para el crecimiento normal de la indexación.

2. Un índice nuevo o reconstruido necesita más espacio temporal del que puede proporcionar el disco actual.

Diagnosticar

Revise las siguientes métricas:

• mongot_system_disk_space_data_path_free_bytes informa bytes libres en el directorio de datos.

• mongot_system_disk_space_data_path_total_bytes informa el total de bytes en el directorio de datos.

Esté atento al comportamiento de pausa de replicación vinculado a los umbrales de disco. La replicación se detiene cuando el uso del disco supera aproximadamente el 90% y se reanuda después de que el uso cae por debajo de aproximadamente el 85%. Para un índice nuevo o una reconstrucción, espere que se acepte la definición, pero que la compilación se quede atascada si la presión del disco ya está por encima del umbral de protección.

Resolver

• Agregue capacidad de disco si el host o el volumen se pueden expandir de forma segura.

• Borre los índices innecesarios para liberar espacio si eso es operacionalmente aceptable.

• Mantenga un margen extra antes de compilar o recompilar índices grandes. Planifique aproximadamente el 125% de la huella esperada en estado estable durante una recompilación.

• En NVMe de almacenamiento de instancias locales, no asuma que puede cambiar el tamaño en su lugar. Por lo general, necesita una clase de máquina más grande y una reindexación cuando supera la capacidad de almacenamiento de instancias locales.

• Si utiliza almacenamiento respaldado por EBS, un cambio de tamaño en vivo es más factible, pero NVMe sigue siendo la orientación preferida para el rendimiento de mongot. Consulte Recomendaciones de clase de almacenamiento para mongot.

Atraso de la replicación del límite de BSON de 16 MB

Un evento de flujo de cambios supera el límite de BSON de 16 MB y detiene la replicación.

Síntomas

• Un índice se vuelve obsoleto o comienza a reconstruirse después de un error de replicación de estado estable.

• El registro mongot muestra change stream payload exceeding 16MB BSON limit, BSONObjectTooLarge o el código de error 10334 durante getMore.

• Sus documentos almacenados pueden parecer más pequeños que 16 MB, pero el error aún se produce.

Causas comunes

1. El evento de flujo de cambios supera los 16 MB porque incluye tanto el documento como metadatos adicionales del flujo de cambios.

2. Las actualizaciones grandes de documentos ya grandes hacen que la carga útil del flujo de cambios sea mayor de lo que sugiere el tamaño del documento almacenado por sí solo.

Diagnosticar

Revise las siguientes métricas:

• mongot_changestream_numSplitEvents_total cuenta los eventos que superaron el tamaño de carga útil de 16 MB.

• mongot_index_stats_indexing_replicationLagMs informa el atraso de la replicación para un índice específico.

Busque las siguientes cadenas en el registro mongot:

• change stream payload exceeding 16MB BSON limit

• BSONObjectTooLarge

• Executor error during getMore

• code 10334

Si una comprobación del tamaño del documento muestra que los documentos más grandes están por debajo de 16 MB, no descartes este escenario. El evento de cambio incluye metadatos además del propio documento.

Resolver

• Reduzca el tamaño del documento y evite las actualizaciones grandes de documentos ya grandes siempre que sea posible.

• Siempre que sea posible, reemplace el documento en lugar de aplicar una actualización grande a un documento grande existente.

• Si la mayoría de las guardados son actualizaciones, revise la query de actualización para reducir el tamaño de los metadatos del evento de flujo de cambios.

• Después de corregir la carga de trabajo, permita que se complete la reconstrucción. Si el patrón de carga de trabajo no cambia, el índice puede volver a fallar.

• Si el problema se repite después de ajustar la carga de trabajo, capture los registros y escale con los detalles del incidente.

Atraso de la replicación grande

El atraso de la replicación crece constantemente con el tiempo.

Síntomas

• El atraso de la replicación crece constantemente y puede alcanzar muchas horas o varios días.

• mongot se vuelve limitado por la memoria o se queda sin memoria repetidamente mientras intenta mantenerse al día.

• El host aún puede servir queries, pero el rendimiento de las queries puede degradarse debido al trabajo de replicación y a las grandes huellas de índice.

Causas comunes

1. Un número muy grande de índices aumenta la replicación y los gastos en general de indexación.

2. El uso generalizado de dynamic: true aumenta el recuento de campos y el tamaño del índice, lo que aumenta la presión de la memoria.

3. Los eventos repetidos de falta de memoria empeoran el retraso y hacen que las métricas aparezcan entrecortadas o incompletas.

4. El cuello de botella está en la base de datos de origen. Los secundarios mongod con aprovisionamiento insuficiente con alta presión de CPU y caché pueden evitar que los eventos de flujo de cambios se emitan lo suficientemente rápido.

Diagnosticar

Revise las siguientes métricas:

• mongot_index_stats_indexing_replicationLagMs informa el atraso de la replicación para un índice específico.

• mongot_indexing_steadyStateChangeStream_getMoresScheduled informa de las operaciones getMore programadas.

• mongot_replication_mongodb_indexManagerState identifica qué índices no están progresando.

• mongot_jvm_memory_used_bytes y las métricas de CPU y carga del host muestran presión de recursos.

Cuente el número total de índices y revise si muchos dependen de dynamic: true o indexan campos innecesarios de alta cardinalidad.

Resolver

• Escale mongot CPU y memoria primero si los nodos se ejecutan sin memoria o tienen restricciones de memoria.

• Reduzca la cantidad total de índices. Con recuentos de índices muy altos, agregar más nodos de búsqueda puede empeorar el patrón de carga a menos que primero controle la carga del flujo de cambios.

• Desactive la asignación dinámica de esquemas cuando no sea necesaria. Prefiera dynamic: false y asigne explícitamente solo los subcampos necesarios para las queries.

• Reduzca el número de campos de índice, especialmente los campos de alta cardinalidad, como las marcas de tiempo o los ID de usuario, y remueva las asignaciones de facetas profundas que no se utilizan para la faceta.

• Si los secundarios mongod son el cuello de botella, escale la base de datos principal para mejorar el rendimiento del flujo de cambios.

Errores de protocolo de enlace de TLS

El protocolo de enlace TLS entre mongot y mongod falla.

Síntomas

• El registro mongot muestra SSL handshake failed, Certificate verification failed o bad certificate.

• El registro mongod muestra errores similares cuando intenta llegar a mongot.

Causas comunes

1. Desajuste de CA: ambos extremos no confían en la misma CA.

2. El SAN del certificado no incluye el nombre de host en uso.

3. El certificado ha caducado.

4. Desajuste del modo TLS: un lado requiere TLS y el otro lo deshabilitó.

5. Mismatched cipher suite o versión de TLS, lo cual es raro.

Diagnosticar

Inspecciona los certificados que sirve cada lado y verifica la cadena con tu CA:

openssl s_client -connect <mongot-host>:<mongot-port> -showcerts
openssl s_client -connect <mongod-host>:<mongod-port> -showcerts
openssl verify -CAfile <ca-bundle> <cert-file>
openssl x509 -in <cert-file> -text -noout

Resolver

• Distribuya la CA correcta a ambos puntos finales.

• Vuelva a emitir certificados con la lista SAN correcta.

• Renovar certificados caducados.

• Concilie los modos TLS en ambos lados. Consulte Configurar el cifrado TLS para mongot.

El índice alcanza el límite de documentos de Lucene

Un solo índice supera el recuento máximo de documentos de Lucene.

Síntomas

• Un índice muy grande deja de avanzar cerca del límite de recuento de documentos de Lucene.

• Los registros muestran java.lang.IllegalArgumentException: number of documents in the index cannot exceed 2147483519.

• mongot_index_stats_numLuceneMaxDocs se acerca al límite máximo y puede dejar de publicarse después de alcanzar el límite.

• El estado del administrador de índices cambia a un estado fallido.

Causas comunes

1. Un único índice no particionado superó el recuento máximo de documentos de Lucene de 2147483519.

2. Se aceptó un nuevo índice y comenzó a compilarse, pero falló una vez que alcanzó el mismo límite máximo.

Diagnosticar

Observe mongot_index_stats_numLuceneMaxDocs como la señal preventiva principal para este modo de error y compruebe el registro para ver la string de excepción exacta:

java.lang.IllegalArgumentException: number of documents in the index cannot exceed 2147483519

Resolver

Particione el índice para que cada partición se mantenga por debajo del límite de recuento de documentos de Lucene y, a continuación, reconstruya el índice con numPartitions configurado correctamente. Espere compensaciones: el particionamiento puede requerir la distribución de queries en varias particiones y puede afectar el rendimiento de la búsqueda.

{
  "numPartitions": 4,
  "mappings": {
    "dynamic": true
  }
}

Errores de incrustación automatizada

Un índice de incrustación automatizada no puede alcanzar el endpoint de incrustación.

Síntomas

• Un índice de incrustación automatizada permanece en PENDING o BUILDING.

• El registro mongot muestra errores en el punto final de incrustación.

• Los contadores de reintento de incrustación mongot_indexing_steadyStateChangeStream_rescheduledEmbeddingGetMores_total o mongot_initialsync_queue_requeuedEmbeddingInitialSyncs_total son mayores que cero. Utiliza estos contadores como indicadores indirectos y revisa el registro para ver el error HTTP real del punto de conexión de incrustación.

Causas comunes

1. La clave API del modelo no es válida o ha caducado.

2. La red no puede alcanzar el punto final de incrustación.

3. El proveedor de incrustación está limitando la tasa de solicitudes.

4. El proveedor de incrustaciones tiene una interrupción del servicio.

Diagnosticar

Pruebe la conectividad con el punto de conexión de incrustación desde el host mongot y, a continuación, compruebe el registro:

grep -E 'voyage|embedding' mongot.log

Resolver

• Reemplace la clave de API del modelo y reinicie mongot.

• Abra la salida de red al punto final de incrustación.

• Si el proveedor limita la velocidad de las solicitudes, aumente el límite o reduzca la simultaneidad de la indexación.

• Si el proveedor tiene una interrupción del servicio, supervise el estado de Voyage AI y considere cambiar los puntos de conexión.

Para ver el modelo de configuración de incrustación completo, consulte Configurar mongot para la incrustación automatizada de búsqueda vectorial de MongoDB.

Señales de almacenamiento como IOPS sostenidas o fallos de página

Las IOPS de almacenamiento sostenidas o los fallos de página indican un cuello de botella en el almacenamiento. Si ejecuta en NVMe local, primero observe el margen de memoria. Si ejecuta en cualquier otra clase de almacenamiento, como SAN, SSD en la nube de uso general o SSD SATA, la clase de almacenamiento es la causa raíz probable y se justifica una migración. Consulte Recomendaciones de clase de almacenamiento para mongot.

El rendimiento disminuye sin una causa obvia

El rendimiento disminuye sin un cambio de implementación reciente.

Síntomas

• La latencia de las queries aumentó sin un cambio de implementación obvio.

• El uso de CPU o memoria aumentó.

Causas comunes

1. La carga de trabajo cambió, con más o más grandes query.

2. Un nuevo índice ahora consume recursos.

3. Una explosión de mapeo de documentos consume el montón.

4. Almacenamiento degradado, como un vecino ruidoso, una reconstrucción de RAID o un problema del proveedor de nube.

5. Se produjo una regresión en el ajuste de la recolección de basura después de una actualización de la JVM.

Diagnosticar

Pivota a través de las métricas por síntoma, como la latencia de la query, el montón, la cola del ejecutor y las IOPS de almacenamiento. Para conocer las definiciones y los umbrales de las métricas, consulta Referencia de métricas para mongot y Alertas recomendadas para mongot.

Resolver

La resolución depende de la causa raíz. Las opciones incluyen el escalado, la planificación de la capacidad o la revisión de índices, como descartar índices no utilizados y refinar las asignaciones.

Captura de diagnósticos para soporte

Cuando no puedas resolver un problema localmente, captura lo siguiente antes de abrir un caso de soporte:

1. mongot registros que cubren el período de tiempo del problema más una hora antes. Reenvíe los registros mongod para la misma ventana.

2. FTDC para la instancia mongot afectada. Consulte Registros de mongot y FTDC.

3. Instantáneas del tablero de las métricas durante el período de tiempo del problema.

4. Versiones de mongot y mongod.

5. Qué cambió, como implementaciones recientes, cambios de configuración o patrones de tráfico.

6. Pasos para reproducir el problema, si puede reproducirlo on-demand.