Docs Menu
Docs Home
/
MongoDB 매뉴얼
/

로그 메시지

이 페이지의 내용

  • 개요
  • 구조화된 로깅
  • 로그 메시지 필드 유형
  • 상세도 수준
  • 로그 편집
  • 구조화된 로그 메시지 구문 분석
  • 로그 메시지 예시
  • 로그 다운로드

정상 작동의 일환으로, MongoDB는 들어오는 연결, 명령 실행, 발생한 문제 등의 항목을 포함한 이벤트의 실행 로그를 유지합니다. 일반적으로 로그 메시지는 문제를 진단하고, 배포를 모니터링하고, 성능을 조정하는 데 유용합니다.

로그 메시지를 얻으려면 다음 방법 중 하나를 사용할 수 있습니다.

mongod / mongos 인스턴스는 모든 로그 메시지를 구조화된 JSON 형식으로 출력합니다. 로그 항목은 일련의 키-값 쌍으로 작성되고 각 키는 '심각도'와 같이 로그 메시지 필드 유형을 나타내며 각 해당 값은 '정보'와 같이 해당 필드 유형에 대한 관련 로깅 정보를 기록합니다. 이전에는 로그 항목이 일반 텍스트로 출력되었습니다.

예시

다음은 MongoDB 로그 파일에 표시되는 JSON 형식의 로그 메시지 예시입니다.

{"t":{"$date":"2020-05-01T15:16:17.180+00:00"},"s":"I", "c":"NETWORK", "id":12345, "ctx":"listener", "msg":"Listening on","attr":{"address":"127.0.0.1"}}

JSON 로그 항목은 가독성을 위해 Prettyprint 할 수 있습니다. 다음은 동일한 로그 항목이 Prettyprint 것입니다.

{
"t": {
"$date": "2020-05-01T15:16:17.180+00:00"
},
"s": "I",
"c": "NETWORK",
"id": 12345,
"ctx": "listener",
"msg": "Listening on",
"attr": {
"address": "127.0.0.1"
}
}

예를 들어 이 로그 항목에서 s 키는 심각도를 의미하며 I 값은 '정보'를 의미합니다. c구성 요소를 나타내며 NETWORK는 특정 메시지가 '네트워크' 구성 요소와 관련이 있음을 나타냅니다. 다양한 필드 유형은 로그 메시지 필드 유형 섹션에 설명되어 있습니다.

키-값 쌍을 사용한 구조화된 로깅을 사용하면 자동화된 도구나 로그 수집 서비스에서 효율적으로 구문 분석할 수 있으며, 로그 메시지에 대한 프로그래밍 방식의 검색과 분석을 더 쉽게 수행할 수 있습니다. 구조화된 로그 메시지 분석의 예시는 구조화된 로그 메시지 구문 분석하기 섹션에서 확인할 수 있습니다.

다음으로 전송되는 출력을 포함해 모든 로그는 JSON 형식으로 출력됩니다.

getLog 명령의 출력도 JSON 형식입니다.

각 로그 항목은 다음과 같은 레이아웃과 필드 순서를 따르는 Relaxed Extended JSON v2.0 사양을 따르는 독립된 JSON 객체로 출력됩니다.

{
"t": <Datetime>, // timestamp
"s": <String>, // severity
"c": <String>, // component
"id": <Integer>, // unique identifier
"ctx": <String>, // context
"msg": <String>, // message body
"attr": <Object> // additional attributes (optional)
"tags": <Array of strings> // tags (optional)
"truncated": <Object> // truncation info (if truncated)
"size": <Object> // original size of entry (if truncated)
}

필드 설명:

필드 이름
유형
설명

t

Datetime

ISO- 형식의 로그 메시지8601 타임스탬프입니다. 예시 는 타임스탬프를 참조하세요.

s

문자열

로그 메시지의 짧은 심각도 코드입니다. 예시 는 심각도를 참조하세요.

c

문자열

로그 메시지의 전체 구성 요소 문자열입니다. 예시 는 구성 요소를 참조하세요.

id

Integer

로그 성명서 고유 식별자입니다. 예시 는 알려진 로그 ID 로 필터링을 참조하세요.

ctx

문자열

로그 문을 생성한 스레드의 이름입니다.

svc

문자열

컨텍스트에서 로그 성명서 이 작성된 서비스의 이름입니다. ' 샤드'는 S , '라우터'는 R , '알 수 없음' 또는 '없음'은 - 로 표시합니다.

msg

문자열

서버 또는 운전자 에서 전달된 출력 메시지를 기록합니다. 필요한 경우 JSON 사양에 따라 메시지가 이스케이프 처리됩니다.

attr

객체

추가 로그 속성을 위한 하나 이상의 키-값 쌍입니다. 로그 메시지에 추가 속성이 포함되어 있지 않으면 attr 객체가 생략됩니다.

속성 값은 메시지에 따라 메시지 본문에서 키 이름으로 참조될 msg 수 있습니다. 필요한 경우 JSON 사양에 따라 속성이 이스케이프 처리됩니다.

tags

문자열 배열

로그 문에 적용 가능한 모든 태그를 나타내는 문자열입니다. 예를 들어 ["startupWarnings"]입니다.

truncated

객체

해당하는 경우 로그 메시지 잘라내기에 대한 정보입니다. 로그 항목에 잘린 속성이 하나 이상 포함된 경우에만 attr 포함됩니다.

size

객체

메시지속성 필드는 완화된 확장 JSON v2.0 사양에 따라 필요에 따라 제어 문자를 이스케이프 처리합니다.

대체 문자
시퀀스 이스케이프

