/ /

mongot 로그 및 FTDC

mongot MongoDB Search 및 MongoDB 벡터 검색의 문제를 진단하는 데 도움이 되는 두 개의 호스트 진단 표면을 노출합니다.

로그: 경고 및 오류를 포함하여 mongot 활동을 읽을 수 있는 형식으로 기록한 것입니다.
FTDC(전시간 진단 데이터 캡처): 매초 세부 내부 상태를 캡처하는 바이너리 진단 스트림으로, 지원 핸드오프용입니다.

로그를 사용하여 사고를 조사하고 MongoDB 지원 사례를 준비할 때 두 개의 표면을 모두 캡처합니다.

로그

mongot 로그는 경고 및 오류를 포함하여 프로세스 활동을 기록합니다. 로그를 사용하여 스타트업이 완료되는지 확인하고 정상 상태 건강을 모니터링하고 실패를 조사합니다.

로그 대상

mongot 이 로그를 쓰는 곳은 배포 유형에 따라 다릅니다.

배포 유형	기본값 대상
Linux tarball	`stdout` 및 `stderr`, 또는 `mongot` YAML 구성에서 `logging.logPath` 을 설정한 경우 파일을 사용합니다.
컨테이너	`stdout` 및 `stderr`. `docker logs <container>`로 로그를 조회합니다.
`atlas-local`	`stdout` 및 컨테이너 내의 `stderr` 입니다. `docker logs`로 로그를 조회합니다.
쿠버네티스 오퍼레이터	`stdout` 및 팟의 `stderr`. `kubectl logs <pod>`로 로그를 조회하고 클러스터 로그 플랫폼으로 전송합니다.

로그 상세도

mongot 설정 파일에 지정된 logging.verbosity 옵션은 다음 수준을 허용합니다.

수준	사용 시기
`DEBUG`	특정 실패를 조사할 때. 이 레벨은 몇 일이 아닌 몇 시간 동안 유지합니다.
`ERROR`	`WARN` 문제에 대한 컨텍스트를 잃으므로 생산에 적합하지 않습니다.
`INFO`	기본값. 제작용에 적합합니다.
`TRACE`	엔지니어링 및 지원 딥다이브에만 해당합니다. 자세한 설명을 포함합니다.
`WARN`	로그 볼륨을 줄이고 오류에 대한 별도 경고를 설정해야 할 때 사용합니다.

mongot 시작 시 상세 수준을 읽습니다. 변경하려면 mongot을(를) 다시 시작하십시오.

로그 형식

mongot 줄당 하나에 하나의 JSON 객체가 있는 구조화된 JSON 로그를 배출합니다. 이 형식은 mongot 로그를 mongod 구조화된 로그 형식과 정렬합니다.

각 mongot 로그 엔트리에는 t, s, svc, ctx, n, msg 및 선택 사항인 attr 등의 필드가 포함됩니다. 예시:

{"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"}}

각 로그 객체에는 다음 필드가 포함되어 있습니다.

필드	설명
`t`	UTC 및 ISO-8601 형식의 타임스탬프입니다.
`s`	심각도. `TRACE`, `DEBUG`, `INFO`, `WARN` 또는 `ERROR` 중 하나.
`svc`	엔트리를 발생한 서비스(`MONGOT` 등).
`ctx`	실행 컨텍스트(예: 스레드 또는 작업 이름).
`n`	로거 이름.
`msg`	사람이 읽을 수 있는 메시지입니다.
`attr`	`startTime`, `numQueued`, `indexGenerationId` 등 이벤트 특정 구조화된 속성은 선택 사항입니다. `mongot` 은 null 값과 빈 값을 생략합니다.

스타트업 시 확인할 사항

정상적인 mongot 스타트업은 기본 INFO 상세 수준에서 식별 가능한 이벤트 시퀀스를 발생시킵니다. 특정 문자열보다는 이러한 이벤트를 찾아보세요.

이벤트	메시지 텍스트
인덱스에 대한 초기 동기화가 시작됩니다.	`Beginning initial sync.` `attr.startTime` 과 `attr.indexGenerationId`가 포함된 `BufferlessInitialSyncManager`에서.
초기 동기화 큐 활동	`Queued initial syncs.` `attr.numQueued`이 있는 `InitialSyncQueue`에서.
시작 시 디스크 기반 재시작 검사	`Replication URIs unavailable, skipping disk-based restart check` `DefaultConfigManager` 에서. 복제가 연결되는 동안 일시적으로 예상됩니다.
종료됩니다	`Shutting down.` `DefaultConfigManager`에서 정상적으로 종료될 때.

추가 정보 행은 스타트업 시 표시됩니다. 이전 이벤트는 확인을 위한 부하를 경디는 이벤트입니다.

