Registros de mongot y FTDC

Destinos de registro

El lugar donde mongot guarda los registros depende del tipo de implementación:

Nivel de verbosidad del registro

La opción logging.verbosity especificada en su archivo de configuración mongot acepta los siguientes niveles:

mongot lee el nivel de verbosidad al iniciar. Para cambiarlo, reinicie mongot.

Formato de registro

mongot emite registros JSON estructurados, con un objeto JSON por línea. Este formato alinea los registros mongot con el formato de registro estructurado mongod.

Cada entrada de registro mongot incluye campos como t, s, svc, ctx, n, msg y attr opcional. Por ejemplo:

{"t":"2026-06-22T14:03:41.582+0000","s":"INFO","svc":"MONGOT","ctx":"indexing-lifecycle-0","n":"com.xgen.mongot.replication.mongodb.initialsync.BufferlessInitialSyncManager","msg":"Beginning initial sync.","attr":{"startTime":"2026-06-22T14:03:41.582+0000","indexGenerationId":"6857f3b6e4b04c2a9d1f0a12-f6-u0-a0"}}

Cada objeto de registro contiene los siguientes campos:

Qué buscar en la empresa emergente

Una empresa emergente mongot saludable emite una secuencia de eventos identificables en el nivel de verbosidad INFO por defecto. Busque estos eventos en lugar de cadenas literales específicas:

Existen líneas de información adicionales en el inicio. Los eventos anteriores son los que soportan la carga para la verificación.

Los siguientes indicadores muestran que la empresa emergente no se completó:

Qué buscar en estado estable

En estado estable, los registros saludables son en su mayoría silenciosos. Espere mensajes informativos periódicos de tareas en segundo plano, como fusiones y tics de FTDC, y entradas WARN ocasionales para el comportamiento transitorio del cliente. No espere entradas ERROR o Exception.

Los siguientes patrones de registro de estado estable requieren atención:

Para asignar estos patrones a los procedimientos de corrección, consulte Solución de problemas de implementaciones de mongot autogestionadas.

Registros de búsqueda

Dado que los registros de mongot son JSON, jq es la herramienta más natural para buscarlos. Los siguientes ejemplos muestran query comunes:

# All errors
jq 'select(.s == "ERROR")' mongot.log
# Initial sync activity
jq 'select(.msg | startswith("Beginning initial sync"))' mongot.log
# Replication or sync from specific loggers
jq 'select(.n | test("BufferlessInitialSyncManager|InitialSyncQueue|InitialSyncManager"))' mongot.log
# Resync events
jq 'select(.msg | test("requiring resync|InitialSyncException|SteadyStateException"))' mongot.log
# Connection-pool churn
jq 'select(.msg | test("Dropping all pooled connections|ShutdownInProgress"))' mongot.log
# Embedding-related entries
jq 'select(.msg | test("embedding|voyage"; "i"))' mongot.log

Dado que el JSON es de una sola línea, grep también funciona:

grep '"s":"ERROR"' mongot.log
grep '"msg":"Beginning initial sync\.' mongot.log
grep -E '"n":"[^"]*(BufferlessInitialSyncManager|InitialSyncQueue)' mongot.log

Para plataformas de registro como Elasticsearch, Splunk y Datadog, filtre por s:ERROR, n:<logger> o attr.<key> en lugar de texto. Los campos son estables, pero los patrones de texto completo pueden moverse entre versiones.

Para las implementaciones que ejecutan varias instancias de mongot, incluya el identificador de instancia en las etiquetas de reenvío de registros para poder filtrar por instancia.

Sugerencias para el análisis de registros

Tenga en cuenta los siguientes puntos al analizar los registros de mongot:

• Los registros no siempre incluyen el nombre del índice en el mensaje. Para errores de indexación, la línea de registro relevante podría aparecer varias líneas antes o después en el mismo contexto de registrador. Capture una ventana, no una sola línea.

• Cruce los registros de mongot con los registros de mongod en la misma ventana de tiempo. Muchos errores de mongot son posteriores a los eventos de mongod.