따옴표 (")

\"

백슬래시 (\)

\\

백스페이스 (0x08)

\b

폼피드 (0x0C)

\f

뉴라인 (0x0A)

\n

캐리지 리턴 (0x0D)

\r

가로 탭 (0x09)

\t

위에 나열되지 않은 제어 문자는 \uXXXX로 이스케이프됩니다. 여기서 " XXXX " 는 16진수의 유니코드 코드 포인트입니다. 잘못된 UTF-8 인코딩이 있는 바이트는 \ufffd로 표시되는 유니코드 대체 문자로 대체됩니다.

메시지 이스케이프의 예는 예시 섹션에나와 있습니다.

속성maxLogSizeKB(기본값: 10KB)로 정의된 최대 크기를 초과하는 경우 해당 속성은 잘려나갑니다. 잘린 속성은 구성된 제한을 초과하는 로그 데이터를 생략하지만 항목의 JSON 형식을 유지하여 항목이 파싱 가능한 상태로 유지되도록 합니다.

다음은 잘린 속성이 있는 로그 항목의 예입니다.

{"t":{"$date":"2020-05-19T18:12:05.702+00:00"},"s":"I", "c":"SHARDING", "id":22104, "ctx":"conn33",
"msg":"Received splitChunk request","attr":{"request":{"splitChunk":"config.system.sessions",
"from":"production-shard1","keyPattern":{"_id":1},"epoch":{"$oid":"5ec42172996456771753a59e"},
"shardVersion":[{"$timestamp":{"t":1,"i":0}},{"$oid":"5ec42172996456771753a59e"}],"min":{"_id":{"$minKey":1}},
"max":{"_id":{"$maxKey":1}},"splitKeys":[{"_id":{"id":{"$uuid":"00400000-0000-0000-0000-000000000000"}}},
{"_id":{"id":{"$uuid":"00800000-0000-0000-0000-000000000000"}}},
...
{"_id":{"id":{"$uuid":"26c00000-0000-0000-0000-000000000000"}}},{"_id":{}}]}},
"truncated":{"request":{"splitKeys":{"155":{"_id":{"id":{"type":"binData","size":21}}}}}},
"size":{"request":46328}}

이 경우 request 속성이 잘리고 잘림을 트리거한 해당 하위 필드 _id의 특정 인스턴스 (즉, maxLogSizeKB을 초과하게 만든 원인)가 데이터 없이 {"_id":{}}로 인쇄됩니다. 나머지 request 속성은 생략됩니다.

하나 이상의 잘린 속성이 포함된 로그 항목에는 로그 항목의 각 잘린 속성에 대해 다음 정보를 제공하는 truncated 객체가 포함되어 있습니다.

  • 잘린 속성

  • 해당되는 경우 잘림을 트리거한 해당 속성의 특정 하위 개체입니다.

  • 잘린 필드의 데이터 type 입니다.

  • 잘린 필드의 size 입니다.

잘린 속성이 있는 로그 항목은 항목 끝에 잘리기 전 속성의 원래 크기(이 경우 46328 또는 약 46KB)를 나타내는 추가 size 필드를 포함할 수도 있습니다. 이 마지막 size 필드는 truncated 객체의 size 필드와 다른 경우, 즉 위의 예에서와 같이 속성의 전체 객체 크기가 잘린 하위 객체의 크기와 다른 경우에만 표시됩니다.

파일 또는 syslog 로그 대상으로 출력할 때 고정 너비 글꼴로 볼 때 가독성을 높이기 위해 심각도, 컨텍스트ID 필드 뒤에 패딩이 추가됩니다.

다음 MongoDB 로그 파일 발췌는 이 패딩을 보여줍니다.

{"t":{"$date":"2020-05-18T20:18:12.724+00:00"},"s":"I", "c":"CONTROL", "id":23285, "ctx":"main","msg":"Automatically disabling TLS 1.0, to force-enable TLS 1.0 specify --sslDisabledProtocols 'none'"}
{"t":{"$date":"2020-05-18T20:18:12.734+00:00"},"s":"W", "c":"ASIO", "id":22601, "ctx":"main","msg":"No TransportLayer configured during NetworkInterface startup"}
{"t":{"$date":"2020-05-18T20:18:12.734+00:00"},"s":"I", "c":"NETWORK", "id":4648601, "ctx":"main","msg":"Implicit TCP FastOpen unavailable. If TCP FastOpen is required, set tcpFastOpenServer, tcpFastOpenClient, and tcpFastOpenQueueSize."}
{"t":{"$date":"2020-05-18T20:18:12.814+00:00"},"s":"I", "c":"STORAGE", "id":4615611, "ctx":"initandlisten","msg":"MongoDB starting","attr":{"pid":10111,"port":27001,"dbPath":"/var/lib/mongo","architecture":"64-bit","host":"centos8"}}
{"t":{"$date":"2020-05-18T20:18:12.814+00:00"},"s":"I", "c":"CONTROL", "id":23403, "ctx":"initandlisten","msg":"Build Info","attr":{"buildInfo":{"version":"4.4.0","gitVersion":"328c35e4b883540675fb4b626c53a08f74e43cf0","openSSLVersion":"OpenSSL 1.1.1c FIPS 28 May 2019","modules":[],"allocator":"tcmalloc","environment":{"distmod":"rhel80","distarch":"x86_64","target_arch":"x86_64"}}}}
{"t":{"$date":"2020-05-18T20:18:12.814+00:00"},"s":"I", "c":"CONTROL", "id":51765, "ctx":"initandlisten","msg":"Operating System","attr":{"os":{"name":"CentOS Linux release 8.0.1905 (Core) ","version":"Kernel 4.18.0-80.11.2.el8_0.x86_64"}}}

MongoDB 구조화된 로깅으로 작업할 때 타사 jq 명령줄 유틸리티는 로그 항목을 쉽고 예쁘게 인쇄하고 강력한 키 기반 매칭 및 필터링을 하는 데 유용한 도구입니다.

jq 는 오픈 소스 JSON 파서이며 Linux, Windows, macOS에서 사용할 수 있습니다.

jq를 사용하여 다음과 같이 로그 항목을 pretty-print 할 수 있습니다.

  • 전체 로그 파일을 pretty-print 합니다.

    cat mongod.log | jq
  • 가장 최근 로그 항목을 pretty-print 합니다.

    cat mongod.log | tail -1 | jq

MongoDB 구조화된 로그로 작업하는 더 많은 예는 구조화된 로그 메시지 구문 분석하기 섹션에서 확인할 수 있습니다.

MongoDB 로그 메시지는 파일, syslog 또는 stdout (표준 출력)으로 출력할 수 있습니다.

로그 출력 대상을 구성하려면 구성 파일 또는 명령줄에서 다음 설정 중 하나를 사용합니다.

구성 파일:
명령줄:

파일이나 syslog 중 하나를 지정하지 않으면 모든 로깅 출력이 stdout으로 전송됩니다.

로깅 설정 및 옵션의 전체 목록은 다음을 참조하세요.

구성 파일:
명령줄:

참고

파일 또는 syslog 로그 대상을 사용하지 않을 때 시작 중 치명적인 오류 또는 잘못 구성된 로깅 설정과 관련된 메시지와 같이 stderr(표준 오류)로 전송되는 오류 메시지는 로그 출력 대상 설정의 영향을 받지 않으며 일반 텍스트 형식으로 stderr에 인쇄됩니다.

타임스탬프 필드 유형은 기록된 이벤트가 발생한 정확한 날짜와 시간을 나타냅니다.

{
"t": {
"$date": "2020-05-01T15:16:17.180+00:00"
},
"s": "I",
"c": "NETWORK",
"id": 12345,
"ctx": "listener",
"msg": "Listening on",
"attr": {
"address": "127.0.0.1"
}
}

파일 또는 syslog [1]에 로깅할 때 타임스탬프의 기본 형식은 iso8601-local입니다. 타임스탬프 형식을 수정하려면 --timeStampFormat 런타임 옵션 또는 systemLog.timeStampFormat 설정을 사용합니다.

타임스탬프 필드를 기준으로 필터링하는 로그 구문 분석 예는 날짜 범위별 필터링을 참조하세요.

참고

ctime 타임스탬프 형식은 더 이상 지원되지 않습니다.

[1] syslog에 로깅하는 경우, syslog 데몬은 메시지를 로깅할 때 타임스탬프를 생성하며, MongoDB가 메시지를 발행할 때는 생성하지 않습니다. 이로 인해 특히 시스템 부하가 심한 경우 로그 항목에 잘못된 타임스탬프가 표시될 수 있습니다.

심각도 필드 유형은 기록된 이벤트와 관련된 심각도 수준을 나타냅니다.

{
"t": {
"$date": "2020-05-01T15:16:17.180+00:00"
},
"s": "I",
"c": "NETWORK",
"id": 12345,
"ctx": "listener",
"msg": "Listening on",
"attr": {
"address": "127.0.0.1"
}
}

심각도 수준은 "치명적" (가장 심각함)에서 "디버그" (가장 덜 심각함)까지 다양합니다.

수준
설명

F

치명적

E

오류

W

경고

I

정보 제공, 상세도 수준 0

D1 - D5

디버그, 상세도 수준 > 0

버전 부터 4.2 MongoDB 는 특정 디버그 상세 수준을 나타냅니다. 예를 예시, 상세도 수준이 인 2 경우 MongoDB 는 를 D2 표시합니다.

이전 버전에서는 모든 디버그 상세도 수준에 대해 D을 지정하는 MongoDB 로그 메시지가 있었습니다.

다양한 구성 요소의 상세 수준을 지정하여 MongoDB가 출력하는 정보디버그 메시지의 양을 결정할 수 있습니다. 이 수준 이상의 심각도 카테고리는 항상 표시됩니다. [2] 상세 수준을 설정하려면 로그 상세 수준 구성을 참조합니다.

컴포넌트 필드 유형은 네트워크 또는 명령과 같이 로깅된 이벤트가 속해 있는 카테고리를 나타냅니다.

{
"t": {
"$date": "2020-05-01T15:16:17.180+00:00"
},
"s": "I",
"c": "NETWORK",
"id": 12345,
"ctx": "listener",
"msg": "Listening on",
"attr": {
"address": "127.0.0.1"
}
}

각 구성 요소는 자체 상세도 필터를 통해 개별적으로 구성할 수 있습니다. 사용 가능한 구성 요소는 다음과 같습니다:

ACCESS

인증 등 액세스 제어와 관련된 메시지입니다. ACCESS 구성 요소의 로그 수준을 지정하려면 systemLog.component.accessControl.verbosity 설정을 사용하세요.

COMMAND

데이터베이스 명령과 관련된 메시지(예: count)입니다. COMMAND 구성 요소에 대한 로그 수준을 지정하려면 systemLog.component.command.verbosity 설정을 사용합니다.

CONTROL

초기화와 같은 제어 활동과 관련된 메시지입니다. CONTROL 구성 요소에 대한 로그 수준을 지정하려면 systemLog.component.control.verbosity 설정을 사용합니다.

ELECTION

특히 복제본 세트 투표와 관련된 메시지입니다. ELECTION 구성 요소의 로그 수준을 지정하려면 systemLog.component.replication.election.verbosity 매개 변수를 설정하세요.

REPLELECTION의 상위 구성 요소입니다. systemLog.component.replication.election.verbosity가 설정되지 않은 경우 MongoDB는 ELECTION 구성요소에 대해 REPL 상세 수준을 사용합니다.

FTDC

서버 통계, 상태 메시지 등 진단 데이터 수집 메커니즘과 관련된 메시지입니다. FTDC 구성 요소에 대한 로그 수준을 지정하려면 systemLog.component.ftdc.verbosity 설정을 사용합니다.

GEO

GeoJSON 모양 확인 등 지리공간 모양 분석과 관련된 메시지입니다. GEO 구성 요소의 로그 수준을 지정하려면 systemLog.component.geo.verbosity 매개변수를 설정하세요.

INDEX

인덱스 생성과 같은 인덱싱 작업과 관련된 메시지입니다. INDEX 구성 요소에 대한 로그 수준을 지정하려면 systemLog.component.index.verbosity 매개 변수를 설정합니다.

INITSYNC

초기 동기화 작업과 관련된 메시지입니다. INITSYNC 구성 요소의 로그 수준을 지정하려면 systemLog.component.replication.initialSync.verbosity 매개변수를 설정하세요.

REPLINITSYNC의 상위 구성 요소입니다. systemLog.component.replication.initialSync.verbosity가 설정되지 않은 경우 MongoDB는 INITSYNC 구성요소에 대해 REPL 상세 수준을 사용합니다.

JOURNAL

특히 스토리지 저널링 작업과 관련된 메시지입니다. JOURNAL 구성 요소에 대한 로그 수준을 지정하려면 systemLog.component.storage.journal.verbosity 설정을 사용합니다.

STORAGEJOURNAL의 상위 구성 요소입니다. systemLog.component.storage.journal.verbosity가 설정되지 않은 경우 MongoDB는 JOURNAL 구성요소에 대해 STORAGE 상세 수준을 사용합니다.

NETWORK

연결 수락과 같은 네트워크 활동과 관련된 메시지입니다. NETWORK 구성 요소의 로그 수준을 지정하려면 systemLog.component.network.verbosity 매개변수를 설정하세요.

QUERY

쿼리 플래너 활동을 포함하여 쿼리와 관련된 메시지입니다. QUERY 구성 요소의 로그 수준을 지정하려면 systemLog.component.query.verbosity 매개변수를 설정하세요.

RECOVERY

스토리지 복구 활동과 관련된 메시지입니다. RECOVERY 구성 요소의 로그 수준을 지정하려면 systemLog.component.storage.recovery.verbosity 설정을 사용하세요.

STORAGERECOVERY의 상위 구성 요소입니다. systemLog.component.storage.recovery.verbosity가 설정되지 않은 경우 MongoDB는 RECOVERY 구성요소에 대해 STORAGE 상세 수준을 사용합니다.

REPL

초기 동기화, 하트비트, 안정적인 상태 복제, 롤백 등 복제본 세트와 관련된 메시지입니다. [2] REPL 구성 요소에 대한 로그 수준을 지정하려면 systemLog.component.replication.verbosity 매개 변수를 설정합니다.

REPLELECTION, INITSYNC, REPL_HBROLLBACK 구성 요소의 상위 구성 요소입니다.

REPL_HB

특히 복제본 세트 하트비트와 관련된 메시지입니다. REPL_HB 구성 요소에 대한 로그 수준을 지정하려면 systemLog.component.replication.heartbeats.verbosity 매개 변수를 설정합니다.

REPLREPL_HB의 상위 구성 요소입니다. systemLog.component.replication.heartbeats.verbosity가 설정되지 않은 경우 MongoDB는 REPL_HB 구성요소에 대해 REPL 상세 수준을 사용합니다.

ROLLBACK

롤백 작업과 관련된 메시지입니다. ROLLBACK 구성 요소에 대한 로그 수준을 지정하려면 systemLog.component.replication.rollback.verbosity 매개 변수를 설정합니다.

REPLROLLBACK의 상위 구성 요소입니다. systemLog.component.replication.rollback.verbosity가 설정되지 않은 경우 MongoDB는 ROLLBACK 구성요소에 대해 REPL 상세 수준을 사용합니다.

SHARDING

mongos 스타트업과 같은 샤딩 활동과 관련된 메시지입니다. SHARDING 구성 요소에 대한 로그 수준을 지정하려면 systemLog.component.sharding.verbosity 설정을 사용합니다.

STORAGE

fsync 명령과 관련된 프로세스 등 저장소 활동과 관련된 메시지입니다. STORAGE 구성 요소에 대한 로그 수준을 지정하려면 systemLog.component.storage.verbosity 설정을 사용합니다.

STORAGEJOURNALRECOVERY의 상위 구성 요소입니다.

TXN

다중 문서 트랜잭션과 관련된 메시지입니다. TXN 구성 요소에 대한 로그 수준을 지정하려면 systemLog.component.transaction.verbosity 설정을 사용합니다.

WRITE

update 명령과 같은 쓰기 작업과 관련된 메시지입니다. WRITE 구성 요소에 대한 로그 수준을 지정하려면 systemLog.component.write.verbosity 설정을 사용합니다.

-

명명된 컴포넌트와 연결되지 않은 메시지. 명명되지 않은 구성 요소의 기본 로그 수준은 systemLog.verbosity 설정에 지정되어 있습니다. systemLog.verbosity 설정은 명명된 구성 요소와 명명되지 않은 구성 요소 모두에 대한 기본 설정입니다.

컴포넌트 필드를 필터링하는 로그 구문 분석 예시는 컴포넌트별 필터링을 참조하세요.

MongoDB 드라이버 및 클라이언트 애플리케이션(mongosh 포함)은 서버에 연결할 때 식별 정보를 보내는 기능이 있습니다. 연결이 설정된 후 클라이언트는 연결을 제거했다가 다시 설정하지 않는 한 식별 정보를 다시 전송하지 않습니다.

이 식별 정보는 로그 항목의 attributes 필드에 포함되어 있습니다. 포함되는 정확한 정보는 클라이언트마다 다릅니다.

다음은 mongosh 연결에서 전송된 클라이언트 데이터 문서가 포함된 샘플 로그 메시지입니다. 클라이언트 데이터는 attributes 필드의 doc 객체에 포함되어 있습니다.

{"t":{"$date":"2020-05-20T16:21:31.561+00:00"},"s":"I", "c":"NETWORK", "id":51800, "ctx":"conn202","msg":"client metadata","attr":{"remote":"127.0.0.1:37106","client":"conn202","doc":{"application":{"name":"MongoDB Shell"},"driver":{"name":"MongoDB Internal Client","version":"4.4.0"},"os":{"type":"Linux","name":"CentOS Linux release 8.0.1905 (Core) ","architecture":"x86_64","version":"Kernel 4.18.0-80.11.2.el8_0.x86_64"}}}}

복제 세트의 보조 구성원이 주 구성원에 대한 연결을 시작하면 유사한 데이터를 전송합니다. 이 시작 연결이 포함된 샘플 로그 메시지는 다음과 같이 나타날 수 있습니다. 클라이언트 데이터는 attributes 필드의 doc 객체에 포함되어 있습니다.

{"t":{"$date":"2020-05-20T16:33:40.595+00:00"},"s":"I", "c":"NETWORK", "id":51800, "ctx":"conn214","msg":"client metadata","attr":{"remote":"127.0.0.1:37176","client":"conn214","doc":{"driver":{"name":"NetworkInterfaceTL","version":"4.4.0"},"os":{"type":"Linux","name":"CentOS Linux release 8.0.1905 (Core) ","architecture":"x86_64","version":"Kernel 4.18.0-80.11.2.el8_0.x86_64"}}}}

클라이언트 데이터를 보여주는 pretty-printed 예시는 예시 섹션을 참조하세요.

클라이언트 정보 및 필수 필드에 대한 전체 설명은 MongoDB 핸드셰이크 사양을 참조하세요.

로깅 상세도 수준을 지정하여 MongoDB가 출력하는 로그 메시지의 양을 늘리거나 줄일 수 있습니다. 상세도 수준은 모든 구성 요소에 대해 함께 조정하거나 특정 명명된 구성 요소에 대해 개별적으로 조정할 수 있습니다.

자세한 정도는 심각도 범주 Informational(정보)Debug(디버그)의 로그 항목에 영향을 줍니다. 이 수준 이상의 심각도 범주는 항상 표시됩니다.

상세 수준을 높은 값으로 설정하여 디버깅 또는 개발을 위한 세부 로깅을 표시하거나, 검증된 프로덕션 배포에서 로그에 대한 쓰기를 최소화하려면 낮은 값으로 설정할 수 있습니다. [2]

현재 상세도 수준을 보려면 db.getLogComponents() 메서드를 사용합니다:

db.getLogComponents()

출력은 다음과 비슷할 수 있습니다.

{
"verbosity" : 0,
"accessControl" : {
"verbosity" : -1
},
"command" : {
"verbosity" : -1
},
...
"storage" : {
"verbosity" : -1,
"recovery" : {
"verbosity" : -1
},
"journal" : {
"verbosity" : -1
}
},
...

초기 verbosity 항목은 모든 구성 요소에 대한 상위 상세 수준을 나타냅니다. accessControl과 같이 뒤에 오는 개별 명명된 구성 요소는 해당 구성 요소에 대한 특정 상세 수준을 나타내며 설정된 경우 해당 특정 구성 요소에 대한 전역 상세 수준을 재정의합니다.

-1은 구성 요소가 상위 구성 요소를 상속한 경우(위의 recovery와 마찬가지로 storage에서 상속받음), 그렇지 않은 경우 전역 상세 수준(위의 command와 마찬가지)을 상속함을 나타냅니다. 상속 관계는 구성 요소 섹션에서 확인할 수 있습니다.

systemLog.verbositysystemLog.component.<name>.verbosity 설정, logComponentVerbosity 매개변수 또는 db.setLogLevel() 방법을 사용하여 상세도 수준을 구성할 수 있습니다. [2]

모든 구성 요소에 대한 기본 로그 수준을 구성하려면 systemLog.verbosity 설정을 사용합니다. 특정 구성 요소의 수준을 구성하려면 systemLog.component.<name>.verbosity 설정을 사용하세요.

예를 들어, 다음 구성은 systemLog.verbosity1로, systemLog.component.query.verbosity2로, systemLog.component.storage.verbosity2로, systemLog.component.storage.journal.verbosity1로 설정합니다.

systemLog:
verbosity: 1
component:
query:
verbosity: 2
storage:
verbosity: 2
journal:
verbosity: 1

mongod 또는 mongos 인스턴스의 구성 파일 또는 명령줄에서 이러한 값을 설정할 수 있습니다.

구성에 명시적으로 지정되지 않은 모든 구성 요소의 상세도 수준은 -1이며, 이는 상위 구성 요소가 있는 경우 상위 구성 요소의 상세도 수준을 상속하고, 없는 경우 전역 상세도 수준(systemLog.verbosity)을 상속함을 나타냅니다.

logComponentVerbosity 매개 변수를 설정하려면 변경할 상세도 설정이 있는 문서를 전달합니다.

예를 들어 다음은 default verbosity level1 으로,query2 로, 을 storage 2 11}로, 을 storage.journal 1 15}로 설정합니다.