다음 지표는 스타트업이 완료되지 않았음을 보여줍니다.

표시기	작업
클러스터에 인덱스 컬렉션이 있어도 `Beginning initial sync.` 이벤트가 표시되지 않습니다. `mongot` 이 초기 동기화 단계에 도달하지 않았습니다.	인증 또는 복제 URI 오류에 대해 로그에서 이전 내용을 찾아보세요.
`Beginning initial sync.` 이벤트 다음에 `Exception requiring resync` 또는 `InitialSyncException`가 있습니다. 동기화가 시작되었지만 실패했습니다.	수정하려면 자체 관리형 mongot 배포 문제 해결을(를) 참조하십시오.
`Replication URIs unavailable, skipping disk-based restart check` 메시지가 몇 초 이상 반복됩니다. `mongot` 은 `mongod` 구성을 기다리고 있습니다.	`mongod` `mongotHost` 매개변수를 확인합니다.

안정 상태에서 찾아야 할 사항

정상 상태에서는 건강한 로그가 대부분 무음입니다. 병합 및 FTDC 틱과 같은 배경 작업에서의 주기적인 정보 메시지와 일시적인 클라이언트 동작에 대한 가끔의 WARN 항목을 예상합니다. ERROR 또는 Exception 항목은 예상하지 마십시오.

다음의 정상 상태 로그 패턴에 주의해야 합니다.

패턴	의미
`Exception requiring resync occurred during steady state replication` (`SteadyStateException`)	`mongot` oplog에서 위치를 잃어 다시 동기화하고 있습니다. `mongod` oplog가 너무 작거나 `mongot` 이 너무 느린 경우 oplog가 롤오버되었거나 다운스트림 오류가 발생했습니다. 지원을 위해 주변 5분을 캡처합니다.
`CollectionScan died due to position in capped collection being deleted` (`CappedPositionLost`, error 136)	`mongot` 가 추격할 수 있기 전에 oplog가 롤오버되었습니다. `mongod` oplog 크기를 늘리거나 상위 `mongot`의 속도 저하 원인을 수정하거나 두 가지 모두 수행합니다.
`Dropping all pooled connections to <host>:<port> due to ShutdownInProgress`	`mongod` 다시 시작 중에는 정상입니다. 해당 `mongod` 다시 시작 없이 자주 반복되는 발생은 연결 풀 문제를 나타냅니다.
문서 매핑 폭발	인덱스가 너무 많은 필드가 있는 문서를 발견했습니다. 이는 일반적으로 동적 매핑이 켜져 있고 문서에 임의 키가 있기 때문입니다. 인덱스가 중단되거나 `mongot` 의 메모리가 부족할 수 있습니다.

이러한 패턴을 수정 절차에 매핑하려면 자체 관리형 mongot 배포 문제 해결을 참조하세요.

로그 검색

mongot 로그는 JSON이므로 jq 는 이를 검색하는 가장 자연스러운 도구입니다. 다음 예시에서는 일반적인 쿼리를 보여줍니다.

# 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

JSON이 단일 행이므로 grep 도 작동합니다.

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

Elasticsearch, Splunk, DataDog 등과 같은 로그 플랫폼의 경우 텍스트 대신 s:ERROR, n:<logger> 또는 attr.<key> 로 필터링합니다. 필드는 안정적이지만 전체 텍스트 패턴은 릴리즈 간에 이동할 수 있습니다.

여러 mongot 인스턴스를 실행하는 배포서버의 경우 로그 전송 태그에 인스턴스 식별자를 포함하세요. 인스턴스별로 필터링할 수 있도록 합니다.

로그 분석 팁

mongot 로그를 분석할 때 다음 사항에 유의하세요:

로그에 항상 메시지에 인덱스 이름이 포함되지 않습니다. 인덱싱 실패의 경우 관련 로그 행은 동일한 로그어 컨텍스트에서 여러 행 이전이나 이후에 나타날 수 있습니다. 단일 행이 아니라 창을 캡처합니다.
동일한 시간 창에서 mongot 로그와 mongod 로그를 상호 참조합니다. 많은 mongot 오류는 mongod 이벤트의 하단에 있습니다.
MongoDB 지원 사례를 열 경우 필터링된 ERROR 줄 집합이 아니라 전체 로그 파일 또는 널은 시간 창을 보냅니다.

FTDC

FTDC 는 매초 디스크에 상세한 내부 상태를 캡처하는 바이너리 진단 스트림입니다. FTDC는 MongoDB 기술 서비스 팀에서 mongot 문제를 진단하기 위해 사용하는 표준 아티팩트입니다.

FTDC에 포함되는 내용

FTDC 샘플에는 Prometheus 지표와 동일한 카테고리의 데이터가 포함되어 있으며, mongot 이 외부에 노출하지 않는 내부 상태도 포함됩니다.