• Si abre un caso de soporte de MongoDB, envíe la entrada de registro completa o una ventana de tiempo amplia, en lugar de un conjunto filtrado de ERROR líneas.

Qué contiene FTDC

Las muestras de FTDC incluyen datos de las mismas categorías que las métricas de Prometheus, además del estado interno que mongot no expone externamente:

• Estado del proceso y de la JVM, incluidos el montón, la recolección de elementos no utilizados y los subprocesos

• Estadísticas de indexación por índice

• Latencias de query por operador

• Estado de replicación y posición del oplog

• Estado del pool del ejecutor

• Estado de fusión y caché de Lucene

• Configuración y eventos del ciclo de vida

• Estado del pool de conexiones

Ubicación del archivo FTDC

Por defecto, mongot guarda los archivos FTDC en <storage.dataPath>/diagnostic.data/, la misma convención que mongod utiliza con <storage.dbPath>/diagnostic.data/.

Para una instancia mongot con storage.dataPath establecido en /var/lib/mongot, los archivos FTDC se encuentran en /var/lib/mongot/diagnostic.data/.

mongot nombra archivos con marcas de tiempo y los rota automáticamente. Los tamaños de archivo suelen ser:

• Unos pocos cientos de KB por archivo

• Varios archivos por hora bajo carga

• Aproximadamente 1 GB por día por instancia de mongot, según la carga

El tamaño total del directorio de ficheros FTDC en el disco está limitado por advancedConfigs.ftdc.directorySizeMb.

Configurar FTDC

FTDC está habilitado por defecto. Para anular los valores por defecto, establezca las siguientes opciones en el bloque advancedConfigs.ftdc de la configuración YAML mongot:

Para la mayoría de las implementaciones, los valores por defecto son apropiados. Anúlelos solo si tiene un requisito específico de uso de disco. Para obtener más información sobre estas configuraciones, consulte Configuración avanzada de FTDC.

Capture FTDC para soporte

Cuando abra un caso con el soporte de MongoDB, envíe todo el directorio de diagnostic.data/ de la instancia de mongot afectada, que cubra el período del problema. Agrupe y comprima el directorio.

Para una implementación de tarball de Linux, agrupe el directorio:

tar -czf mongot-ftdc-$(hostname)-$(date -u +%Y%m%dT%H%M%S).tar.gz <dataPath>/diagnostic.data/

Para una implementación de contenedor, primero copie el directorio fuera del contenedor:

docker cp <container>:/<dataPath>/diagnostic.data ./mongot-ftdc
tar -czf mongot-ftdc.tar.gz ./mongot-ftdc

Para una implementación de Kubernetes operador, primero copie el directorio fuera del pod:

kubectl cp <namespace>/<pod>:<dataPath>/diagnostic.data ./mongot-ftdc
tar -czf mongot-ftdc.tar.gz ./mongot-ftdc

Incluya lo siguiente en el caso de soporte:

• El paquete FTDC.

• El archivo de registro de mongot que cubre la misma ventana de tiempo, más un búfer de una hora antes.

• El archivo de registro mongod en el primario que cubre la misma ventana.

• La versión mongot, la versión mongod y la versión del operador de Kubernetes, si corresponde.

• Una marca de tiempo de cuándo observó por primera vez el problema.

• Una descripción de lo que cambió en la implementación en ese momento, como la configuración, el tráfico o las actualizaciones.

Datos confidenciales en FTDC

FTDC contiene métricas operativas y estado interno, no datos de documentos sin procesar ni string del query de usuario. Por lo general, FTDC se puede enviar a MongoDB Support de forma segura sin necesidad de desinfección. Si su política de cumplimiento es más estricta, revise los campos capturados con su equipo de seguridad antes de enviarlos.

Lo mismo no ocurre con los registros. Las líneas de registro pueden incluir texto de query, identificadores de documentos u otros datos de nivel de aplicación, según el nivel de registro. Revise las entradas de registro antes de enviarlos en entornos de cumplimiento restrictivos.