db.adminCommand( {
setParameter: 1,
logComponentVerbosity: {
verbosity: 1,
query: {
verbosity: 2
},
storage: {
verbosity: 2,
journal: {
verbosity: 1
}
}
}
} )

이러한 값은 mongosh에서 설정합니다.

db.setLogLevel() 메서드를 사용하여 단일 컴포넌트 로그 수준을 업데이트합니다. 구성 요소의 경우 0 ~ 5의 상세 수준을 지정하거나 -1를 지정하여 상위 구성 요소의 상세도를 상속할 수 있습니다. 예를 들어 다음은 systemLog.component.query.verbosity을 상위 상세도로 설정합니다(기본 상세도).

db.setLogLevel(-1, "query")

이 값은 mongosh에서 설정합니다.

[2](1, 2, 3, 4, 5) 이제 복제본 세트의 세컨더리 멤버가 느린 작업 임계값보다 오래 걸리는 oplog 항목을 기록합니다. 이러한 느린 oplog 메시지의 특성은 다음과 같습니다.
  • diagnostic log에 세컨더리 멤버에 대해 기록합니다.
  • applied op: <oplog entry> took <num>ms 텍스트와 함께 REPL 구성 요소 아래에 기록됩니다.
  • 로그 수준(시스템 또는 구성 요소 수준)에 의존하지 않습니다.
  • 프로파일링 수준에 의존하지 않습니다.
  • slowOpSampleRate의 영향을 받습니다.