힙, 가비지 컬렉션 및 스레드를 포함하여 프로세스 및 JVM 상태를 처리합니다.
인덱스 별 인덱싱 통계
연산자별 쿼리 지연 시간
복제 상태 및 oplog 위치
실행자 푸일 상태
Lucene 병합 및 캐시 상태
구성 및 라이프사이클 이벤트
연결 풀 상태

FTDC 파일 위치

기본적으로 mongot 은 mongod 가 <storage.dbPath>/diagnostic.data/에 사용하는 동일한 귀칙에 따라 FTDC 파일을 <storage.dataPath>/diagnostic.data/에 쓰기합니다.

storage.dataPath 이 /var/lib/mongot로 설정된 mongot 인스턴스의 경우 FTDC 파일은 /var/lib/mongot/diagnostic.data/에 있습니다.

mongot 타임스탬프가 있는 파일의 이름을 지정하고 자동으로 로테이트합니다. 파일 크기는 일반적으로 다음과 같습니다.

파일당 수백 KB
부하 시 시간당 여러 개의 파일
부하에 따라 mongot 인스턴스당 하루 약 1 GB

디스크에 있는 FTDC 보관 디렉토리의 총 크기는 advancedConfigs.ftdc.directorySizeMb으로 제한됩니다.

중요

mongot FTDC 파일을 자동으로 회전합니다. 인시던트 동안 FTDC 파일을 수동으로 삭제하지 마십시오. MongoDB 지원 팀은 문제 진단 시 FTDC 파일을 요청합니다.

FTDC 구성

FTDC는 기본적으로 활성화되어 있습니다. 기본값을 재정의하려면 mongot YAML 구성의 advancedConfigs.ftdc 블록 아래에 다음 옵션을 설정합니다.

옵션	기본값	설명
`enabled`	`true`	FTDC를 활성화합니다. `false`일 경우 `mongot` 은 FTDC 데이터를 캡처하지 않습니다.
`directorySizeMb`	`100`	FTDC 보관 디렉토리의 최대 총 크기(메가바이트 단위). 최소한 `10` 이고 `fileSizeMb`보다 큰야 합니다.
`fileSizeMb`	`10`	개별 FTDC 보관 파일의 최대 크기(메가바이트 단위). 최소 `1` 이고 `directorySizeMb`보다 작아야 합니다.
`collectionPeriodMillis`	`1000`	`mongot` 이 FTDC에 지표를 수집하는 간격(밀리초). `100` 이상이어야 합니다.

대부분의 배포서버에서는 기본값이 적절합니다. 특정한 디스크 사용 요구 사항이 있는 경우에만 재정의하세요. 이 설정에 대해 자세히 알아보려면 고급 FTDC 설정을 참조하세요.

지원을 위한 FTDC 캡처

MongoDB 지원에 케이스를 열 때 문제 발생 기간을 포함하여 영향을 받은 mongot 인스턴스의 전체 diagnostic.data/ 디렉토리를 보냅니다. 디렉토리를 번들하고 압축합니다.

Linux tarball 배포의 경우 디렉토리를 번들합니다.

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

컨테이너 배포의 경우 먼저 컨테이너에서 디렉토리를 복사합니다.

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

Kubernetes 연산자 배포서버의 경우 먼저 팝에서 디렉토리를 복사합니다.

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

지원 사례에 다음 내용을 포함하세요.

FTDC 번들.
동일한 시간 창을 보감하는 mongot 로그 파일과 그 전 1시간의 버퍼가 있습니다.
동일한 창을 덮는 프라이머리의 mongod 로그 파일입니다.
mongot 버전, mongod 버전 및 해당하는 경우 Kubernetes Operator 버전입니다.
문제를 처음 관찰한 시간 스탬프.
구성, 트래픽 또는 업그레이드와 같이 당시 배포서버에서 변경된 내용에 대한 설명입니다.

FTDC의 민감한 데이터

FTDC에는 운영 지표와 내부 상태가 포함되어 있지만 원시 문서 데이터 또는 사용자 쿼리 문자열은 포함되어 있지 않습니다. FTDC는 일반적으로 사니타이저 없이 MongoDB 지원에 보내도 안전합니다. 컴플라이언스 정책이 더 엄격하면 보내기 전에 보안 팀과 함께 캡처된 필드를 검토합니다.

로그의 경우는 다릅니다. 로그 수준에 따라 로그 라인에는 쿼리 텍스트, 문서 식별자 또는 기타 애플리케이션 수준 데이터가 포함될 수 있습니다. 제한적인 컴플라이언스 환경에서 로그 파일을 전송하기 전에 해당 파일을 검토하십시오.

돌아가기

mongot 지표 참조

권장 경고