프로파일러는 느린 oplog 항목을 캡처하지 않습니다.

클라이언트 작업(예: 쿼리)은 그 기간이 느린 작업 임계값을 초과하거나 로그 상세도 수준이 1 이상인 경우 로그에 표시됩니다. [2] 이러한 로그 항목에는 작업과 관련된 전체 명령 객체가 포함됩니다.

읽기/쓰기 작업에 대한 프로파일러 항목진단 로그 메시지(예: mongod/mongos logmessages) 에는 다음이 포함됩니다.

  • queryHash 동일한 쿼리 형태를 가진 느린 쿼리를 식별할 수 있습니다.

  • planCacheKey 느린 쿼리에 대한 쿼리 계획 캐시에 관해 더 많은 인사이트를 제공합니다.

MongoDB 5.0부터 느린 작업 로그 메시지에는 클라이언트 IP 주소를 지정하는 remote 필드가 포함됩니다.

다음 예시 출력에는 느린 애그리게이션 작업에 대한 정보가 포함되어 있습니다.

{"t":{"$date":"2020-05-20T20:10:08.731+00:00"},"s":"I", "c":"COMMAND", "id":51803, "ctx":"conn281","msg":"Slow query","attr":{"type":"command","ns":"stocks.trades","appName":"MongoDB Shell","command":{"aggregate":"trades","pipeline":[{"$project":{"ticker":1.0,"price":1.0,"priceGTE110":{"$gte":["$price",110.0]},"_id":0.0}},{"$sort":{"price":-1.0}}],"allowDiskUse":true,"cursor":{},"lsid":{"id":{"$uuid":"fa658f9e-9cd6-42d4-b1c8-c9160fabf2a2"}},"$clusterTime":{"clusterTime":{"$timestamp":{"t":1590005405,"i":1}},"signature":{"hash":{"$binary":{"base64":"AAAAAAAAAAAAAAAAAAAAAAAAAAA=","subType":"0"}},"keyId":0}},"$db":"test"},"planSummary":"COLLSCAN","cursorid":1912190691485054730,"keysExamined":0,"docsExamined":1000001,"hasSortStage":true,"usedDisk":true,"numYields":1002,"nreturned":101,"reslen":17738,"locks":{"ReplicationStateTransition":{"acquireCount":{"w":1119}},"Global":{"acquireCount":{"r":1119}},"Database":{"acquireCount":{"r":1119}},"Collection":{"acquireCount":{"r":1119}},"Mutex":{"acquireCount":{"r":117}}},"storage":{"data":{"bytesRead":232899899,"timeReadingMicros":186017},"timeWaitingMicros":{"cache":849}},"remote": "192.168.14.15:37666","protocol":"op_msg","durationMillis":22427}}

MongoDB 5.0.24 부터 느린 쿼리 로그 메시지의 totalOplogSlotDurationMicros 는 쓰기 작업에서 커밋 타임스탬프를 가져와 스토리지 엔진 쓰기를 커밋한 후 실제로 커밋하기까지의 시간을 보여줍니다. mongod 는 병렬 쓰기를 지원합니다. 그러나 커밋 타임스탬프가 있는 쓰기 작업은 순서에 관계없이 커밋합니다.

예시

커밋 타임스탬프가 있는 다음 쓰기를 생각해 보세요.

  • 타임스탬프1이 있는 writeA

  • 타임스탬프2를 사용한 writeB

  • 타임스탬프3을 사용한 writeC

writeB가 Timestamp2에서 처음으로 커밋한다고 가정합니다. 복제에서 oplog를 보조 복제 세트 멤버로 복제하려면 Timestamp1이 포함된 WriteA의 oplog 항목이 필요하기 때문에 WriteA가 커밋할 때까지 복제가 일시 중지됩니다.

느린 작업 로그 항목의 pretty-printed 예시는 로그 메시지 예시를 참조하세요.

버전 5.0에 추가.

MongoDB 5.0부터는 remoteOpWaitMillis 로그 필드를 사용하여 샤드에서 결과를 얻기 위한 대기 시간(밀리초)을 얻을 수 있습니다.

remoteOpWaitMillis 만 기록됩니다.

병합 작업이나 샤드 문제로 인해 쿼리 속도가 느려지는지 확인하려면 로그의 durationMillisremoteOpWaitMillis 시간 필드를 비교하세요. durationMillis는 쿼리를 완료하는 데 걸린 총 시간입니다. 구체적으로 다음과 같습니다.

  • durationMillisremoteOpWaitMillis보다 약간 길면 샤드 응답을 기다리는 데 대부분의 시간이 소요된 것입니다. 예를 들어 17의 durationMillis, 15의 remoteOpWaitMillis입니다.

  • durationMillisremoteOpWaitMillis보다 상당히 긴 경우 대부분의 시간이 병합을 수행하는 데 소비된 것입니다. 예를 들어 100의 durationMillis, 15의 remoteOpWaitMillis입니다.

MongoDB Enterprise에서만 사용할 수 있습니다.

mongod 또는 mongosredactClientLogData와 함께 실행되는 경우, 주어진 로그 이벤트를 로깅하기 전에 모든 메시지를 삭제하여 이벤트와 관련된 메타데이터, 소스 파일 또는 줄 번호만 남깁니다. redactClientLogData는 진단 세부 정보를 희생하여 잠재적으로 민감한 정보가 시스템 로그에 입력되는 것을 방지합니다.

예를 들어 다음 작업은 로그 수정 없이 실행 중인 mongod 파일에 문서를 삽입합니다. mongod에는 로그 세부 정보 표시 수준1로 설정되어 있습니다.

db.clients.insertOne( { "name" : "Joe", "PII" : "Sensitive Information" } )

이 작업은 다음 로그 이벤트를 생성합니다.

{
"t": { "$date": "2024-07-19T15:36:55.024-07:00" },
"s": "I",
"c": "COMMAND",
...
"attr": {
"type": "command",
...
"appName": "mongosh 2.2.10",
"command": {
"insert": "clients",
"documents": [
{
"name": "Joe",
"PII": "Sensitive Information",
"_id": { "$oid": "669aea8792c7fd822d3e1d8c" }
}
],
"ordered": true,
...
}
...
}
}

mongodredactClientLogData와 함께 실행되어 동일한 삽입 작업을 수행하면 다음과 같은 로그 이벤트가 생성됩니다.

{
"t": { "$date": "2024-07-19T15:36:55.024-07:00" },
"s": "I",
"c": "COMMAND",
...
"attr": {
"type": "command",
...
"appName": "mongosh 2.2.10",
"command": {
"insert": "###",
"documents": [
{
"name": "###",
"PII": "###",
"_id": "###"
}
],
"ordered": "###",
...
}
...
}
}

redactClientLogData를 저장 시 암호화TLS/SSL(전송 암호화)과 함께 사용하면 규제 요건을 준수하는 데 도움이 됩니다.

로그 구문 분석은 대개 자동화된 방식으로 로그 파일을 프로그래밍 방식으로 검색하고 분석하는 작업입니다. 구조화된 로깅이 도입되면서 로그 구문 분석이 더 간단하고 강력해졌습니다. 예를 들면 다음과 같습니다.

  • 로그 메시지 필드는 키-값 쌍으로 표시됩니다. 로그 파서는 관심 있는 특정 키로 쿼리하여 결과를 효율적으로 필터링할 수 있습니다.

  • 로그 메시지는 항상 동일한 메시지 구조를 포함합니다. 로그 파서는 정보가 누락되거나 형식이 다른 경우를 코딩할 필요 없이 모든 로그 메시지에서 정보를 안정적으로 추출할 수 있습니다.

다음 예시는 MongoDB JSON 로그 출력을 사용할 때의 일반적인 로그 구문 분석 워크플로를 보여줍니다.

MongoDB 구조화된 로깅으로 작업할 때 타사 jq 명령줄 유틸리티는 로그 항목을 쉽게 인쇄하고 강력한 키 기반 일치 및 필터링을 허용하는 유용한 도구입니다.

jq 는 오픈 소스 JSON 파서이며 Linux, Windows, macOS에서 사용할 수 있습니다.

이 예시에서는 jq을 사용하여 로그 구문 분석을 간소화합니다.

다음 예에서는 지정된 로그 파일의 상위 10개 고유 메시지 값을 빈도별로 정렬하여 보여 줍니다.

jq -r ".msg" /var/log/mongodb/mongod.log | sort | uniq -c | sort -rn | head -10

원격 클라이언트 연결은 속성 객체의 "remote" 키 아래에 있는 로그에 표시됩니다. 다음은 로그 파일 과정에서 모든 고유 연결을 계산하고 발생 횟수에 따라 내림차순으로 표시합니다.

jq -r '.attr.remote' /var/log/mongodb/mongod.log | grep -v 'null' | sort | uniq -c | sort -r

이 명령은 동일한 IP 주소에서 연결하지만 다른 포트를 통해 연결하는 경우 다른 연결로 취급된다는 점에 유의하십시오. 다음과 같이 변경하여 IP 주소만 고려하도록 출력을 제한할 수 있습니다:

jq -r '.attr.remote' /var/log/mongodb/mongod.log | grep -v 'null' | awk -F':' '{print $1}' | sort | uniq -c | sort -r

다음 예시에서는 모든 원격 MongoDB 드라이버 연결을 계산하여 각 드라이버 유형 및 버전을 발생 횟수에 따라 내림차순으로 표시합니다.

jq -cr '.attr.doc.driver' /var/log/mongodb/mongod.log | grep -v null | sort | uniq -c | sort -rn

다음 예시에서는 mongosh을 포함한 원격 MongoDB 드라이버 연결 및 클라이언트 애플리케이션의 보고된 클라이언트 데이터를 분석하여 연결한 각 고유 운영 체제 유형에 대한 총계를 빈도별로 정렬하여 인쇄합니다.

jq -r '.attr.doc.os.type' /var/log/mongodb/mongod.log | grep -v null | sort | uniq -c | sort -rn

이 로그 필드에 보고된 문자열 "Darwin"은 macOS 클라이언트를 나타냅니다.

느린 작업 로깅을 활성화하면 다음은 추가 분석을 위해 2000 밀리초 이상 걸린 느린 작업만 반환합니다.

jq 'select(.attr.durationMillis>=2000)' /var/log/mongodb/mongod.log

이 예시에 표시된 jq 필터에 대한 자세한 내용은 jq 문서에서 확인하세요.

로그 구성 요소(JSON 로그 출력 형식의 세 번째 필드)는 지정된 로그 메시지가 속하는 일반 범주를 나타냅니다. 구성 요소별 필터링은 관련 이벤트에 대한 로그 메시지를 분석할 때 좋은 출발점인 경우가 많습니다.

다음 예시는 컴포넌트 유형 REPL의 로그 메시지만 인쇄합니다.

jq 'select(.c=="REPL")' /var/log/mongodb/mongod.log

다음 예시에서는 컴포넌트 유형 REPL제외한 모든 로그 메시지를 인쇄합니다.

jq 'select(.c!="REPL")' /var/log/mongodb/mongod.log

다음 예시는 컴포넌트 유형 REPL 또는 STORAGE의 로그 메시지를 인쇄하는 예시입니다:

jq 'select( .c as $c | ["REPL", "STORAGE"] | index($c) )' /var/log/mongodb/mongod.log

이 예시에 표시된 jq 필터에 대한 자세한 내용은 jq 문서에서 확인하세요.

로그 ID( JSON 로그 출력 형식의 다섯 번째 필드)는 특정 로그 이벤트에 매핑되며, 연속적인 MongoDB 릴리스에 걸쳐 안정적으로 유지될 수 있도록 신뢰할 수 있습니다.

예를 들어 클라이언트 연결 후 연결 끊김을 보여주는 다음 두 가지 로그 이벤트에 관심이 있을 수 있습니다.

{"t":{"$date":"2020-06-01T13:06:59.027-0500"},"s":"I", "c":"NETWORK", "id":22943,"ctx":"listener","msg":"connection accepted from {session_remote} #{session_id} ({connectionCount}{word} now open)","attr":{"session_remote":"127.0.0.1:61298","session_id":164,"connectionCount":11,"word":" connections"}}
{"t":{"$date":"2020-06-01T13:07:03.490-0500"},"s":"I", "c":"NETWORK", "id":22944,"ctx":"conn157","msg":"end connection {remote} ({connectionCount}{word} now open)","attr":{"remote":"127.0.0.1:61298","connectionCount":10,"word":" connections"}}

이 두 항목의 로그 ID는 각각 2294322944 입니다. 그런 다음 다음 jq 구문을 사용하여 이러한 로그 ID만 표시하도록 로그 출력을 필터링하여 클라이언트 연결 활동만 효과적으로 표시할 수 있습니다.

jq 'select( .id as $id | [22943, 22944] | index($id) )' /var/log/mongodb/mongod.log

이 예시에 표시된 jq 필터에 대한 자세한 내용은 jq 문서에서 확인하세요.

타임스탬프 필드를 필터링하여 반환되는 로그 항목을 특정 날짜 범위로 제한하여 로그 출력을 더욱 세분화할 수 있습니다. 예를 들어 다음은 2020년 4월 15일에 발생한 모든 로그 항목을 반환합니다:

jq 'select(.t["$date"] >= "2020-04-15T00:00:00.000" and .t["$date"] <= "2020-04-15T23:59:59.999")' /var/log/mongodb/mongod.log

이 구문에는 밀리초를 포함하지만 시간대 오프셋을 제외한 전체 타임스탬프가 포함됩니다.

날짜 범위별 필터링은 위의 예와 결합하여 주간 보고서나 연간 요약 등을 생성할 수 있습니다. 다음 구문은 " 모니터링 연결 " 예시를 이전 버전에서 확장하여 결과를 2020년 5월로 제한합니다.

jq 'select(.t["$date"] >= "2020-05-01T00:00:00.000" and .t["$date"] <= "2020-05-31T23:59:59.999" and .attr.remote)' /var/log/mongodb/mongod.log

이 예시에 표시된 jq 필터에 대한 자세한 내용은 jq 문서에서 확인하세요.

로그 수집 서비스는 일반적으로 분산된 시스템 클러스터에서 로그 파일을 가져와 집계하여 중앙 위치에서 해당 데이터에 대한 지속적인 분석을 제공하는 타사 제품입니다.

JSON 로그 형식은 로그 수집 및 분석 서비스 작업 시 더욱 유연하게 사용할 수 있습니다. 일반 텍스트 로그는 일반적으로 이러한 제품에서 사용하기 전에 어떤 방식으로든 변환이 필요하지만, JSON 파일은 서비스에 따라 즉시 사용할 수 있는 경우가 많습니다. 또한 키-값 구조는 관심 있는 필드만 구체적으로 가져오고 나머지는 생략할 수 있는 기능을 제공하므로 이러한 서비스 필터링을 수행할 때 JSON 형식의 로그를 더 효과적으로 제어할 수 있습니다.

자세한 내용은 선택한 타사 로그 수집 서비스에 대한 설명서를 참조하세요.

다음 예에서는 JSON 출력 형식의 로그 메시지를 보여줍니다.

이러한 로그 메시지는 편의를 위해 pretty-printed 형식으로 표시됩니다.

이 예는 시작 경고를 보여줍니다.

{
"t": {
"$date": "2020-05-20T19:17:06.188+00:00"
},
"s": "W",
"c": "CONTROL",
"id": 22120,
"ctx": "initandlisten",
"msg": "Access control is not enabled for the database. Read and write access to data and configuration is unrestricted",
"tags": [
"startupWarnings"
]
}

이 예시는 클라이언트 데이터를 포함하는 클라이언트 연결을 보여 줍니다.

{
"t": {
"$date": "2020-05-20T19:18:40.604+00:00"
},
"s": "I",
"c": "NETWORK",
"id": 51800,
"ctx": "conn281",
"msg": "client metadata",
"attr": {
"remote": "192.168.14.15:37666",
"client": "conn281",
"doc": {
"application": {
"name": "MongoDB Shell"
},
"driver": {
"name": "MongoDB Internal Client",
"version": "4.4.0"
},
"os": {
"type": "Linux",
"name": "CentOS Linux release 8.0.1905 (Core) ",
"architecture": "x86_64",
"version": "Kernel 4.18.0-80.11.2.el8_0.x86_64"
}
}
}
}

이 예시는 느린 작동 메시지를 보여줍니다.

{
"t": {
"$date": "2020-05-20T20:10:08.731+00:00"
},
"s": "I",
"c": "COMMAND",
"id": 51803,
"ctx": "conn281",
"msg": "Slow query",
"attr": {
"type": "command",
"ns": "stocks.trades",
"appName": "MongoDB Shell",
"command": {
"aggregate": "trades",
"pipeline": [
{
"$project": {
"ticker": 1,
"price": 1,
"priceGTE110": {
"$gte": [
"$price",
110
]
},
"_id": 0
}
},
{
"$sort": {
"price": -1
}
}
],
"allowDiskUse": true,
"cursor": {},
"lsid": {
"id": {
"$uuid": "fa658f9e-9cd6-42d4-b1c8-c9160fabf2a2"
}
},
"$clusterTime": {
"clusterTime": {
"$timestamp": {
"t": 1590005405,
"i": 1
}
},
"signature": {
"hash": {
"$binary": {
"base64": "AAAAAAAAAAAAAAAAAAAAAAAAAAA=",
"subType": "0"
}
},
"keyId": 0
}
},
"$db": "test"
},
"planSummary": "COLLSCAN",
"cursorid": 1912190691485054700,
"keysExamined": 0,
"docsExamined": 1000001,
"hasSortStage": true,
"usedDisk": true,
"numYields": 1002,
"nreturned": 101,
"reslen": 17738,
"locks": {
"ReplicationStateTransition": {
"acquireCount": {
"w": 1119
}
},
"Global": {
"acquireCount": {
"r": 1119
}
},
"Database": {
"acquireCount": {
"r": 1119
}
},
"Collection": {
"acquireCount": {
"r": 1119
}
},
"Mutex": {
"acquireCount": {
"r": 117
}
}
},
"storage": {
"data": {
"bytesRead": 232899899,
"timeReadingMicros": 186017
},
"timeWaitingMicros": {
"cache": 849
}
},
"remote": "192.168.14.15:37666",
"protocol": "op_msg",
"durationMillis": 22427
}
}

이 예시는 속성 객체의 setName 필드에 표시된 것처럼 문자 이스케이프에 대해 설명합니다.

{
"t": {
"$date": "2020-05-20T19:11:09.268+00:00"
},
"s": "I",
"c": "REPL",
"id": 21752,
"ctx": "ReplCoord-0",
"msg": "Scheduling remote command request",
"attr": {
"context": "vote request",
"request": "RemoteCommand 229 -- target:localhost:27003 db:admin cmd:{ replSetRequestVotes: 1, setName: \"my-replica-name\", dryRun: true, term: 3, candidateIndex: 0, configVersion: 2, configTerm: 3, lastAppliedOpTime: { ts: Timestamp(1589915409, 1), t: 3 } }"
}
}

MongoDB 5.0에서 시작하는 에 대한 느린 쿼리 로그 메시지에는 뷰 세부 정보가 들어있는 resolvedViews 필드가 포함됩니다.

"resolvedViews": [ {
"viewNamespace": <String>, // namespace and view name
"dependencyChain": <Array of strings>, // view name and collection
"resolvedPipeline": <Array of documents> // aggregation pipeline for view
} ]

다음 예에서는 test 데이터베이스를 사용하여 myCollection 문서를 firstName 필드별로 정렬하는 myView 뷰를 만듭니다.

use test
db.createView( "myView", "myCollection", [ { $sort: { "firstName" : 1 } } ] )

myView에서 느린 쿼리가 실행된다고 가정합니다. 다음 예시 로그 메시지에는 myView에 대한 resolvedViews 필드가 포함되어 있습니다.

{
"t": {
"$date": "2021-09-30T17:53:54.646+00:00"
},
"s": "I",
"c": "COMMAND",
"id": 51803,
"ctx": "conn249",
"msg": "Slow query",
"attr": {
"type": "command",
"ns": "test.myView",
"appName": "MongoDB Shell",
"command": {
"find": "myView",
"filter": {},
"lsid": {
"id": { "$uuid": "ad176471-60e5-4e82-b977-156a9970d30f" }
},
"$db": "test"
},
"planSummary":"COLLSCAN",
"resolvedViews": [ {
"viewNamespace": "test.myView",
"dependencyChain": [ "myView", "myCollection" ],
"resolvedPipeline": [ { "$sort": { "firstName": 1 } } ]
} ],
"keysExamined": 0,
"docsExamined": 1,
"hasSortStage": true,
"cursorExhausted": true,
"numYields": 0,
"nreturned": 1,
"queryHash": "3344645B",
"planCacheKey": "1D3DE690",
"reslen": 134,
"locks": { "ParallelBatchWriterMode": { "acquireCount": { "r": 1 } },
"ReplicationStateTransition": { "acquireCount": { "w": 1 } },
"Global": { "acquireCount": { "r": 4 } },
"Database": { "acquireCount": {"r": 1 } },
"Collection": { "acquireCount": { "r": 1 } },
"Mutex": { "acquireCount": { "r": 4 } } },
"storage": {},
"remote": "127.0.0.1:34868",
"protocol": "op_msg",
"durationMillis": 0
}
}
}

MongoDB 5.0부터 느린 쿼리에 대한 로그 메시지에는 system.profile.authorization 섹션이 포함됩니다. 이러한 메트릭은 사용자 권한 부여 캐시에 대한 경합으로 인해 요청이 지연되는지 여부를 확인하는 데 도움이 됩니다.

"authorization": {
"startedUserCacheAcquisitionAttempts": 1,
"completedUserCacheAcquisitionAttempts": 1,
"userCacheWaitTimeMicros": 508
},

MongoDB Atlas를 사용하여 데이터베이스 배포에서 선택한 호스트 이름 또는 프로세스에 대한 로그가 포함된 압축 파일을 다운로드할 수 있습니다. 자세한 내용은 MongoDB 로그 보기 및 다운로드를 참조하세요.

돌아가기

용어집